ESC

Escribe para buscar entre todos los artículos

Volver al archivo

Cómo se gesta un ataque a una planta eléctrica: 70 segundos que cambian todo

Análisis forense de un ataque multietapa a una subestación eléctrica simulada. Desde polling Modbus legítimo hasta corrupción de PLCs en menos de 70 segundos. Kill Chain completa.

Un caso de análisis forense OT/ICS

Hoy comparto un caso de análisis forense sobre un entorno simulado de una subestación eléctrica (OT/ICS). El archivo PCAP muestra un ataque multietapa completo.

Esto es lo que ocurre, segundo a segundo.


La línea de tiempo del ataque

T+0 a T+33s — Todo parece normal

El SCADA realiza polling legítimo a 10 PLCs vía Modbus/TCP (FC3 Read Holding Registers). 844 lecturas cíclicas. El operador no ve nada inusual.

El atacante sí lleva tiempo dentro.

T+33s — DNS Tunneling

Un host interno dispara 40 solicitudes DNS anómalas en menos de 1 segundo. No es resolución de nombres. Es beaconing.

El malware está despertando.

T+34s a T+38s — Canal C2 activo

Se establece una conexión TLS cifrada a una dirección IP externa. El atacante ya recibe datos de la red OT y envía instrucciones.

Nadie lo ve porque “es solo HTTPS”.

T+39s a T+53s — Movimiento lateral

Tres nodos coordinados realizan un SYN scan sobre el SCADA maestro: puertos 22, 80, 443 y 502. Las sesiones SSH exitosas confirman lo peor.

El SCADA fue comprometido.

T+54s a T+70s — Impacto físico

El SCADA, ahora controlado por el atacante, envía 56 comandos FC16 (Write Multiple Registers) con valores aleatorios a los 10 PLCs.

Registros de control corrompidos. La planta ya no responde como debe.


Por qué es tan peligroso

Modbus/TCP no tiene autenticación

Cualquier dispositivo en la red puede escribir en un PLC. No hay handshake, no hay verificación de identidad, no hay cifrado. El protocolo fue diseñado en 1979 para redes confiables.

Confianza heredada

El SCADA comprometido hereda la confianza total del sistema. Los PLCs obedecen sin cuestionar. Si la orden viene del SCADA, se ejecuta.

C2 invisible

El canal de comando y control viajó por TLS. Sin inspección DPI, es invisible para cualquier monitor de red convencional.

Velocidad

Todo el ataque tomó menos de 70 segundos desde el primer movimiento visible. Para cuando un operador nota algo, los registros de control ya están corrompidos.


Las lecciones

El tráfico normal es el mejor camuflaje

Las 844 lecturas Modbus legítimas de los primeros 33 segundos son el camuflaje perfecto. El atacante espera a que el patrón de tráfico normal esté establecido antes de actuar.

DNS y TLS saliente desde OT son alarmas

En una red OT correctamente segmentada, no debería haber tráfico DNS directo ni conexiones TLS salientes. Cualquiera de estas señales debería disparar una alerta inmediata.

Sin segmentación, un equipo = toda la planta

Comprometer un solo equipo en una red OT plana equivale a comprometer toda la infraestructura. La segmentación IT/OT no es una buena práctica — es la diferencia entre un incidente contenido y un desastre operacional.

IDS-OT no es opcional

La detección de anomalías de protocolo industrial es un control fundamental en infraestructura crítica. Un IDS que entienda Modbus puede detectar los 56 comandos FC16 anómalos en tiempo real.


Mapeo MITRE ATT&CK for ICS

FaseTécnicaID
Initial AccessExploit Public-Facing ApplicationT0819
Command & ControlStandard Application Layer ProtocolT0869
DiscoveryNetwork Service ScanningT0841
Lateral MovementRemote Services (SSH)T0886
ImpactManipulation of ControlT0831
ImpactLoss of ControlT0827

Controles de mitigación

  1. Segmentación de red con DMZ industrial entre IT y OT
  2. Monitoreo de protocolos industriales con IDS especializado (Claroty, Nozomi, Dragos)
  3. Restricción de tráfico saliente desde la red OT — sin DNS directo, sin TLS no autorizado
  4. Autenticación en SCADA — no depender solo de la confianza de red
  5. Baseline de comportamiento — detectar desviaciones del patrón normal de comunicación Modbus
  6. Inspección TLS en el perímetro IT/OT para identificar canales C2

La conclusión

Entender cómo se gesta un ataque es el primer paso para detenerlo.

Este escenario es simulado. Pero los protocolos, las vulnerabilidades y las técnicas son exactamente las mismas que existen en plantas reales operando hoy.

Entorno de simulación controlado — de uso exclusivamente educativo.

SV
Autor

Sebastián Vargas

CISO & Fundador de TTPSEC SpA. Más de 15 años en ciberseguridad, governance, riesgo y compliance. Escribiendo sobre seguridad de la información desde 2018.

¿Te sirve el contenido?

Recomendarme en LinkedIn
Volver al archivo