Stadler Rail Refuses 10M Franc Ransom After Everest Attack

Published on 28 July 2026

10 million Swiss francs – that's how much the Everest ransomware group demanded from the Swiss rail vehicle manufacturer Stadler Rail. The company's answer was a firm no. And it is precisely this no that turns the case into a lesson for every German company that exchanges data with suppliers or customers.

What's interesting here isn't just that Stadler refused to pay – but how the attackers got in in the first place: not through a security flaw in Stadler's systems, not through malware, but via stolen credentials for a data-exchange platform shared with a supplier. It's an attack path that practically every company leaves open today – from the large corporation to the small trade business with a Dropbox folder.

What happened?

In mid-July 2026, cybercriminals from the Russian-speaking ransomware group Everest gained illegal access to a data-exchange platform (a kind of shared file storage) operated by Stadler Rail AG together with an unnamed supplier. Through this platform, the attackers stole the supplier's technical information.

With around 18,000 employees and over 4.9 billion US dollars in annual revenue, Stadler Rail is one of Europe's largest rail vehicle manufacturers. But according to the company's own account, its core systems remained completely untouched. In its official press release of 21 July 2026, Stadler made it clear:

„Cyberkriminelle haben sich illegal Zugriff auf die Datenaustauschplattform mit einem Stadler-Zulieferer verschafft. Diese Informationen sind nicht sicherheitsrelevant – die weltweit im Einsatz stehenden Schienenfahrzeuge sind davon nicht betroffen. Die Produktion von Stadler läuft normal weiter. Stadler zahlt unter keinen Umständen ein Lösegeld und ist somit nicht erpressbar. Stadler hat Strafanzeige eingereicht.“ (Stadler Rail AG, 21 July 2026)

The company also stressed that no relevant personal data had been stolen and that its own IT infrastructure had remained intact. Stadler filed a criminal complaint with the cantonal police of Thurgau and dealt with the incident openly.

An unusual detail

Notably: as of late July 2026, Stadler Rail did not appear on the Everest group's dark-web leak site – and the stolen data was not published. That is atypical for Everest. Cybernews journalist Gintaras Radauskas suspects the reason:

„Everest might have realized they hadn't grabbed anything of true value when they breached the systems of Stadler's supplier.“ (Gintaras Radauskas, Cybernews, 24 July 2026)

In other words: the attackers may have realised that the data they had captured simply wasn't valuable enough for credible extortion – further evidence that data minimisation on shared platforms is a genuine protective factor.

Incidentally, it wasn't the first attack on Stadler. Back in May 2020, attackers (presumably the Nefilim group) had infiltrated the company network, stolen data and demanded around 6 million US dollars in Bitcoin. Even then, Stadler refused to pay – whereupon the attackers published internal documents. So the company's stance is consistent.

The technical background – explained clearly

The crucial point for you as a business owner: this attack exploited no software vulnerability. There is no CVE number (the standardised identifier for a known security flaw), no patch, no update that would provide a remedy.

The attack path was a so-called "Valid Accounts" attack – in plain terms: the attackers used valid but stolen credentials. In the MITRE ATT&CK framework, this technique carries the identifier T1078. The insidious part: anyone logging in with correct credentials looks to the systems like a legitimate user. There is no malware warning, no alarm.

Since roughly 2024, the Everest group has switched to pure data-theft extortion – it no longer encrypts systems at all, but only steals data and threatens to publish it. According to security researchers, its typical entry points are:

• unprotected remote-maintenance access (RDP) without multi-factor authentication
• compromised VPN endpoints
• stolen credentials for third-party platforms – as in the Stadler case

The security firm Halcyon already warned back in October 2025:

„Everest exploits vulnerable remote services, uses stolen or insider-provided credentials, and breaches supplier-managed file-transfer systems to steal sensitive data and extort victims; the group has actively recruited corporate insiders since October 2023.“ (Halcyon AI Threat Research, October 2025)

Everest is one of the most active ransomware groups of all – with over 116 victims in the past twelve months alone (as of July 2026).

Who is affected? Why this concerns SMEs too

You might think: "But I'm not a rail manufacturer with billions in revenue." That's exactly the mistake. The actual point of attack was not a highly specialised industrial facility, but an ordinary data-exchange platform – something almost every company uses.

Whether SharePoint, Dropbox Business, WeTransfer Enterprise or an industry-specific customer portal: wherever you share files with suppliers, customers or service providers, this very risk exists. These platforms are often less well secured than the core systems, because they sit outside your own network and multiple parties have access.

The figures clearly show the growing danger:

• 297 supply-chain attacks in 2025 – an increase of 93% compared to 154 in 2024 (Verizon DBIR 2025).
• Third-party involvement in data breaches doubled from 15% to 30% within a year.
• Compromised credentials are responsible for around 22% of all data breaches (Verizon DBIR 2024).
• In Germany, around 950 ransomware attacks were reported during the BSI reporting period 2024/2025 – "two to three serious cases per day".

