Ciberataque a Adif y Renfe: qué se sabe y por qué importa la conexión entre sus sistemas

A última hora del jueves 24 de septiembre, Adif detectó «actividad inusual» en sus sistemas. Al día siguiente, Renfe informó de que los atacantes habían utilizado servidores de Adif previamente comprometidos e interconectados con los suyos para acceder a información de sus clientes, sobre todo nombres y direcciones de correo electrónico.

Ni Adif ni Renfe han informado de incidencias en la circulación. Adif suspendió por precaución las webs de Adif y Adif Alta Velocidad, las restableció el sábado 26, presentó denuncia y notificó el incidente al Centro Criptológico Nacional (CCN). Renfe aisló los entornos afectados, activó sus protocolos de respuesta y recurrió a especialistas independientes.

Para otras organizaciones, lo relevante está en el origen. Según la versión de Renfe, la intrusión que expuso datos de sus clientes empezó en los sistemas de otra entidad conectada a los suyos. MITRE ATT&CK describe esa vía como abuso de una relación de confianza (T1199), y a ella se exponen las empresas que intercambian datos, cuentas o accesos con un socio, un proveedor o una filial.

¿Qué han confirmado Adif y Renfe?

Hasta el 27 de septiembre, Adif y Renfe han confirmado públicamente lo siguiente:

1. Detección: actividad inusual en los sistemas de Adif a última hora del jueves 24.
2. Origen: servidores de Adif comprometidos con anterioridad e interconectados con sistemas de Renfe.
3. Datos: información «limitada» de usuarios de Renfe, principalmente nombres y correos, sin indicios de acceso a datos bancarios, medios de pago ni DNI.
4. Publicación: Renfe no ha encontrado pruebas concluyentes de que esa información se haya difundido.
5. Antecedentes: Renfe venía bloqueando desde hacía varias semanas intentos de ataque continuados.
6. Operación ferroviaria: según Adif, ningún sistema relacionado con la explotación ferroviaria resultó afectado.
7. Notificaciones: Adif presentó denuncia, avisó al CCN y alertó a las empresas y proveedores que hayan podido verse afectados.

¿Se robaron 500 GB y se usó IA? Lo que sigue sin confirmar

Dos datos han ocupado buena parte de los titulares sin respaldo oficial. El primero es el volumen. El Mundo, citando fuentes próximas a la investigación según recoge Infobae, habla de unos 500 GB extraídos, con el pico de extracción el jueves. Sitúa además el posible acceso inicial en la web de Adif, desde donde los atacantes habrían saltado a la infraestructura en la nube de la entidad y, de ahí, a Renfe.

El segundo es la inteligencia artificial. Según las mismas fuentes, los investigadores analizan si los atacantes se apoyaron en un sistema de IA para encontrar la vulnerabilidad. Ninguna de las dos entidades ha confirmado este punto ni la cifra de 500 GB, y el grupo responsable sigue sin identificar.

Las dos versiones encajan mal. Un listado de nombres y correos, incluso de millones de viajeros, ocupa una fracción mínima de 500 GB. Si esa cifra se confirma, habrá salido bastante más que los datos de clientes descritos por Renfe, y hoy no se sabe de qué tipo ni de qué sistemas. Hasta que Adif o Renfe den más información, este análisis parte de lo confirmado y trata el resto como hipótesis.

¿Cómo pasa un atacante de una organización a otra conectada?

Adif y Renfe formaban parte de la antigua RENFE hasta el 1 de enero de 2005. Ese día se hizo efectiva la separación entre la gestión de la infraestructura y la explotación de los trenes que preveía la Ley 39/2003 del Sector Ferroviario. Hoy Renfe circula por la red que gestiona Adif, y ambas necesitan intercambiar información a diario. Cada uno de esos intercambios se apoya en un mecanismo técnico: una cuenta de servicio, una API, un túnel de red, una carpeta compartida o una base de datos replicada.

Quien controla un extremo de esa conexión recibe la confianza que el otro extremo concede. Muchas organizaciones vigilan con detalle lo que llega desde internet y tratan el tráfico de un socio como si fuera interno, con permisos amplios y poca monitorización. Por esa rendija puede pasar un atacante sin necesidad de romper el perímetro del segundo objetivo.

El fenómeno no es exclusivo del sector ferroviario. El ENISA Threat Landscape 2026 constata que los grupos criminales atacan cada vez más a proveedores y terceros, como analizamos en nuestra lectura del informe sin el ruido del DDoS. Y el Data Breach Investigations Report 2026 de Verizon sitúa en el 48 % las brechas analizadas con participación de un tercero, una categoría amplia que va más allá de las intrusiones por relación de confianza.

¿Qué exige el ENS para interconectar sistemas?

Adif y el grupo Renfe forman parte del sector público estatal y, por tanto, del ámbito de aplicación del Esquema Nacional de Seguridad. La norma regula este escenario en la medida op.ext.4, «Interconexión de sistemas», del Real Decreto 311/2022, exigible desde la categoría media.

La medida pide autorización previa para todo intercambio con otros sistemas y prohíbe todo flujo de información que no esté autorizado expresamente. Para cada interconexión hay que documentar las características de la interfaz, los requisitos de seguridad y de protección de datos y la naturaleza de la información que se intercambia. En categoría alta añade el refuerzo R1, «Coordinación de actividades», aplicable a escenarios como este. Cuando la identificación, autenticación y autorización tienen lugar en dominios de seguridad distintos, bajo responsabilidades distintas, las medidas locales deben acompañarse de mecanismos de coordinación que atribuyan a cada parte sus responsabilidades.

