Der kürzliche Sicherheitsbruch bei der Eurail B.V. (der in Utrecht ansässige Betreiber von Eurail und Interrail) fügt der sich immer weiter verlängerten Liste europäischer Betreiber kritischer Infrastrukturen, die in den letzten zwei Monaten von Bedrohungsakteuren ins Visier genommen wurden, einen weiteren Eintrag hinzu. Wenn wir die letzten Brüche studieren würden, zeichnet sich ein klares Muster ab:

·       Russische Bedrohungsakteure zielen mit mehreren Partnern auf Infrastrukturen in der EU

·       Einige der Sicherheitsverletzungen entstehen aufgrund mangelnder Validierung von Sicherheitsmaßnahmen durch Dritte

·       Vergessene Daten, Privilegien und Zugangsdaten werden von Bedrohungsakteuren häufiger verwendet als je zuvor

·       Das Jahresende und der Beginn eines neuen Jahres werden zunehmend zu einer beliebten Zeit für Hacker.  
 

Dieser Sicherheitsbruch sticht als ein scharfer und ernüchternder Hinweis darauf hervor, wie „identitätsreiche“ Ziele für Datenerpresser das höchste Ziel bleiben. Bedrohungsakteure machen vor nichts Halt, um Störungen zu schaffen und Daten zu stehlen.

Dieser Vorfall geht über ein einfaches Leck persönlicher Informationen hinaus. Stattdessen handelt es sich um einen hochauflösenden Datendiebstahl, der von der Regierung ausgestellte Identifikatoren, Wohnadressen und sensible Gesundheitsdaten umfasst. Der mit dem unberechtigten Zugriff verknüpfte Cache gestohlener Informationen umfasst:

·       Namen

·       E-Mail-ID

·       Wohnadressen,

·       Telefonnummern

·       Geburtsdaten

und möglicherweise Passnummern, Identitätsdokumente und sogar Bankkontoangaben

·       Passkopien von Teilnehmern des DiscoverEU-Programms

Im heutigen Blogbeitrag machen wir eine tiefgehende Analyse des Vorfalls und erkunden, was schief gelaufen ist.

Bevor wir fortfahren, vergessen Sie nicht, unseren vorherigen Blogbeitrag über „Inside December’s Cyberattack on Poland’s Power Grid and Renewable Systems“ hier zu lesen.

Zeitlinie des Vorfalls: Januar 2026

Hier ist, wie sich die Ereignisse bei der Eurail B.V. entfaltet haben:

• 10. Januar 2026: Eurail B.V. stellt offiziell einen unbefugten externen Zugriff auf ihre IT-Systeme und Kundendatenbank fest. Sofort werden Maßnahmen zur Ereignisreaktion eingeleitet. Das involvierte Team beginnt mit der „Eindämmung“, indem es Systeme sichert und externe Forensikteams einbezieht.

• 12. Januar 2026: Details zu den kompromittierten Systemen und Daten werden bekannt.

• 13. Januar 2026: Der Prozess der Berichterstattung und Benachrichtigung beginnt. Betroffene Kunden und Partnerorganisationen (einschließlich der Europäischen Kommission) werden über den Sicherheitsbruch durch formelle Datenschutzverletzungsbenachrichtigungen informiert.

• 14.-15. Januar 2026: Es werden Details über das DiscoverEU-Programm bekannt. Es wird klar, dass Teilnehmer dieses Programms einen „katastrophaleren“ Datenverlust erlitten haben als reguläre Passhalter. Eurail ist der Implementierer von DiscoverEU und verwaltet die Daten für Teilnehmer im Programm der Europäischen Kommission.

• 19. Januar 2026 (Gegenwart): Die Untersuchung bleibt „laufend“, wobei niederländische und europäische Datenschutzbehörden (DPA/EDPS) den GDPR-Compliance-Teil überwachen.

Anatomie des Angriffs: Warum und wie?