How to check whether you are at risk

1. Create an inventory: List all file-sharing, data-exchange and collaboration platforms that you use jointly with suppliers, customers or partners.
2. Check credentials: Do you use a unique, strong password for each platform? Check via haveibeenpwned.com whether your credentials appear in known data leaks.
3. Check MFA status: Is multi-factor authentication (the additional confirmation via app or code) enabled for every platform? If not – top priority.
4. Analyse access logs: Check the login history for unusual access – unknown IP addresses, unusual times, access from unexpected countries.
5. Question your suppliers: Actively ask about your partners' security measures for shared platforms. Review contractual arrangements.
6. Check data categories: What data is actually stored there? Personal data, trade secrets, security-relevant information? Minimise what you hold.

What you now need to do specifically

Since there is no patch, only one thing helps: better organisation and processes. The following measures are ordered by priority:

1. Enable multi-factor authentication (MFA) immediately – for all external platforms, VPN access, email and cloud services. This is the single most effective measure against credential-based attacks. Even stolen passwords are then of little use.
2. Rotate credentials: Change all passwords for external platforms, especially those shared with suppliers. At least 16 characters, unique, managed via a password manager.
3. Enforce least privilege: Grant each access account only as many rights as necessary. Remove access for former employees and suppliers no longer needed without delay.
4. Introduce supplier risk management: Request evidence of security measures (such as ISO 27001 certification). Regulate security requirements contractually.
5. Set up access monitoring: Enable logging and alerts for unusual patterns – such as logins from unknown countries or mass downloads.
6. Create and test an incident-response plan: Set out in writing who does what in an emergency – including reporting obligations (more on that shortly).
7. Train employees: Recognise phishing, handle credentials securely, report incidents.
8. Practise data minimisation: Store only what is essential on shared platforms. The Stadler case shows: where little of value is held, extortion loses its power.

GDPR and NIS2: The legal side

A ransomware attack is almost always also a potential data breach with reporting obligations. Bear in mind:

Reporting obligation under Art. 33 GDPR (72 hours)

As soon as personal data could be affected, the 72-hour deadline for reporting to the competent data protection supervisory authority applies. Stadler explicitly stressed that no relevant personal data had been stolen – which may have removed the reporting obligation. For SMEs, however, the rule is: when in doubt, report.

NIS2 reporting obligation (in force in Germany since 6 December 2025)

Companies with 50 or more employees or 10 million EUR annual revenue in one of the 18 regulated sectors must report significant security incidents to the BSI: early warning within 24 hours, follow-up report within 72 hours, final report within one month. Violations can be penalised with up to 10 million EUR.

„Die 24-Stunden-Frist ist das, woran Unternehmen am häufigsten scheitern. Nicht weil die Technik fehlt, sondern weil niemand weiß, wer die Meldung absetzt. Klären Sie die Zuständigkeiten, bevor der Ernstfall eintritt.“ (Kai Irmler, Head of Compliance Services at SECJUR)

Data processing on behalf (Art. 28 GDPR)

If a third-party platform processes personal data, you need a data processing agreement (DPA). If it is missing, that is itself a violation subject to fines. And: you are also liable for data breaches caused by inadequately secured service providers.

To pay or not to pay?

Stadler's consistent refusal matches the recommendations of the BSI, the BKA and international security authorities – and the statistics prove them right. According to the Proofpoint report of July 2026 (953 organisations surveyed), 54% of those affected paid a ransom. Of these, more than a third (37%) received a second demand. Anyone who pays once is regarded as willing to pay.

„Cybercrime experts advise that paying a ransom can often lead to further hassles from attackers.“ (Daryna Antoniuk, The Record, 22 July 2026)

What's more: the data recovery rate after payment is only 65%. So a third of those who pay don't get their data back in full at all.

Conclusion

The Stadler case is not an exotic industrial incident, but a blueprint for a risk that affects every company with shared data platforms. The most important lessons:

• Your supply chain is your point of attack. The weakest access point to a shared platform is enough.
• MFA is mandatory, not a nice-to-have. There is no patch against stolen credentials – only a second layer of authentication.
• Data minimisation protects you. Where little of value is held, extortion fizzles out – as the Stadler case strikingly demonstrates.
• Clarify reporting obligations in advance. GDPR (72 hours) and NIS2 (24 hours) require swift, orderly action in an emergency.
• Paying rarely pays off. A third of those who pay are extorted again, and a third still don't get all their data back.

Stadler Rail has shown how to react correctly: no payment, an immediate criminal complaint, transparent communication. Take this stance as a model – but above all, make sure that things never get that far for you in the first place.