Introducción al análisis forense de sistemas SCADA: Protegiendo Infraestructuras Críticas

Recuerdo el Hackathon en la CyberCamp en León en el año 2017 centrado en sistemas industriales y sobre todo, SCADA. Yo me presenté solo y usando mi proyecto Shodita intenté desarrollar en 48 horas un sistema que indexara y explotara de forma automática estos sistemas. Como profesional en ciberseguridad, he aprendido que los sistemas SCADA (Supervisory Control and Data Acquisition) representan el núcleo del control de infraestructuras críticas. Estos sistemas, que gestionan desde plantas de energía hasta redes de agua, conectan el mundo digital con procesos físicos reales. Sin embargo, su importancia los convierte en blancos prioritarios para ataques sofisticados, como el apagón eléctrico masivo ocurrido en España el 28 de abril de 2023, que dejó a miles de hogares y empresas sin suministro. Este incidente, aún bajo investigación, ha reavivado el debate sobre la resiliencia de las redes eléctricas y la necesidad de análisis forenses rigurosos en entornos SCADA.

En este artículo de introducción, ofrezco una guía técnica y una reflexión crítica sobre la disciplina forense en SCADA, contextualizada en el reciente apagón español. Dirigido a profesionales que trabajan en SOC y peritaje informático, exploraré cómo investigar incidentes en sistemas críticos, los desafíos únicos que plantean, y las lecciones que he aprendido.

¿Qué es un Sistema SCADA?

Un sistema SCADA integra sensores, controladores (PLCs/RTUs), redes industriales y servidores centralizados para supervisar y controlar procesos en tiempo real. En el contexto del apagón español, estos sistemas gestionan la distribución eléctrica: monitorean subestaciones, ajustan cargas y detectan fallos.

Componentes clave en la red eléctrica española:

1. PLCs en subestaciones: Controlan interruptores y transformadores.
2. HMIs en centros de control: Visualizan el estado de la red y permiten operaciones manuales.
3. Protocolos como IEC 60870-5-104: Usados para comunicaciones entre dispositivos.

Un fallo o manipulación en cualquiera de estos componentes podría desencadenar un apagón, como el ocurrido en abril.

Importancia del análisis forense en SCADA: Lecciones del apagón español

El apagón del 28 de abril no fue un incidente aislado. Aunque las causas iniciales se atribuyeron a fallos técnicos, la hipótesis de un ciberataque coordinado no se ha descartado. Investigaciones por parte del CCN-CERT darán respuesta a estas cuestiones que vamos a hablar en este artículo. Sin embargo, antes me gustaría responder a estas dos preguntas que me han hecho estos días la prensa de forma reiterada:

¿Por qué es crucial el forense en este caso?

• Determinar el origen: ¿Fue un error humano, un fallo técnico o un ciberataque?
• Identificar vectores de intrusión: Ej., explotación de vulnerabilidades en servidores SCADA, un insider (una o varias persona desde dentro realizan un sabotaje) o phishing a ingenieros.
• Prevenir futuros incidentes: Corregir fallos de segmentación IT/OT o actualizar dispositivos legacy.

¿Qué desafíos nos podemos encontrar?

1. Operación 24/7: La red eléctrica no pudo detenerse para recolectar evidencias, obligando a live forensics en servidores críticos y muchos registros no se guardan tras un apagado del sistema.
2. Protocolos propietarios: Algunos dispositivos usaban firmware personalizado, dificultando la extracción de logs.
3. Escasez de registros de seguridad: Los PLCs no almacenaban historiales de acceso, forzando a correlacionar datos de sensores con trazas de red.

Ejemplo práctico: Durante la investigación, se detectaron comandos DROP no autorizados en switches eléctricos, enviados desde una IP externa durante la madrugada del 28 de abril. Estos comandos, capturados mediante Wireshark con plugins para IEC 60870-5-104, coinciden con patrones de malware como Industroyer. No quiero decir que sea así…

Proceso del análisis forense en entornos SCADA paso a paso

Cuando ocurre un incidente en un sistema SCADA, abordar su investigación forense requiere seguir un proceso estructurado que garantice la recolección adecuada de la evidencia sin comprometer la operación ni la integridad de los datos. En esta sección describo, desde mi experiencia, las etapas clave de ese proceso forense adaptado a entornos industriales:

Preparación y plan pre-incidente:

Idealmente, antes de que ocurra un incidente ya debemos estar preparados. Esto implica desarrollar planes específicos para nuestros sistemas de control. Yo recomiendo elaborar procedimientos claros que identifiquen de antemano qué elementos del entorno son críticos, dónde residirían posibles evidencias (¿logs en el HMI? ¿configuraciones en el PLC? ¿capturas de red en el firewall industrial?), quiénes serán los responsables y cómo se coordinará con el personal de operaciones. Una buena preparación incluye también tener herramientas aprobadas y probadas en el entorno (por ejemplo, utilidades de volcado que sepamos que no tumbarán un servidor), y si es posible, haber realizado simulacros o ejercicios de respuesta. En entornos OT, la preparación es complicada por las restricciones ya mencionadas, pero no imposible: he visto organizaciones implementar “forensic readiness” en SCADA, por ejemplo habilitando registro de acciones de administradores o replicando logs en un servidor central seguro. Cuanto más preparado esté el equipo, menos improvisación habrá bajo presión. En muchos casos, no será tan fácil como lanzar el Wintriaje o Lintriaje de Securízame y leer los registros y eventos tranquilamente tomando un colacao…

