The recent breach of Eurail B.V. (the Utrecht-based operator of Eurail and Interrail) adds another entry to an ever-lengthening list of European critical infrastructure operators that have been targeted by threat actors in the last two months. If we were to study the last few breaches, a clear pattern emerges:

·       Russian threat actors are targeting infrastructure across EU using multiple affiliates

·       Some of the breaches are occurring due to a lack of validation of third-party security measures

·       Forgotten data, privileges and credentials are being used more frequently by threat actors than ever

·       Year-end and the start of a new year are becoming a favorite time for hackers.  
 

This breach stands out as a stark and sobering reminder of how "identity-rich" targets remain the holy grail for data extortionists. Threat actors will stop at nothing to create disruption and steal data.

This incident isn't just about a simple leak of personal information. Instead it is a high-fidelity data theft involving government-issued identifiers, home address and sensitive health data. The cache of stolen information linked to the unauthorized access includes:

·       Names

·       email ID

·       Home addresses,

·       Phone numbers

·       Dates of birth

and possibly passport numbers, identity documents, and even bank account details

·       Passport copies of DiscoverEU program participants

In today blog post, we do a deep dive into the incident and explore what went wrong.

Before we move forward, don’t forget to check our previous blog post on “Inside December’s cyberattack on Poland’s power grid and renewable systems” here.

The incident timeline: January 2026

Here is how things unfolded at Eurail B.V:

• January 10, 2026: Eurail B.V. officially detects an unauthorized external access to its IT systems and customer database. Incident response measures are launched immediately. The team involved initiate "containment" by securing systems and engaging external forensics teams.

• January 12, 2026: Details emerge on the systems and data compromised.

• January 13, 2026: Reporting and notification process begins. Impacted customers and partner organizations (including the European Commission) are informed of the breach through formal data breach notifications.

• January 14-15, 2026: Details emerge regarding the DiscoverEU program. It becomes clear that participants in this program suffered a more "catastrophic" data loss than standard pass holders. Eurail is the implementer of DiscoverEU and manages the data for participants in the European Commission's program.

• January 19, 2026 (Present): Investigation remains "ongoing," with Dutch and European Data Protection Authorities (DPA/EDPS) overseeing the GDPR compliance bit.

Anatomy of the attack: Why and how?

From a breach TTP standpoint, it appears to be a classic exploitation of a public-facing application vector.

Initial access (T1190 & T1078)

By studying the nature of data compromised, the public statement issued by Eurail B.V and the systems involved, it seems that the threat actor was able to exploit a vulnerability in the portal that gave the threat actor direct access to the backend DB. Since then, Eurail B.V has fixed the CVE as per a statement from them. This was possibly a hybrid attack involving an application-layer vulnerability (possibly an Insecure Direct Object Reference (IDOR) or a SQL injection) that allowed the actor to copy or even bypass the authentication measures to reach the backend database.

The vulnerability in question could have arisen from improper coding that may have failed to sanitize user input. This allowed the attackers to bypass security, dump entire databases, modify data, or even gain server level control (thankfully this didn’t happen in this case).   

In case of the Insecure Direct Object Reference (IDOR), an application could have exposed the internal identifiers (like user IDs, file names, or database keys) in URLs or parameters, allowing the attacker to manipulate them and access or modify data they shouldn't. This is often done by changing a parameter in the URL to view another user's sensitive information, bypassing access controls due to missing server-side checks. It is essentially a type of broken access control that often leads to loss of data or even control.  

Once the data was compromised, the threat actor continued to retain access for a short period of time before the breach was detected by Eurail B.V.  

The data discrepancy and its disproportionate impact

The technical "uniqueness" of this breach lies in the breach of segmented data. Unlike traditional breaches were all types of data are exposed, in this instance, regular customers of Eurail B.V and DiscoverEU participants lost data disproportionately. Here is what each segment of customers lost in the breach:

• Standard customers: Only the text-based data was stolen (names, passport numbers, expiry dates). As per Eurail, it does not store visual copies of passports for these users.

• DiscoverEU Participants: The attackers hit a "goldmine" here because this program required visual photocopies of IDs, bank IBANs, and health data (for accessibility requirements). The presence of this "high-value" data in a single repository turned a standard breach into a high-stakes identity fraud engine.

Disproportionate data loss is not a very common occurrence today but may become the norm in the future in case of breaches where all types of data are stored together. In the case of OT, an attack that involves a network, system or even an application breach could end up creating a chain of events leading to a kinetic event.