El artículo 33.2 del mismo decreto obliga a las entidades del sector público a notificar al CCN los incidentes con impacto significativo, y Adif lo ha hecho en este caso. Según su artículo 2.3, el ENS alcanza también a los sistemas de las empresas privadas que, por contrato, prestan servicios o proveen soluciones a entidades públicas para el ejercicio de sus competencias.

Para el resto del sector privado, las referencias más próximas son los controles de relación con proveedores de ISO/IEC 27001:2022 (5.19 a 5.22), de adopción voluntaria, y la seguridad de la cadena de suministro que exige el artículo 21 de NIS2. La transposición de esta directiva en España sigue pendiente a 27 de septiembre, mientras continúa vigente el Real Decreto-ley 12/2018, que incorporó la primera directiva NIS.

¿Cuánto riesgo corren los clientes si solo salieron nombres y correos?

Un nombre asociado a un correo y a la condición de cliente de Renfe basta para preparar un correo de phishing creíble. Los señuelos previsibles son avisos de reembolso por el incidente, compensaciones por retrasos, cambios de billete o solicitudes para «verificar la cuenta». Quien reciba un mensaje así debería abrir la aplicación de Renfe o escribir a mano la dirección de su web, sin pulsar el enlace del mensaje.

Las empresas también están expuestas. Muchos empleados compran los billetes de sus viajes de trabajo con el correo corporativo, así que el listado puede incluir direcciones de empresa asociadas a nombre y apellidos de personas que probablemente se desplazan por trabajo. Es material útil para un phishing dirigido contra la organización, y justifica un aviso interno a quienes viajan con frecuencia.

Como responsable del tratamiento, Renfe está sujeta al artículo 33 del RGPD, que exige notificar una brecha a la autoridad de control sin dilación indebida y, de ser posible, en un máximo de 72 horas desde que se tiene constancia de ella. La excepción es que resulte improbable que suponga un riesgo para las personas. El artículo 34 añade, por regla general, la comunicación directa a los afectados cuando el riesgo es alto. Cómo se valore este caso dependerá de lo que la investigación confirme sobre el volumen y el tipo de datos.

Cinco comprobaciones para empresas conectadas con otras

Primero, inventariar las interconexiones: qué organizaciones externas pueden iniciar una conexión hacia los sistemas de la empresa, con qué cuenta, por qué protocolo y hasta qué datos llegan. Sin ese inventario, las demás medidas se apoyan en una base incompleta.

Segundo, tratar cada socio como una zona separada de la red, con acceso limitado a los sistemas que necesita y cuentas de servicio con los permisos mínimos. Es la misma lógica que explicamos en el artículo sobre segmentación de la red interna, aplicada a la frontera con otra organización.

Tercero, vigilar lo que sale. Una extracción de gran volumen repartida en varios días deja huella en los flujos de red, en los registros del cortafuegos y en la factura de tráfico saliente del proveedor de nube. Detectarla depende de que esas fuentes lleguen a un SOC que las correlacione, y la guía sobre qué registros enviar al SIEM ayuda a priorizarlas.

Cuarto, leer como aviso los intentos bloqueados. Cuando se repiten durante semanas contra los mismos servicios, lo habitual es que alguien haya elegido a la organización como objetivo. Es el momento de revisar su superficie de ataque y la de las entidades con las que está conectada, empezando por las aplicaciones web.

Quinto, pactar por escrito qué pasa cuando la otra parte sufre un incidente. Los contratos y acuerdos de interconexión deberían fijar plazos de aviso, contactos de respuesta a incidentes y quién puede cortar el enlace, y el procedimiento debe ensayarse antes de necesitarlo. La gestión del riesgo de terceros y un plan de respuesta a incidentes compartido entre organizaciones dan forma a esos acuerdos.

El comunicado de Renfe y la frase que parecía escrita por IA

El comunicado de Renfe tiene una estructura correcta: qué datos se vieron afectados, cuáles no, qué medidas se han tomado y qué se sigue investigando. Según ADSLZone y Que.es, la primera versión publicada en su web terminaba con la frase «Esta segunda versión tiene un tono más institucional», que ambos medios interpretan como un resto de redacción asistida por IA. Cuando publicaron sus artículos, el texto ya estaba corregido.

El episodio ilustra un riesgo común en las primeras horas de un incidente, cuando los textos se escriben con prisa, pasan por varias manos y se publican con menos controles de los habituales. Tener plantillas aprobadas de antemano y una última revisión humana antes de publicar hace menos probable que un detalle de forma eclipse el mensaje principal, como explicamos en la guía de comunicación de crisis en las primeras 24 horas.

Preguntas abiertas y una para el comité de dirección

Siguen sin respuesta el volumen exacto de lo extraído y su contenido, el papel de la IA, si lo tuvo, la autoría y si los datos aparecerán en algún foro. Este análisis se actualizará cuando Adif, Renfe o los investigadores aporten datos nuevos.

La pregunta para el próximo comité de dirección es qué entidades externas pueden entrar hoy en los sistemas de la empresa, con qué cuenta y hasta dónde. Si la respuesta no está documentada, el inventario de interconexiones es el primer trabajo pendiente.

Este análisis se basa en las declaraciones públicas de Adif y Renfe y en la información publicada por los medios citados hasta el 27 de septiembre de 2026. Las cifras de volumen, la supuesta vía de entrada por la web de Adif y su nube y el posible uso de inteligencia artificial proceden de fuentes periodísticas y no han sido confirmados por las entidades afectadas. El texto no atribuye el incidente a fallos de productos ni de proveedores tecnológicos determinados, y la atribución del ataque puede cambiar a medida que avance la investigación.