Aus einer TTP-Sicht auf einen Sicherheitsbruch scheint dies eine klassische Ausnutzung eines öffentlich zugänglichen Anwendungsvectors zu sein.

Erstzugriff (T1190 & T1078)

Indem man die Art der kompromittierten Daten untersucht, die öffentliche Erklärung von Eurail B.V und die involvierten Systeme durchgeht, ergibt sich, dass der Bedrohungsakteur eine Schwachstelle im Portal ausnutzen konnte, die dem Bedrohungsakteur direkten Zugang zur Backend-Datenbank verschaffte. Seitdem hat Eurail B.V die CVE gemäß einer Erklärung von ihnen behoben. Dies war möglicherweise ein hybrider Angriff, der eine Anwendungsschichtschwachstelle betraf (möglicherweise eine unsichere direkte Objektreferenz (IDOR) oder SQL-Injection), die dem Akteur erlaubte, Authentifizierungsmaßnahmen zu umgehen oder zu kopieren, um die Backend-Datenbank zu erreichen.

Die Schwachstelle könnte durch unsachgemäße Kodierung entstanden sein, die möglicherweise nicht ordnungsgemäß Benutzereingaben gesäubert hat. Dies erlaubte den Angreifern, Sicherheitsvorkehrungen zu umgehen, ganze Datenbanken abzuladen, Daten zu ändern oder sogar Kontrolle auf Server-Ebene zu erlangen (zum Glück ist dies in diesem Fall nicht passiert).   

Im Fall der unsicheren direkten Objektreferenz (IDOR) könnte eine Anwendung interne Identifier (wie Benutzer-IDs, Dateinamen oder Datenbankschlüssel) in URLs oder Parametern offengelegt haben, die es dem Angreifer ermöglichten, diese zu manipulieren und auf Daten zuzugreifen oder Daten zu ändern, die er nicht sollte. Dies wird häufig durch das Ändern eines Parameters in der URL getan, um die sensiblen Informationen eines anderen Benutzers zu sehen, indem auf Grund fehlender serverseitiger Überprüfungen Zugriffkontrollen umgangen werden. Dies ist im Wesentlichen eine Art von gebrochenem Zugangskontrolle, die oft zu Datenverlust oder sogar Kontrolle führt.  

Nachdem die Daten kompromittiert waren, behielt der Bedrohungsakteur für eine kurze Zeit den Zugang, bevor der Sicherheitsbruch von Eurail B.V entdeckt wurde.  

Die Diskrepanz der Daten und ihre unverhältnismäßige Auswirkung

Die technische „Einzigartigkeit“ dieses Sicherheitsbruches liegt im Sicherheitsbruch von segmentierten Daten. Anders als bei traditionellen Sicherheitsbrüchen, bei denen alle Arten von Daten offengelegt werden, haben in diesem Fall reguläre Kunden der Eurail B.V und DiscoverEU-Teilnehmer Daten unverhältnismäßig verloren. Hier ist, was jeder Kundensegment im Sicherheitsbruch verloren hat:

• Standardkunden: Nur die textbasierten Daten wurden gestohlen (Namen, Passnummern, Ablaufdaten). Laut Eurail werden keine visuellen Kopien von Pässen für diese Benutzer gespeichert.

• DiscoverEU-Teilnehmer: Die Angreifer fanden hier einen „Goldfund“, da dieses Programm visuelle Fotokopien von Identifikationsdokumenten, Bank-IBANs und Gesundheitsdaten (für Barrierefreiheitsanforderungen) erforderte. Das Vorhandensein dieser „hochwertigen“ Daten in einem einzigen Repository verwandelte einen Standard-Sicherheitsbruch in eine Motor für Identitätsbetrug mit hohen Einsätzen.

Unverhältnismäßiger Datenverlust ist heute nicht sehr häufig vorkommend, könnte aber in der Zukunft zum Standard werden bei Sicherheitsbrüchen, in denen alle Arten von Daten zusammen gespeichert sind. Im Fall von OT könnte ein Angriff, der ein Netzwerk, System oder gar einen Sicherheitsbruch einer Anwendung betrifft, eine Ereigniskette erzeugen, die zu einem kinetischen Ereignis führt.