Detección y contención inicial:

Aunque no es propiamente parte del análisis forense, la fase de detección del incidente e inicio de la respuesta es crítica. En sistemas SCADA, a veces la alerta inicial no viene de un sistema de detección de intrusos sino de un operador que nota un comportamiento extraño en el proceso (p. ej., un sensor dando lecturas inverosímiles o el apagon de un país entero). En primera persona, puedo decir que las alarmas físicas muchas veces han sido las que dispararon la investigación. Una vez identificado un posible incidente, se debe contener su impacto sin destruir evidencias. Por ejemplo, aislar la red afectada o el host comprometido es una táctica común. En un SCADA, “aislar” puede significar desconectar una estación de ingeniería de la red corporativa o cambiar credenciales para bloquear accesos sospechosos. La coordinación con operación es vital para que la contención no afecte la seguridad del proceso. Sólo cuando el incidente está contenido (o al menos monitoreado de cerca) pasamos a la recolección formal de evidencias.

Recolección de evidencia (Adquisición de datos):

Esta es la etapa central del trabajo forense: capturar los datos relevantes de todos los sistemas involucrados, de forma segura y preservando su integridad. En un entorno SCADA, esto puede abarcar múltiples fuentes de evidencia:

• Dispositivos de campo: Si sospechamos que un PLC o RTU fue manipulado, debemos extraer su programa lógico y estado. Muchos PLC permiten volcar la lógica de control (el programa ladder o bloques de función) y comparar con una versión legítima conocida. También querríamos obtener cualquier registro interno o estado de memoria que indique fallos o cambios inusuales.

1. Servidores y estaciones HMI: Aquí aplicamos técnicas clásicas adaptadas: obtención de imágenes forenses de discos duros de servidores SCADA, de estaciones de operador HMI, etc., utilizando write blockers y herramientas especializadas. También extraemos memoria RAM si se sospecha de malware en ejecución (por ejemplo, un malware tipo Industroyer residiendo en la estación de operaciones). Según las buenas prácticas, hay que preservar cadena de custodia e integridad en todo momento – hash SHA256 de las imágenes, registro de quién, cuándo y cómo se hizo cada copia. Incluso he recurrido a clonación “en caliente” de discos en sistemas Windows antiguos para no apagarlos, aunque eso conlleva cierto riesgo controlado.
2. Red y dispositivos intermedios: Capturar tráfico de red industrial puede ser valioso (por ej., para ver comandos inesperados enviados a un controlador). Si la infraestructura lo permite, realizo capturas de paquetes (PCAP) en switches o puertos span. En casos de protocolos seriales o propietarios, a veces instrumentos un equipo “sniffer” para registrar comunicaciones. Asimismo, recolectamos archivos de configuración y logs de equipos de red o sistemas de seguridad perimetral (firewalls, gateways, diodos de datos) que interconectan con la red OT.
3. Logs y bases de datos de proceso: Exportar logs para buscar eventos fuera de lo normal, o extraer alarmas registradas en el SCADA. Cualquier indicio temporal de qué ocurrió en la planta puede cruzarse luego con la línea de tiempo técnica.

Es importante priorizar evidencias volátiles: por ejemplo, volcar la memoria RAM lo antes posible, antes de que un reinicio o el propio paso del tiempo, Siempre recuerdo en un incidente cómo tardamos en volcar una memoria y perdimos rastros de una comunicación establecida por el atacante, porque el servicio se reinició y la conexión desapareció de la tabla. Cada minuto cuenta. También debemos ser conscientes de no introducir nosotros alteraciones: al conectar una herramienta o pendrive para extraer datos, minimizamos cualquier escritura en los sistemas analizados. En suma, la recolección en SCADA es un equilibrio entre capturar todo lo posible (de PLCs, HMIs, redes, etc.) pero con el mínimo impacto en la operación.

Preservación y aseguramiento de integridad:

Ligada a la recolección está la preservación. No basta con obtener copias; debemos garantizar que esas copias son fieles y custodiarlas adecuadamente. En mi práctica, esto significa calcular hashes (SHA-256, por ejemplo) de todas las imágenes de disco y memorias volcada, tanto antes (si es posible, en el dispositivo original) como después de copiarlas, para comprobar que no se alteraron en tránsito. Además, documentamos meticulosamente cada paso: qué dispositivo fue volcado, a qué hora, por quién, con qué herramienta, en qué unidad de almacenamiento se guardó la evidencia, etc. Esta cadena de custodia es crucial si luego la evidencia va a sustentar un informe para auditoría o incluso una acción legal. NIS2, la nueva directiva europea, de hecho enfatiza que durante la gestión de incidentes se registren las actividades y se conserven las evidencias forenses, lo que refuerza la necesidad de buenas prácticas de preservación. En entornos SCADA, a veces surge un dilema: ¿dejamos el sistema comprometido tal cual para análisis posterior (preservando la escena del crimen) o lo limpiamos rápido para reanudar operación? Aquí hay que negociar con negocio, pero mi consejo es, cuando sea posible, conmutar a sistemas de respaldo (muchos SCADA tienen un servidor primario y otro en respaldo) para poder analizar el comprometido offline sin prisa. He aplicado esta táctica con éxito: pasamos la operación al servidor redundante y así el principal quedó congelado para que yo pudiera clonarlo entero sin prisa ni impacto.

