Threat intel

On Friday, September 25, Renfe, Spain's state-owned train operator, said attackers had accessed customer data, mainly names and email addresses. The attack did not start at Renfe. It started on servers belonging to Adif, the separate state company that runs Spain's track, stations and signalling. Those servers had already been compromised and were connected to Renfe's systems, and the attackers used that connection to get in.

Trains kept running and Renfe says no payment or ID data was taken. What makes the case useful to everyone else is the route: two companies with separate IT and security teams were joined by a trusted link, and a breach at one became a breach at the other. If your systems connect to a sister company, a parent group, an outsourcer or a public-sector partner, you have the same kind of link.

How it works

Adif manages the infrastructure and Renfe runs the trains and sells the tickets, so their systems have to exchange data. Links like this are usually built from a mix of four things. A network link, such as a site-to-site VPN or a private circuit, with firewall rules that allow the partner's address ranges. Service accounts, API keys or certificates issued to the partner and stored on its servers so its applications can call yours. A directory or identity trust, such as an Active Directory trust or a cross-tenant setting in Microsoft Entra ID, that lets the partner's accounts sign in to your resources. And shared platforms: a hosting environment, file transfer server or management tool that both sides administer.

Every one of these assumes the other side is healthy. Traffic from a partner range often skips the web application firewall and the rate limits applied to internet traffic. A partner's service account has standing access around the clock, because a machine calls the API and no person signs in, so there is no MFA prompt to fail. An attacker who takes over a server on the partner side inherits whatever that server could reach, with credentials and network paths your monitoring treats as normal.

Renfe and Adif have not said which of these connected the compromised Adif servers to Renfe. Their wording is that the servers were "previously compromised and interconnected" with Renfe's systems. So the first intrusion happened at Adif, and the Renfe data was reached from inside that trusted path rather than through Renfe's own internet-facing services.

That changes the response. Rotating your own passwords does nothing if the attacker holds the API key you issued to the partner, and blocking suspicious internet addresses does nothing if the traffic arrives over the VPN.

What attackers are doing

Both companies describe this as the end of a longer campaign: "several weeks" of attack attempts against their systems, detected and blocked, before the one that succeeded through Adif.

What the companies have confirmed, as reported:

• Renfe disclosed the incident on Friday, September 25, and Adif's websites went offline. Reports differ on how long; one says they were restored the next day after security checks, another that they were down for several days.
• The data accessed was limited customer information, mainly names and email addresses. Renfe says there is no evidence of access to bank or payment details, national ID numbers or other sensitive data, and it has not said how many customers are affected.
• Renfe says there is no conclusive evidence the data has been published.
• Adif says rail traffic systems kept operating normally throughout, and trains ran as usual.
• Both companies activated their incident procedures, isolated the affected environments, added protections with independent security specialists and told technology suppliers that might be affected. Both filed police reports and sent the details to Spain's National Cryptologic Centre (CCN-CERT), the incident response team attached to the National Intelligence Centre (CNI).

Some Spanish outlets, citing unnamed sources, reported that the attackers used AI-assisted automated scanning to find their way in and took a large volume of data. Neither company's statement confirms either claim, and neither has named the group responsible. Treat both as unverified until Renfe, Adif or CCN-CERT say more.

For Renfe customers the practical risk is phishing. A name and an email address are enough for a convincing "your booking has changed" or "refund due" message. Open bookings through the Renfe app or by typing the website address, not through links in email.

What to do

These steps apply to any organisation whose systems connect to another organisation's: a sister company in the same group, a subsidiary, an outsourced IT provider or a public body you exchange data with.

1. List every link. For each partner, record the network paths (VPN tunnels, private circuits and the firewall rules that name their address ranges), the credentials they hold (service accounts, API keys, client certificates, SSH keys) and any identity trust. On Active Directory, Get-ADTrust -Filter * | Select Name,Direction,SelectiveAuthentication,SIDFilteringQuarantined lists trusts and shows whether selective authentication and SID filtering are on. In Microsoft Entra, open External Identities, then Cross-tenant access settings, and review the enterprise applications registered from partner tenants.
2. Cut each link down to what it needs. A partner should reach named hosts on named ports, ideally one API gateway or file transfer server in its own network zone, never a routed path into your internal network. Scope each partner credential to the records it needs, not read access to the whole customer database.
3. Make partner credentials short-lived. Prefer tokens that expire in hours over static keys, and record where each credential is stored on the partner side so you know what an attacker on that server would find.
4. Log the traffic between you separately. Filter firewall logs by the partner's ranges, API gateway logs by client ID and Entra sign-in logs by cross-tenant access type. Baseline normal volume per link and alert on new destination hosts, queries against customer tables the partner does not normally touch, bulk exports and activity outside the partner's usual hours.
5. Agree in advance what happens when one side is hit. Put a notification deadline in the agreement, name a contact on each side, and keep a tested way to shut each link off quickly. Renfe and Adif telling their suppliers is the step every partner will need from you.

If a partner announces a breach, do not wait for their investigation to finish. Rotate every credential they hold for your systems, narrow or suspend their network access, and search your logs for their traffic back to the earliest date they give. To size the problem before it happens, ask what someone with full control of your partner's server could read in your environment using only what is already on that server.

Our network penetration testing can start from a foothold on a partner-facing or shared system and show how far it reaches, and our attack surface management work keeps track of the links and exposed services a group of companies builds up over time. Open the chat and Yaali, our AI agent, will pass your question to the engineer who would run the work.

---

Sources: The Local Spain, TodoAlicante, RusTourismNews, inSpain.news, APD Notícies, Ara.