Solche Ereignisse weisen auf die unmittelbare Notwendigkeit hin, öffentlich zugängliche Systeme zu überprüfen, die direkt oder indirekt über das Internet zugänglich sind. Daten und gefährdete Systeme müssen identifiziert werden und zusätzliche Maßnahmen zur Sicherung dürfen nicht unterlassen werden (mehr dazu später).  

Der Bedrohungsakteur: Zuschreibung

Bis heute hat keine spezifische Ransomware-Gruppe oder staatlich geförderte Akteur offiziell den Eurail-Sicherheitsbruch auf bekannten Leaks-Seiten wie BreachForums oder RansomFeed beansprucht. Dies könnte Folgendes bedeuten:

·       Der Akteur wartet auf ein passendes Fenster, um entweder die gestohlenen Daten abzulegen oder zu verkaufen

·       Er möchte möglicherweise im Hintergrund bleiben, während die Untersuchung des Vorfalls aufrecht ist

·       Ein staatlicher Akteur ist beteiligt und sie studieren momentan die kompromittierten Daten, um Daten von interessanter Personen zu identifizieren

·       Sie suchen nicht danach, einen Zug lahmzulegen. Sondern suchen danach, die Identitäten der Passagiere an „zweite-Stufe“-Betrüger zu verkaufen.

Die Stille ist sicherlich ohrenbetäubend.

Wenn man jedoch nach dem „Modus Operandi“ vorgeht, bei dem europäische Infrastrukturen für hochpräzise Identitätsdaten ins Visier genommen werden, ist dieser Vorfall bemerkenswert ähnlich zu jüngster Aktivität von Scattered Lapsus$ Hunters und IntelBroker. Das Fehlen von Ransomware schließt Gangs wie Clop aus.

Aber dann, wenn keine Behauptung und/oder eine formale Signatur vorhanden ist, kann nichts mit sehr hoher Zuversicht angenommen werden. Es könnte genauso gut ein Akteur der mittleren Ebene sein, der die Schwachstelle entdeckt und sich entschieden hat, sie auszunutzen.  

Prävention: Aufbau einer widerstandsfähigeren Eisenbahninfrastruktur

Der Eurail B.V-Sicherheitsbruch zeigt, dass Prävention nicht mehr nur darin besteht, Firewalls mit benutzerdefinierten Regeln zu haben; es geht darum, die Infrastruktur insgesamt zu entlasten.

Technische Schutzmaßnahmen

• Zero-Knowledge-Speicherung: Organisationen sollten keine visuellen Kopien von IDs speichern, wenn sie einen Drittanbieter-Verifizierungsdienst (wie Onfido oder Jumio) nutzen können, der ein „Verifizierungstoken“ statt des eigentlichen Dokuments bereitstellt.

• Identity Threat Detection and Response (ITDR): Da die Angreifer wahrscheinlich gültige oder eskalierte Konten (T1078) einmal im Inneren benutzt haben, hätte die Verwendung von Verhaltensanalysen die Massenausführung von Passdaten als Anomalie erkannt.

• Aggressive Anmeldeinformationenrotation: Automatische Rotation von Dienstkonto-Geheimnissen und API-Schlüsseln und nicht nur von Benutzerpasswörtern kann im Wesentlichen die „Beharrlichkeit“ eines Angreifers degradieren, bevor sie die ganze Datenbank kartografieren können.

• Datentrennung in einer Weise, die ihre Nützlichkeit einschränkt, wird auch empfohlen, wo immer möglich, um die Nützlichkeit der gestohlenen Informationen zu reduzieren

Der TS 50701-basierte Präventionscheckliste für Eisenbahnbetreiber