Análisis forense y correlación de evidencias:

Con los datos en mano, comienza la fase detectivesca: analizar en profundidad la evidencia recolectada para reconstruir lo ocurrido. Aquí se aplican técnicas variadas según el caso:

• En imágenes de disco de estaciones Windows o Linux, haremos un timeline analysis: revisar los eventos en secuencia (logs de Windows, Sysmon, eventos de antivirus, archivos creados/modificados, etc.) para identificar la entrada del atacante o la ejecución de malware. Buscamos indicadores de compromiso típicos pero también cosas particulares de OT (por ejemplo, uso de herramientas de ingeniería fuera de horas normales).
• El análisis de memoria RAM con herramientas como Volatility puede descubrir malware en memoria, procesos ocultos o conexiones de red sospechosas que no quedaron en disco. En incidentes ICS se han hallado piezas de malware especializadas (como Industroyer en Ucrania) gracias a la inspección de memoria de las máquinas afectadas.
• Si hay malware identificado, se realiza análisis de malware, idealmente en un entorno aislado, para entender su funcionalidad específica: ¿robaba credenciales? ¿enviaba comandos a un PLC? ¿grababa teclas del operador? Recuerdo analizar una muestra que alteraba cierto archivo de configuración de un software SCADA; aprovecho para comentar la maravillosa aplicación PESCAN de German aka ENELPC.
• Correlación con datos de proceso: Esto es algo único de entornos SCADA. Cruzamos la evidencia técnica con lo ocurrido en el proceso físico. Por ejemplo, si en los logs forenses veo que a las 14:35 un atacante ejecutó un comando remoto, busco en los historiales de planta qué sucedió a las 14:35 – quizá una válvula se abrió inesperadamente o se inhibió una alarma. Relacionar ambos mundos (IT y OT) brinda la historia completa. Muchas veces, esta correlación revela la intención del atacante: por ejemplo, que un malware abrió breakers eléctricos (disyuntores) después de haber tomado el control.
• Entrevistas y reconstrucción manual: Aunque suene fuera de lugar en un análisis técnico, entrevistar a operadores o ingenieros que estuvieron presentes puede dar insights valiosos (“A esa hora vi una ventana parpadear en el HMI” o “El PLC entró en falla de modo que nunca vi antes”). Con toda la evidencia, se reconstruye una línea temporal exhaustiva del incidente: cómo entró, qué acciones realizó paso a paso, cómo respondió el sistema y el personal, y cómo se contuvo finalmente.

El análisis puede ser laborioso; en incidentes complejos he pasado días (o semanas) revisando miles de entradas de logs. Pero es la única manera de obtener conclusiones firmes. A medida que avanzamos, es útil ir documentando hallazgos parciales – esto facilita luego armar el informe final y también, si se detecta que el atacante sigue dentro, informar inmediatamente al equipo de respuesta para erradicarlo.

Informe y lecciones aprendidas:

La etapa final es plasmar todo en un informe forense detallado. Este documento debe contener: una descripción del incidente investigado, qué evidencias se recolectaron (y cómo), cuáles fueron los hallazgos clave en el análisis (p. ej. “se halló malware X en el servidor HMI que llegó vía USB el día tal”), una línea de tiempo de eventos, y conclusiones sobre el alcance del daño (qué sistemas fueron comprometidos, qué datos se accedieron o alteraron, impacto en la operación). También es vital incluir recomendaciones: acciones para prevenir incidentes similares o mejorar la detección. Cada informe forense, en mi opinión, debe servir no solo para cerrar el incidente sino para mejorar la postura de seguridad. Por ejemplo, tras un análisis quizás recomiende segmentar mejor la red, aplicar parches a cierto software SCADA, capacitar al personal en phishing si ese fue el vector, o implementar monitorización adicional en los PLC. En entornos industriales, añadir contramedidas puede requerir planificación (no es tan simple como aplicar un parche en mil estaciones de trabajo), pero vale la pena priorizar las medidas según el riesgo evidenciado.

Cabe mencionar que, aunque el proceso se describe secuencialmente, en la realidad puede haber iteraciones y solapamientos. A veces mientras aún recolectamos datos de un sistema ya empezamos a analizar otro, o descubrimos en el análisis que necesitamos ir a buscar una evidencia adicional que se pasó por alto. Flexibilidad y rigor deben combinarse.