Un atacante entró en la red de un parque eólico, pasó de allí a la red industrial de una central de cogeneración que da calefacción a unos 50.000 vecinos, apagó una turbina de vapor y el sistema de tratamiento de agua, y borró su rastro antes de irse. No usó malware ni explotó ningún fallo de software conocido. El puente entre las dos instalaciones fue una red móvil privada —una APN— que se suponía que las mantenía aisladas.
CERT Polska describe el caso como el primer incidente real que conoce en el que se llega a una red OT a través de una APN privada. El equipo lo hizo público el 8 de agosto de 2026, tras más de tres meses de análisis de un incidente ocurrido el 29 de diciembre de 2025. La instalación recuperó el servicio antes de que se cortara el calor o la electricidad, pero el camino que siguió el atacante merece atención porque casi nadie lo estaba vigilando.
El hecho que atraviesa todo el caso es que ninguna de las dos instalaciones era dueña de la red que las conectaba. El parque eólico y la central eran instalaciones separadas; la APN la gestionaba el operador de distribución eléctrica. El corredor que unía las dos redes no era responsabilidad de ninguno de los tres.
¿Qué es una APN privada y por qué se daba por aislada?
Una APN (Access Point Name, o nombre de punto de acceso) privada es una red de datos móvil dedicada que un operador de distribución eléctrica contrata a una operadora de telefonía para llegar a equipos repartidos por el territorio: subestaciones, parques renovables, puntos de telemando. Es la forma habitual de dar conectividad celular a equipamiento que está lejos y sin fibra.
La idea de la que parte todo el mundo es que esa red está separada de Internet y, por tanto, es de confianza. El propio aviso de julio del FBI y la EPA sobre ataques a autómatas de plantas de agua sigue recomendando la APN privada como una de las arquitecturas aisladas a considerar. El problema no está en la tecnología, sino en un detalle de configuración: si la APN permite que cualquier dispositivo conectado hable con cualquier otro, deja de ser un conjunto de enlaces punto a punto y se convierte en una red plana. Y una red plana no está segmentada; solo lo parece.
CERT Polska señala que, en las encuestas que hizo a organizaciones que usan este tipo de solución, esa configuración permisiva era lo habitual en Polonia, y estima que ocurre lo mismo en muchos otros países. No es un defecto de un fabricante concreto: es una suposición de confianza que se ha extendido sin revisarse.
El camino del atacante, tramo a tramo
La reconstrucción de CERT Polska es especialmente valiosa porque el atacante borró buena parte de las pruebas. El equipo rehízo la secuencia trabajando hacia atrás con lo que quedaba: registros de un router que sobrevivieron a un reinicio de fábrica y correlaciones de tiempos con los registros de la operadora móvil.
El punto de entrada: un cortafuegos VPN sin doble factor
Todo empezó en la subestación de un parque eólico, donde un dispositivo FortiGate hacía de cortafuegos y de concentrador VPN a la vez. Su interfaz VPN era accesible desde Internet y admitía cuentas sin autenticación multifactor. Con acceso administrativo al dispositivo, el atacante pudo hacerse con credenciales de VPN que alcanzaban todos los segmentos de la red de la subestación. Es un patrón conocido y evitable: un acceso remoto expuesto sin un segundo factor es una puerta que se abre sola.
El router con dos interfaces que unía dos mundos
En esa red había un router celular Teltonika RUTX50 con dos conexiones: un enlace serie hacia el equipamiento de red, como exigían las reglas de protocolo del operador de distribución, y un puerto Ethernet conectado a la red interna ya comprometida. Nadie había restringido esa segunda interfaz. Los registros recuperados del router muestran inicios de sesión por SSH repetidos a lo largo de diciembre y, desde ahí, un túnel hacia la APN privada del operador.
Hay que ser honesto con lo que no se sabe: los investigadores recuperaron esos accesos SSH pero no pudieron determinar cómo obtuvo el atacante la contraseña, que se había cambiado en el despliegue. The Hacker News revisó los fallos publicados del firmware del router y no encontró ninguno que entregase la contraseña a un atacante sin autenticar; los dos fallos de la serie RUT del aviso de CISA de 2023 requieren privilegios previos. Que no se identifique un fallo no descarta uno no publicado, pero tampoco permite culpar al fabricante: lo que consta es un acceso por credenciales cuyo origen no se pudo establecer.
El salto por la APN y un autómata con credenciales por defecto
Desde el router, el atacante hizo un túnel hacia la APN privada y, a partir del 18 de diciembre, la escaneó buscando servicios de VNC, HTTP y protocolos industriales como S7 y Modbus. Ahí encontró un controlador WAGO PFC200 en la central de cogeneración con las credenciales de administrador por defecto todavía activas en su interfaz web. El SSH no venía activado, pero los registros sugieren que el atacante lo habilitó una vez dentro. Ese autómata tenía ruta hacia el sistema SCADA de la planta y hacia el equipo que controlaba sus operaciones: se convirtió en el puente para el movimiento lateral hacia la red industrial, once días antes del sabotaje.
Una semana de reconocimiento silencioso
Entre el 18 y el 25 de diciembre, el atacante recorrió la red de la planta. Probó, sin éxito, a entrar en el cortafuegos con los nombres de cuenta «admin», «user» y un tercero asociado a una empresa que desplegaba sistemas de telemando. Escaneó servicios de acceso remoto como RDP y VNC junto a protocolos industriales, y en una subred el barrido arrancó justo en la dirección del sistema SCADA, lo que sugiere que ya había identificado los objetivos de valor. El día de Navidad se conectó a tres autómatas Siemens por el protocolo S7. CERT considera que lo más probable es que fuera reconocimiento en preparación de lo que vino después.
El sabotaje: autómatas en STOP y equipos con IP inalcanzable
El 29 de diciembre, hacia las 5:30 de la mañana, el atacante hizo un túnel a través del WAGO, abrió la interfaz web del SCADA y conectó sucesivamente con un Siemens S7-300, un S7-1200 y un S7-1500, poniendo cada uno en modo STOP y protegiéndolo con contraseña. Eso detuvo la turbina y el tratamiento de agua. También reinició de fábrica siete servidores serie Moxa y tres conmutadores, les cambió las contraseñas y les asignó direcciones IP inalcanzables como 127.0.0.1. Por los tiempos de las peticiones, CERT concluye con alto grado de confianza que esas acciones fueron automatizadas.
Nada de esto requirió malware. Cada paso destructivo usó una función legítima del dispositivo, invocada sobre los protocolos que la planta ya utilizaba. Es la característica que hace tan difícil de detectar un ataque a OT: no hay un binario extraño que un antivirus reconozca, solo órdenes válidas dadas por quien no debía.
El borrado del rastro
Antes de irse, el atacante dañó el camino de vuelta. Corrompió la tabla de particiones del controlador WAGO para dejarlo sin arrancar y sin registros útiles; de hecho, el análisis forense de laboratorio no recuperó nada de él. En el parque eólico reinició de fábrica el router Teltonika, le cambió la contraseña de administrador y le puso la dirección 127.0.0.1 para impedir reconfigurarlo, y por último borró el FortiGate que le había dado el punto de apoyo inicial, con sus registros. Que sobrevivieran algunas pruebas se debe a un detalle: las versiones de RutOS anteriores a la 7.07 conservaban su base de datos de eventos tras un reinicio de fábrica.
Por qué los controles habituales no lo vieron
La primera reacción de la planta no fue tratarlo como un ataque. Ese día había mantenimiento en curso, así que el personal supuso que los técnicos del contratista se habían equivocado y lo registró solo a título informativo. CERT abrió el incidente porque ya conocía sucesos parecidos. Esa confusión inicial no es anecdótica: cuando el sabotaje usa funciones legítimas, se parece mucho a un error de operación.
El fallo de fondo no fue un producto, sino una frontera de confianza que nadie gestionaba. El operador de distribución exigía que las comunicaciones hacia la unidad de telemando de la subestación fueran por el protocolo serie DNP3.0, y ese requisito se cumplió. Pero ningún requisito equivalente cubría cómo se administraba el router celular, cuya interfaz de gestión colgaba de una segunda interfaz Ethernet detrás del cortafuegos comprometido. El requisito gobernaba cómo viajaban los datos, no cómo se administraba el equipo que los transportaba. La norma se cumplió al pie de la letra y el hueco siguió ahí.
A eso se suma que un ataque lanzado desde un autómata no es un escenario que los investigadores de OT encuentren a menudo. La APN se daba por aislada, el WAGO conservaba sus credenciales de fábrica y la interfaz de gestión estaba expuesta: cada pieza funcionaba tal como estaba configurada. El conjunto, no.
¿Qué señales habría que buscar para detectar algo así?
La detección de un ataque como este no vive en el equipo final, porque los dispositivos afectados no admiten un agente EDR y, aunque lo admitieran, el atacante los restableció de fábrica. Vive en la red y en registros enviados fuera del dispositivo. Merece la pena vigilar varias cosas concretas:
- Inicios de sesión SSH o accesos administrativos a routers celulares y equipos de telemando que normalmente nadie toca de forma interactiva. Un router de campo no debería recibir sesiones SSH repetidas.
- Tráfico entre dispositivos dentro de una APN privada que no deberían hablarse entre sí. Si un equipo de un parque eólico alcanza un autómata de otra instalación, eso es una anomalía por sí sola.
- Barridos de protocolos industriales —S7, Modbus— y de servicios de acceso remoto (RDP, VNC) originados desde direcciones internas inesperadas, sobre todo si empiezan en la dirección del SCADA.
- Cambios de estado en los autómatas: pasos a modo STOP, protección con contraseña o recargas de lógica de control fuera de una ventana de mantenimiento planificada.
Reunir esa telemetría exige tratar la red OT como un objeto de vigilancia continua, no como una caja que solo se mira cuando algo se para. Un servicio de caza de amenazas y una capacidad de respuesta a incidentes concebidos para entornos industriales —el enfoque con el que trabajamos en la empresa de ciberseguridad Hard2bit Cybersecurity— marcan la diferencia entre reconstruir el ataque tres meses después y detenerlo mientras ocurre.
Qué cambiar en la práctica
La primera recomendación de CERT Polska es la más barata y la más olvidada: auditar la configuración de la APN privada y activar el aislamiento entre clientes, de modo que un dispositivo no pueda alcanzar a otro salvo cuando el diseño lo exija. A partir de ahí, el resto son controles conocidos que este caso vuelve a recordar:
- Tratar la APN como no confiable desde el lado OT: segmentar y restringir el tráfico, y quitar de las interfaces alcanzables por la APN cualquier servicio de gestión que no tenga que estar ahí.
- Cambiar las credenciales por defecto en todo el equipamiento de campo, autómatas incluidos, y comprobar que las interfaces web de administración no quedan expuestas.
- Exigir doble factor en todo acceso VPN y remoto, sin excepciones para cuentas de servicio o de mantenimiento.
- Definir de quién es la responsabilidad de administrar cada equipo compartido entre instalaciones y quién controla la red que las une, para que no haya fronteras de confianza huérfanas.
Para una organización que opera tecnología industrial, esto encaja en un enfoque de ciberseguridad industrial OT que empieza por conocer la superficie de ataque real —incluida la que viaja por redes de terceros— y priorizar el riesgo con criterio de negocio, como planteamos al hablar de priorizar riesgos en entornos OT/IT. Es la línea de trabajo que en Hard2bit venimos aplicando desde 2013 en entornos con ENS categoría ALTA e ISO 27001. El incidente también enlaza con un patrón que venimos observando: los ataques que entran por dispositivos de red y de perímetro que el EDR no cubre, y con la actualización de la alerta de CISA sobre ataques a PLCs en infraestructura crítica.
Lo que este caso deja abierto
Conviene no forzar las conclusiones. CERT Polska no atribuye esta intrusión concreta a ningún actor; la campaña más amplia del 29 de diciembre, que afectó a treinta instalaciones renovables y a otra central, recibió en enero cuatro valoraciones distintas de la Administración polaca, del propio CERT, de ESET y de Dragos, cada una acotada a una parte del cuadro. Este incidente en particular quedó fuera de aquel primer informe por lo que costó analizarlo, y no lleva nombre de responsable.
Lo que sí queda claro es el mecanismo, y es exportable: una red que se creía aislada, una frontera de confianza sin dueño y equipos de campo con la configuración de fábrica. Ninguno de esos tres ingredientes es exclusivo de Polonia ni del sector energético, como se ve en las amenazas híbridas contra la infraestructura europea. La cadena de suministro y las redes compartidas entre terceros son el terreno donde más se juega ahora la resiliencia operativa, algo que ya recogíamos en las lecciones de la cadena de suministro digital para el CISO. La pregunta útil para cualquier operador no es si le podría pasar lo mismo, sino quién administra hoy las redes por las que llega a sus equipos más críticos.
Este análisis se basa en el informe de seguimiento publicado por CERT Polska y en la cobertura de medios especializados con la información disponible a 12 de agosto de 2026. El caso se apoya en una divulgación pública; las menciones a equipos y fabricantes describen la configuración y la exposición observadas, no un fallo de seguridad de sus productos, ya que el vector fue abuso de accesos y mala configuración. Las atribuciones sobre la campaña más amplia pueden evolucionar. Verifica siempre las versiones y configuraciones concretas de tu entorno antes de aplicar cualquier control.