Such events point to an immediate need to audit public-facing systems that can be directly or indirectly accessed via the internet. Data and systems at risk need to be identified and additional measures should be taken to secure them (more on this later).  

The threat actor: Attribution

As of today, no specific ransomware group or state-sponsored actor has officially claimed the Eurail breach on known leak sites like BreachForums or RansomFeed. This could mean:

·       The actor is waiting for an opportune window to either dump or sell the stolen data

·       They may want to stay in the shadows while the investigation into the incident is on

·       A state-actor is involved and they are presently studying the breached data to identify data belonging to persons of interest

·       They certainly aren't looking to lock down any train. But are looking to sell the passengers' identities to "second-stage" fraudsters.

The silence is certainly deafening.

However, if one goes by the "modus operandi" involving targeting European infrastructure for high-fidelity identity data, this incident is remarkably similar to recent activity by Scattered Lapsus$ Hunters and IntelBroker. Absence of a ransomware eliminates gangs such as Clop.

But then in the absence of a claim and/or a formal signature, nothing can be assumed with a very high level of confidence. This could very well be a mid-tier actor that came across the vulnerability and decided to exploit it.  

Prevention: Building a more resilient railway infrastructure

The Eurail B.V breach highlights that prevention is no longer just about having firewalls with custom rules; it’s about de-risking the infrastructure as a whole.

Technical safeguards

• Zero-knowledge storage: Organizations should not store visual copies of IDs if they can use a third-party verification service (like Onfido or Jumio) that provides a "verification token" instead of the actual document.

• Identity hreat Detection and Response (ITDR): Since the attackers likely used valid or escalated accounts (T1078) once inside, the use of Behavioral Analytics would have flagged the mass exfiltration of passport data as an anomaly.

• Aggressive credential rotation: Automated rotation of service account secrets and API keys and not just user passwords can essentially "degrade" an attacker's persistence before they can map the entire database.

• Data segregation in a manner that limits its usefulness is also recommended wherever possible to reduce the usefulness of the stolen information

The TS 50701-based prevention checklist for railway operators

While TS 50701 (and its successor IEC 63452) is often associated with "train-side" Operational Technology (OT), it provides a holistic lifecycle framework that is essential for securing the entire rail ecosystem, including to a large extent, passenger-facing IT.

Use this checklist to align your passenger data architecture with railway-specific security standards:

Zoning and conduit isolation (Section 6.2)

• [ ] Logical segmentation: Is your passenger database (Public Zone) logically and physically isolated from the Operational Zones (Signaling/TMS)?

• [ ] Conduit filtering: Are all communications between the web portal and the backend database strictly filtered through a Deep Packet Inspection (DPI) firewall or an API Gateway that enforces schema validation?

• [ ] Zero-Trust for partners: For DiscoverEU integrations, are partner conduits restricted by Mutual TLS (mTLS) and restricted IP whitelisting?

Data minimization and Security Levels (SL-T)

• [ ] Target Security Level (SL-T): Have you defined a Target Security Level of at least SL-3 (protection against intentional violation with moderate resources) for databases containing visual ID copies?

• [ ] Tokenization: Can you replace visual ID storage with "Verification Tokens" from a certified provider? (TS 50701 emphasizes reducing the "System under Consideration" (SuC) footprint).

• [ ] Encryption at rest (FR 4): Is sensitive health and biometric data encrypted with Hardware Security Modules (HSM), ensuring that a database dump is useless without the keys?

Identity and Access Management (Section 7.2)

• [ ] Automated Secret Rotation: Are the service account credentials used by the web application rotated automatically every 30 days or upon detected anomalies?

• [ ] MFA for Database Admin: Is Phishing-Resistant MFA (FIDO2/WebAuthn) mandated for all administrative access to the customer environment?

Continuous Monitoring and Maintenance (Section 8)

• [ ] Exfiltration detection: Do you have behavioural analytics tuned to detect "Bulk Data Exports"? (A standard reservation system should not be querying 10,000 passport numbers in a single session).

• [ ] SBOM Management: Do you have a Software Bill of Materials (SBOM) for your web portal to identify vulnerable sub-components (like Log4j or similar) before attackers do?

• [ ] Incident Playbooks: Does your incident response plan include a "Railway-Specific" communication branch for notifying European DPAs within the 72-hour GDPR window?

Interested in a custom briefing on specific security measures to secure your OT network based on TS 50701? Talk to our expert.

Test drive our NDR solution for OT security, here.

Interested in an in-depth briefing on this incident, let us know here.