La parte más peligrosa del ataque ya llevaba meses en marcha

El 29 de diciembre de 2025, con Polonia ya en pleno temporal de nieve y temperaturas bajo cero en la semana previa a Año Nuevo, un ciberataque coordinado golpeó más de 30 parques eólicos y solares, además de una planta de cogeneración que daba servicio de calefacción a cerca de medio millón de personas. El primer ministro, Donald Tusk, lo calificó después como un acto de sabotaje ruso con un objetivo claro: provocar un apagón en pleno invierno. 

Cuando el ataque se puso en marcha, el grupo responsable llevaba meses dentro de la planta. 

Ese es el dato clave, y aparece documentado en el análisis técnico publicado por CERT Polska en enero de 2026. Lo que ocurrió el 29 de diciembre no fue un ataque puntual ni improvisado, sino el resultado de una infiltración larga y muy trabajada, durante la cual los atacantes recopilaron información operativa, escalaron privilegios y mapearon los sistemas al detalle para saber exactamente dónde atacar. 

Cuando activaron el malware tipo wiper, no buscaban extorsionar, sino borrar datos de forma irreversible, corromper firmware y dejar inutilizados los sistemas industriales. En la planta, el ataque se consiguió frenar en el último momento gracias a los sistemas de detección en endpoint. En las subestaciones renovables repartidas por el país no hubo esa última capa de protección. 

Controladores RTU, relés de protección y equipos HMI fueron cayendo uno tras otro; se corrompió firmware, se eliminaron archivos y los operadores perdieron la visibilidad y el control remoto de instalaciones que llevaban años funcionando sin interrupciones. La electricidad seguía generándose, pero ya no había forma de supervisar ni de intervenir desde fuera. 

CERT Polska atribuyó los ataques a los grupos Static Tundra, Berserk Bear y Ghost Blizzard, vinculados al FSB ruso. Otros análisis, como los de Dragos o ESET, apuntaron con un nivel moderado de certeza a Sandworm, grupo ligado al GRU y responsable de ataques anteriores contra infraestructuras energéticas en Ucrania. Más allá de la autoría concreta, lo importante es el perfil del atacante: un actor sofisticado, con recursos, conocimiento profundo de sistemas industriales y capacidad real de provocar impacto físico a gran escala. 

En febrero de 2026, CISA lanzó una alerta global reforzando el informe de CERT Polska. El punto de entrada fue el mismo en todos los casos: dispositivos VPN FortiGate expuestos a internet, sin autenticación multifactor y con credenciales reutilizadas en más de 30 ubicaciones. Una vez dentro, los atacantes no necesitaron nada especialmente complejo. La propia arquitectura, bastante habitual en entornos OT distribuidos, ya les abría la puerta. 

Un problema recurrente en los accesos remotos 

El informe IBM X-Force Threat Intelligence Index 2026 sitúa al sector industrial como el más atacado del mundo por quinto año consecutivo, concentrando el 27,7% de todos los ciberataques. Según el Cost of a Data Breach Report 2024, el coste medio de una brecha en este sector alcanzó los 5,56 millones de dólares, un 18% más que el año anterior. Además, el tiempo medio para detectarla en entornos OT se sitúa en 199 días. En el caso de Polonia, los atacantes llevaban bastante más tiempo dentro antes de ser descubiertos. 

El patrón se repite en muchos incidentes OT.  

Los atacantes suelen entrar a través de accesos remotos pensados para uso legítimo (proveedores, mantenimiento, terceros) pero sin los controles necesarios para auditar o limitar ese acceso. A partir de ahí, se mueven lateralmente durante semanas o incluso meses, reutilizando credenciales y escalando privilegios. Cuando no hay una segmentación real entre IT y OT, ese movimiento acaba alcanzando los sistemas industriales. El impacto final no depende solo de lo sofisticado que sea el atacante, sino también del margen de maniobra que la propia arquitectura le ha ido dejando. 

Corregir esto no implica necesariamente una transformación radical que paralice la operación, aunque tampoco es sencillo en entornos donde la disponibilidad es crítica, los sistemas llevan décadas funcionando y los recursos son limitados. Aun así, los controles que habrían cambiado el resultado en Polonia son bien conocidos. 

Cualquier sesión remota con privilegios debería requerir una aprobación explícita antes de iniciarse, y cada acción debería quedar registrada en un sistema que no pueda alterarse. La reutilización de credenciales entre distintas instalaciones es bastante habitual en entornos OT distribuidos, en parte porque rotarlas de forma masiva sin afectar a la operación no es fácil, pero también es uno de los puntos más vulnerables, y centralizarlas en un sistema seguro es la forma más directa de reducir ese riesgo.  

La separación entre IT y OT tiene que aplicarse de verdad a nivel de red, no darse por hecha, de forma que una cuenta comprometida no pueda pasar de un entorno a otro sin cruzar un punto controlado. Y cuando ocurre un incidente, la organización debe poder cortar todos los accesos externos, bloquear cuentas concretas y mantener la producción interna en marcha, aislando la amenaza sin tener que elegir entre seguridad y continuidad. 

Nada de esto es teórico. En la planta de cogeneración en Polonia, el sistema de protección en endpoint consiguió frenar el ataque en el último momento. Si además hubiera habido visibilidad sobre meses de movimiento lateral a través de cuentas privilegiadas, probablemente no se habría llegado hasta ahí.  

Esa arquitectura de control y visibilidad es precisamente la que ahora exige NIS2 en Europa: control de accesos documentado, autenticación multifactor, gobierno de la cadena de suministro y procesos de respuesta probados, con responsabilidad directa de la dirección y sanciones que pueden alcanzar los 10 millones de euros o el 2% de la facturación global. 

Construir resiliencia antes de necesitarla 

En seguridad OT es bastante habitual pensar en la resiliencia como algo que entra en juego cuando la prevención falla. El caso de Polonia demuestra justo lo contrario. Cuando se activó la fase destructiva, los atacantes llevaban meses dentro. La prevención, entendida como impedir el acceso, ya había fallado mucho antes. 

Lo que realmente marcó la diferencia fue otra cosa: si existían o no controles para detectar ese movimiento lateral, limitar el impacto y recuperarse rápido. En algunos casos funcionaron (el wiper fue bloqueado) y en otros no; las subestaciones renovables quedaron expuestas. 

Las organizaciones que analicen este caso deberían hacerse dos preguntas muy concretas. La primera, si tienen visibilidad real sobre quién tiene acceso privilegiado a sus sistemas OT, a qué puede acceder y si hay algo fuera de lo normal. La segunda, si hoy mismo hubiera un atacante dentro de su red, qué capacidad tendrían para detectarlo, contenerlo y responder sin tener que parar la operación. 

En Polonia, el atacante estuvo dentro durante meses sin ser detectado. La pregunta importante no es si algo así puede volver a ocurrir en otro sitio, sino si, cuando ocurra, el impacto será el mismo.