Un ataque reciente a una planta de calor y electricidad combinados (CHP) en Polonia dejó claro un punto preocupante: incluso cuando se usa conectividad celular “privada”, la red privada APN puede convertirse en el puente que falta entre redes ajenas y entornos de control industrial. Según el informe de CERT Polska, los atacantes lograron llegar a equipos remotos y ejecutar acciones que detuvieron la turbina de vapor y afectaron el tratamiento del agua del proceso.
Lo relevante para operadores y equipos OT/IT es el recorrido del intruso: el punto de entrada no fue un sistema de planta aislado, sino una combinación de acceso remoto mal configurado, tráfico permitido entre clientes en el APN y credenciales por defecto en un controlador industrial. Aunque la recuperación empezó cerca de las 7:30 a. m., el impacto pudo contenerse en términos de servicios: ni la calefacción ni la electricidad para los residentes se perdieron por completo.
Qué ocurrió en la planta CHP y por qué importa
La planta afectada suministra calefacción a unas 50.000 personas. De acuerdo con las investigaciones, durante el incidente se detuvo la turbina de vapor y el sistema de tratamiento del agua del proceso. CERT Polska detalla que los atacantes actuaron mientras aún tenían actividad dentro de la red.
El incidente se comunicó el 8 de agosto, tras una investigación que superó los tres meses. Además, el primer ministro polaco había mencionado anteriormente que dos plantas CHP habían sido impactadas; el caso actual se describe como el segundo de esa serie.
La ruta del ataque: de una granja eólica a la planta
En vez de tratarse de una intrusión “directa” en la planta, el ataque se movió por una cadena técnica. El punto clave fue la red privada APN gestionada por el operador de red de distribución para conectar equipos remotos.
Según CERT, la arquitectura permitía que dispositivos arbitrarios comunicaran entre sí dentro del APN. Esa configuración hizo posible que un atacante “pivotara” desde una red comprometida asociada a un parque eólico hacia un controlador presente en la planta CHP. Importa subrayar que el parque eólico y la planta son instalaciones separadas y no comparten el mismo sistema de red; lo que las conectó a nivel de ruta fue precisamente la manera en que el APN fue configurado y utilizado.
Una señal que marca tendencia: tráfico cliente a cliente dentro del APN
CERT afirma que, hasta donde sabe, este fue el primer caso observado en un ataque real en el que se usó una red privada APN como vector para alcanzar una red de control industrial. Es decir, no solo se trató de un incidente con “conectividad”, sino de una evidencia de que el APN puede funcionar como canal de acceso si no existe aislamiento adecuado.
De hecho, el informe describe que en encuestas realizadas por CERT en Polonia se vio un patrón común: organizaciones que operan APNs privados solían permitir que cualquier dispositivo alcanzara a cualquier otro. Esa práctica, sumada a credenciales deficientes, elevó el riesgo de propagación.
Sin una sola “parche”: qué se pudo y no se pudo demostrar
Uno de los puntos más útiles para el lector es lo que el informe no afirma. El reporte no establece un CVE concreto como causa del acceso. Tampoco se pudo determinar si se explotó una vulnerabilidad específica en un router de Teltonika.
Esto implica una lección operativa: cuando el problema es de diseño o configuración (aislamiento en APN, credenciales por defecto, exposición de servicios de administración), no existe un único parche que “arregle todo”. CERT recomienda enfocarse en cambios de configuración y en higiene de credenciales.
Credenciales por defecto y exposición previa en la granja eólica
El salto decisivo se apoyó en una combinación de fallos. CERT indica que el controlador WAGO accesible a través del APN conservaba credenciales de administrador por defecto. Además, el APN permitía tráfico entre clientes, por lo que un acceso desde un punto comprometido podía traducirse en alcance hacia la planta.
La investigación también rastreó la entrada inicial dentro del entorno de la granja eólica. Allí, un equipo FortiGate actuaba como cortafuegos y concentrador VPN. Su VPN estaba expuesta a Internet y permitía cuentas sin autenticación multifactor.
El atacante contó con privilegios de administración en ese dispositivo. Con esos permisos, CERT considera probable que se obtuvieran credenciales VPN capaces de llegar a segmentos de red completos.
El papel de los protocolos y el “encaje” con el acceso remoto
La distribución exigía comunicaciones con una unidad terminal remota del subestación mediante el protocolo DNP3.0. El informe señala que esa condición se cumplía para el flujo que transportaba datos.
El punto crítico es otro: no existía un requisito equivalente que controlara cómo se administraba la interfaz de gestión del router celular. Esa interfaz se ubicaba en un segundo puerto de red, conectada a una VLAN situada detrás del cortafuegos comprometido. En otras palabras, el diseño permitía que el tráfico de gestión fuera alcanzable desde rutas que, en la práctica, terminaron vinculándose con la red privada APN.
Teltonika, SSH y el túnel más probable
El router involucrado fue un Teltonika RUTX50. CERT menciona que durante el despliegue se había cambiado la contraseña por defecto. Sin embargo, los investigadores recuperaron múltiples inicios de sesión SSH exitosos y no pudieron confirmar cómo el atacante obtuvo esa contraseña.
Según un análisis adicional publicado el 11 de agosto, el material revisado de vulnerabilidades divulgadas para el firmware del router no mostraba un fallo que permitiera a un atacante no autenticado obtener la contraseña. Las dos vulnerabilidades de Teltonika citadas en un asesoramiento de CISA requerían privilegios previos en el dispositivo y, en el caso de las del módem, se limitaban a denegación de servicio. Aun así, el informe deja abierta la posibilidad de una vulnerabilidad no publicada.
Con base en registros del operador móvil, CERT considera lo más probable que el atacante utilizara túneles SSH a través del router para llegar a la red privada APN.
Reconocimiento y preparación entre fechas
El informe sitúa la actividad de exploración desde el 18 de diciembre, cuando el atacante escaneó la red privada y encontró un controlador WAGO PFC200 con la interfaz web de administración accesible y con credenciales por defecto. Posteriormente, actividades SSH sugieren que el servicio probablemente se activó mediante esa interfaz.
Las correlaciones de marcas de tiempo llevaron a CERT a concluir que el atacante habría usado ese acceso, mediante túnel, para entrar en la red OT de la planta. Más tarde, el 25 de diciembre, se conectó a controladores Siemens a través del protocolo S7; CERT lo interpreta como reconocimiento para acciones posteriores.
Acciones destructivas sin malware: automatización y funciones soportadas
Entre aproximadamente las 5:30 a. m. y las 10:10 a. m. del 29 de diciembre, el atacante operó dentro de la red del CHP. La recuperación en el sitio comenzó hacia las 7:30 a. m.
De acuerdo con el personal de planta, controladores Siemens S7-300, S7-1200 y S7-1500 fueron cambiados a modo STOP y se protegieron con contraseña, lo que derivó en la detención de la turbina y la interrupción del sistema de tratamiento del agua del proceso, afectando la cogeneración.
Además, se menciona que servidores de dispositivos seriales Moxa y conmutadores fueron reseteados de fábrica: se ajustaron contraseñas y se asignaron direcciones IP inalcanzables como 127.0.0.1. CERT indica que la temporización sugiere con alto grado de confianza que esas acciones estaban automatizadas.
Un aspecto importante: el informe no describe el uso de malware para ejecutar los pasos destructivos. Cada paso se realizó usando funciones de dispositivos compatibles y llamadas a través de los protocolos que la propia planta utiliza.
Cómo se intentó dificultar el análisis posterior
Tras la parte destructiva, el atacante dañó la capacidad de arranque y los registros. El controlador WAGO recibió corrupción en la tabla de particiones, lo que lo dejó sin posibilidad de iniciar correctamente y sin logs útiles.
Además, alrededor de 30 minutos después de la última actividad observada en la planta, el atacante aplicó un factory reset al router Teltonika, cambió su contraseña de administrador y le asignó 127.0.0.1 como dirección inalcanzable. Luego, reseteó de fábrica el FortiGate, lo que provocó pérdida de registros.
CERT añade un detalle operativo sobre por qué algunos rastros sobrevivieron: versiones de RutOS anteriores a 7.07 conservaron la base de eventos tras el reseteo, permitiendo que los registros de inicio de sesión SSH permanecieran.
Qué recomienda CERT Polska para reducir el riesgo
Las recomendaciones se centran en bloquear precisamente los fallos que hicieron posible el recorrido por la red privada APN.
- Auditar la configuración del APN y activar el aislamiento de clientes.
- Tratar el APN como no confiable desde el lado OT.
- Segmentar y restringir el tráfico entre zonas.
- Retirar servicios de gestión innecesarios de las interfaces accesibles desde el APN.
- Cambiar credenciales por defecto y evitar cuentas débiles.
En conjunto, estas acciones atacan el “cómo” de la intrusión: no basta con que el enlace sea privado o celular; lo determinante es el control de alcance, aislamiento y superficie de administración.
Una lección más amplia para otros países y sectores
El informe también apunta a un contexto más amplio. Se indica que APNs privados aún aparecen como opción de aislamiento en guías federales. Un asesoramiento del 30 de julio de FBI y EPA, sobre ataques contra PLCs del sector del agua expuestos a Internet, lista arquitecturas aisladas donde se considera el APN privado para llegar a equipos OT por enlaces celulares.
En otras palabras: el concepto de APN no es el problema por sí mismo. El riesgo aparece cuando la red privada no está diseñada para impedir comunicación cliente a cliente, cuando existen credenciales por defecto y cuando la gestión de equipos queda expuesta a rutas que terminan conectando con redes operativas.
Conclusión
Este incidente en una planta CHP polaca demuestra cómo una red privada APN, si se configura con falta de aislamiento, puede permitir que un atacante alcance y afecte sistemas de control industrial. El caso combina exposición previa en un entorno remoto, tráfico permitido dentro del APN y credenciales de administración por defecto para facilitar el movimiento hacia OT.
Para prevenir daños similares, la prioridad debe ser clara: auditar el APN, activar aislamiento de clientes, tratar el acceso celular como no confiable para OT y reforzar la administración segura (segmentación, restricción de tráfico y eliminación de credenciales por defecto). Así, la conectividad “privada” deja de ser un atajo y vuelve a ser una barrera real.
Fuente: https://thehackernews.com/2026/08/hackers-breach-polish-power-plant.html
