New analysis from Shieldworkz detailed the recent cyber breach involving Spain’s railway infrastructure manager Adif and train operator Renfe, finding that attackers compromised Adif’s external-facing web infrastructure and pivoted into interconnected Renfe IT systems. However, several technical aspects of the intrusion, including initial exploitation mechanism, precise role of AI, the volume and composition of exfiltrated data, extent of internal traversal, and identity of the threat actor, remain under investigation.
The assessment said approximately 500 GB of enterprise data was exfiltrated, including passenger names and email addresses, while there was no evidence that bank details, payment information, national identity numbers or passwords were compromised.
“Zero physical train disruptions, signalling failures, or station control outages occurred,” Team Shieldworkz wrote in a Monday blog post. “Passenger transport remained fully operational. Operational impact was restricted to the preventative offline status of Adif public web services and temporary delays in online ticket management interfaces.”
Adif is Spain’s state-owned railway infrastructure manager responsible for tracks, signalling, interlocking, power networks, stations, and rail traffic control. It was the primary entry point in the incident. Renfe Operadora is the state-owned passenger and freight train operator that runs on Adif infrastructure. Renfe suffered a secondary compromise through legacy interconnected IT and data exchanges shared with Adif.
Shieldworkz identified that Renfe reported ‘several weeks’ of continuous attempted attacks that its edge security blocked before the breach occurred. The reconstruction table lists multi-week reconnaissance and brute-force campaigns against the Renfe and Adif perimeter from late August to mid-September 2026 as a confirmed fact. It also lists an initial compromise of interconnected Adif web and application infrastructure, hosting API tokens or cross-tenant databases, before Sept. 25, as a confirmed fact.
Adif detected abnormal system behavior late on Thursday, Sept. 24. On Friday, Sept. 25, preventive containment measures took the Adif and Adif Alta Velocidad web services offline. Official disclosures were released the same day. The reconstruction table says Renfe publicly confirmed the exposure of personally identifiable information through a pivot via an Adif server on the evening of Sept. 25. It describes the Adif website’s unavailability as either a preventative shutdown or DoS saturation. Systems were restored by Saturday, Sept. 26, 2026, and the table adds that the incident was formally referred to Spain’s Centro Criptológico Nacional (CCN-CERT) and law enforcement.
Team Shieldworkz said that compromised systems were public web servers, customer portal databases, external API endpoints, and the interconnected IT servers linking Adif and Renfe. The uncompromised systems included Industrial Control Systems (ICS), Computer-Based Interlocking (CBI), Centralized Traffic Control (CTC), traction power SCADA, and the GSM-R/FRMCS communication networks.
The data exfiltration section says approximately 500 GB of data was exfiltrated. Passenger names and email addresses are confirmed as exfiltrated, citing Renfe’s official statement of Sept. 25. Official statements confirm no evidence of exfiltration involving bank details, credit cards, national identity numbers (DNI/NIE), passwords, or safety-critical operational topologies. Financial and payment information, as well as national ID numbers and passwords, are marked as confirmed safe, citing Renfe and Adif disclosures. Rail SCADA and interlocking are marked as confirmed isolated, citing Adif Operational Engineering. The 500 GB bulk enterprise data figure is labeled an attributed claim, sourced to El Mundo and investigative sources.
The reconstruction table also lists the deployment of automated AI-driven exploitation agents on Sept. 24 and 25, 2026, to scrape and exfiltrate about 500 GB of IT data. It describes the agents as resembling Anthropic’s Claude API tool-use wrappers and labels this an ‘attributed claim/strongly supported’ rather than a confirmed fact.
Shieldworkz analyzed an Iranian hypothesis, since these state-sponsored actors, such as CyberAv3ngers, MuddyWater, and Agrius, have an established history of targeting critical infrastructure, rail systems, and water utilities across Europe and the Middle East. The attack targeted a major NATO and EU transportation network, which supports the hypothesis. Data theft without immediate ransom monetization also aligns with state-sponsored reconnaissance, credential harvesting, and network mapping for future operational pre-positioning.
However, Iranian operations against critical infrastructure typically include public messaging, hacktivist personas, or destructive wipers. The execution in this case was a stealthy data theft that leveraged an AI execution wrapper, which deviates from standard Iranian tactics, techniques, and procedures. The verdict is therefore insufficient evidence and low confidence for Iranian attribution. State pre-positioning remains a plausible hypothesis, but attributing this specific incident to Iran based solely on the transport target is analytically unsound.
Two alternative hypotheses should also be considered. The first is an AI-capable cybercrime or extortion syndicate, meaning a financially motivated group that uses LLM-based web-exploitation frameworks to harvest enterprise data for sale on underground forums or dark-web leak sites. The second is foreign state reconnaissance by a non-Iranian actor, meaning a foreign intelligence service that gathers relational identity data on critical infrastructure personnel to build targeted spear-phishing campaigns against rail engineers.
Three trends stand out in rail-sector attacks. Attackers target infrastructure managers such as Adif to pivot into train operators such as Renfe, bypassing the primary target’s perimeter controls. Threat actors are also shifting from manual exploitation to autonomous AI tool-use agents that can run multi-stage web application attacks at machine speed.
In addition, disrupting non-safety systems such as crew scheduling or ticketing can force operators to halt trains under safety regulations, as the Danish DSB incident showed, paralyzing operations without any breach of interlocking systems. The confirmed breach sits in enterprise IT and web services, while the operational DMZ offers plausible pivot pathways if attackers harvest credentials or API tokens. The high-impact OT layer could face unauthorized changes to signal logic, and although safety systems fail to a safe red status, network-wide signal drops would still cause economic paralysis.
Several points received less attention than they deserve. AI agents can map databases and exfiltrate 500 GB of data within hours, sharply shrinking the window for SOC detection. Adif serves multiple operators, including Renfe, Iryo, and Ouigo, so a compromise of its IT/OT boundary could expose the entire national rail ecosystem. Exfiltrated employee records also give attackers the targeting intelligence to craft spear-phishing campaigns against signalling engineers. Inter-agency cloud APIs act as bridges across logical air gaps, and data theft often serves as reconnaissance for future operational disruption.
Shieldworkz evaluates that the attack involved AI execution agents that were deployed against Adif web application interfaces. Trackside OT, signalling, and train operations were completely isolated and were not affected.
Clearly, absence of demonstrated OT compromise should not be interpreted as evidence that the enterprise-to-operational dependency surface is irrelevant. Conversely, the existence of digital interconnections should not be treated as evidence that attackers reached OT. Thus, the central security question is not whether IT and OT are connected in the abstract. The question is which trusted pathways, identities, services, and data exchanges can cross the boundary, and what controls govern them.
The post prescribed that railway OT teams should build their defense around identity, segmentation, and visibility. OT domain controllers should be disconnected from corporate Active Directory, with an independent, non-routable identity provider maintained for OT. FIDO2 hardware keys should be enforced for all access to OT jump servers and engineering gateways, and persistent contractor VPN connections should be replaced with session-recorded, time-bound access approvals for maintenance windows.
Under IEC 62443, strict boundaries should separate Enterprise IT (Zone 3), the OT DMZ (Zone 2), SCADA and CTC (Zone 1), and field PLCs and interlocking (Zone 0). Hardware data diodes should export historian data from OT to IT while preventing reverse traffic. OT-native passive sensors should monitor industrial protocols from SPAN or TAP ports in control centers without adding latency, and public web APIs should be hardened against automated LLM tool-use agents through behavioral rate limiting and bot mitigation.
The OT incident response playbook puts safety first. If cyber telemetry raises uncertainty about signal status or train tracking integrity, operations must move to degraded manual operation or controlled signal stops in line with railway safety manuals. The cyber SOC handles containment, API blocking, and forensics within IT boundaries, while OT engineering verifies PLC logic, checks SCADA telemetry, and monitors trackside controllers. The rail operations or safety director holds ultimate authority over service suspensions and manual overrides.
Back in May, industrial cybersecurity firm Dragos revealed details of an AI-assisted intrusion targeting a municipal water and drainage utility serving the Monterrey metropolitan area in Mexico, after researchers from Gambit Security uncovered a broader campaign that compromised multiple Mexican government organizations between December 2025 and February 2026. According to the investigation, the unidentified adversary used commercial AI models from Anthropic and OpenAI to accelerate reconnaissance, intrusion planning, malware development, lateral movement, and data exfiltration, while attempting to pivot from the utility’s enterprise IT network toward OT (operational technology) infrastructure.