Während TS 50701 (und sein Nachfolger IEC 63452) oft mit „zugseitiger“ Betriebstechnologie (OT) assoziiert wird, bietet er einen ganzheitlichen Lebenszyklenrahmen, der wesentlich für die Sicherung des gesamten Eisenbahnumfelds ist, einschließlich in erheblichem Maße der IT-Bereitstellung für Passagiere.

Verwenden Sie diese Checkliste, um Ihre Passagierdatenarchitektur mit eisenbahnspezifischen Sicherheitsstandards in Einklang zu bringen:

Abgrenzung und Kanaltrennung (Abschnitt 6.2)

• [ ] Logische Segmentierung: Ist Ihre Passagierdatenbank (Öffentliche Zone) logisch und physisch isoliert von den Betrieblicher Zonen (Signalisierung/TMS)?

• [ ] Kanalfilterung: Werden alle Kommunikationswege zwischen dem Webportal und der Backend-Datenbank streng durch eine Deep Packet Inspection (DPI)-Firewall oder ein API-Gateway gefiltert, das Schemakontrolle durchsetzt?

• [ ] Zero Trust für Partner: Sind Partnerkanäle für DiscoverEU-Integrationen eingeschränkt durch Mutual TLS (mTLS) und eingeschränktes IP-Whitelisting?

Datenminimierung und Sicherheitsstufen (SL-T)

• [ ] Ziel-Sicherheitslevel (SL-T): Haben Sie ein Ziel-Sicherheitslevel von mindestens SL-3 festgelegt (Schutz gegen absichtliche Verstöße mit moderaten Ressourcen) für Datenbanken, die visuelle ID-Kopien enthalten?

• [ ] Tokenisierung: Können Sie die visuelle ID-Speicherung durch „Verifikationstoken“ eines zertifizierten Anbieters ersetzen? (TS 50701 betont die Reduzierung des „Systems unter Betrachtung“ (SuC)).

• [ ] Verschlüsselung im Ruhezustand (FR 4): Sind sensible Gesundheits- und Biometriedaten mit Hardware-Sicherheitsmodulen (HSM) verschlüsselt und sichergestllt, dass ein Datenbank-Dump ohne die Schlüssel nutzlos ist?

Identitäts- und Zugangsmanagement (Abschnitt 7.2)

• [ ] Automatische Geheimnissrotation: Werden die Dienstkonto-Anmeldeinformationen, die von der Webanwendung verwendet werden, automatisch alle 30 Tage oder bei festgestellten Anomalien rotiert?

• [ ] MFA für Datenbankadministratoren: Ist Phishing-resistente MFA (FIDO2/WebAuthn) für alle administrativen Zugänge zur Kundenumgebung vorgeschrieben?

Fortlaufende Überwachung und Wartung (Abschnitt 8)

• [ ] Exfiltrations-Erkennung: Haben Sie Verhaltensanalysen angepasst, um „Massen-Daten-Exporte“ zu erkennen? (Ein Standard-Reservierungssystem sollte keine 10.000 Passnummern in einer einzigen Sitzung abfragen).

• [ ] SBOM-Management: Haben Sie ein Software-Bill of Materials (SBOM) für Ihr Webportal, um verletzliche Subkomponenten (wie Log4j oder ähnliche) zu identifizieren, bevor Angreifer das tun?

• [ ] Ereignis-Spielbücher: Beinhaltet Ihr Ereignisreaktionsplan einen „eisenbahnspezifischen“ Kommunikationszweig zur Benachrichtigung europäischer DPAs innerhalb des 72-Stunden-GDPR-Zeitfensters?

Interessiert an einem maßgeschneiderten Briefing über spezifische Sicherheitsmaßnahmen zur Sicherung Ihres OT-Netzwerkes basierend auf TS 50701? Sprechen Sie mit unserem Experten.

Testen Sie unsere NDR-Lösung für OT-Sicherheit, hier.

Interessiert an einem detaillierten Briefing zu diesem Vorfall, lassen Sie es uns wissen hier.