Protocolos Industriales y sus Vulnerabilidades: Modbus, DNP3, OPC y S7comm

Protocolos diseñados para otro mundo

Los protocolos de comunicación industrial que controlan plantas de energía, fábricas, sistemas de tratamiento de agua y edificios inteligentes fueron diseñados en una era en la que las redes industriales eran circuitos seriales punto a punto, físicamente aislados de cualquier otra red. La seguridad no era una consideración de diseño porque el modelo de amenazas no incluía atacantes remotos.

Estos protocolos, muchos de ellos con más de 30 años de antigüedad, ahora operan sobre Ethernet y TCP/IP, accesibles desde redes corporativas y, en demasiados casos, desde internet. Shodan indexa cientos de miles de servicios Modbus, DNP3, BACnet, EtherNet/IP y S7comm accesibles desde la red pública. Cada uno de estos servicios expuestos es un punto de entrada potencial a un sistema de control industrial.

El malware ICS moderno explota las debilidades inherentes de estos protocolos. Industroyer hablaba IEC 61850, IEC 104 y OPC DA para operar interruptores eléctricos. FrostyGoop usaba Modbus TCP para manipular controladores de calefacción. Stuxnet manipulaba comunicaciones S7comm para reprogramar PLCs. Entender las vulnerabilidades de estos protocolos es esencial para defender infraestructura crítica.

Modbus: el protocolo universal sin seguridad

Historia y funcionamiento

Modbus fue desarrollado por Modicon (ahora Schneider Electric) en 1979 como protocolo serial para la comunicación entre PLCs. Su simplicidad lo convirtió en un estándar de facto de la industria. Existen tres variantes:

• Modbus RTU: comunicación serial (RS-232/RS-485), formato binario compacto
• Modbus ASCII: comunicación serial, formato legible en texto
• Modbus TCP: adaptación para redes TCP/IP, puerto 502

Modbus opera con un modelo cliente/servidor (anteriormente master/slave). El cliente (típicamente un HMI o SCADA) envía peticiones al servidor (PLC, RTU, sensor inteligente). Las operaciones se definen por function codes:

Function Code	Operación	Riesgo
01	Read Coils (leer salidas digitales)	Reconocimiento
02	Read Discrete Inputs (leer entradas digitales)	Reconocimiento
03	Read Holding Registers (leer registros)	Reconocimiento
04	Read Input Registers (leer registros de entrada)	Reconocimiento
05	Write Single Coil (escribir una salida digital)	Manipulación
06	Write Single Register (escribir un registro)	Manipulación
15	Write Multiple Coils (escribir múltiples salidas)	Manipulación masiva
16	Write Multiple Registers (escribir múltiples registros)	Manipulación masiva
43/14	Read Device Identification	Fingerprinting

Vulnerabilidades

Modbus no implementa ningún mecanismo de seguridad:

• Sin autenticación. Cualquier dispositivo que pueda enviar un paquete TCP al puerto 502 puede leer y escribir en el PLC. No hay usuarios, contraseñas ni tokens.
• Sin cifrado. Todo el tráfico viaja en texto plano. Un atacante con acceso a la red puede capturar todas las comunicaciones Modbus.
• Sin verificación de integridad. No hay firmas ni HMACs que protejan los mensajes contra modificación en tránsito.
• Sin control de acceso. No hay forma de restringir qué function codes puede usar un cliente o qué registros puede leer/escribir.

Escenario de ataque

Un atacante con acceso a la red donde opera Modbus TCP puede:

1. Reconocimiento: leer todos los registros del PLC (FC 03/04) para entender el proceso que controla
2. Fingerprinting: usar Read Device Identification (FC 43/14) para identificar fabricante y modelo
3. Manipulación: escribir valores en registros de control (FC 06/16) para alterar setpoints de temperatura, presión, velocidad
4. Sabotaje: forzar salidas digitales (FC 05/15) para abrir/cerrar válvulas, arrancar/parar motores
5. Denegación de servicio: inundar el PLC con peticiones Modbus para saturar su procesador

FrostyGoop (2023) demostró este escenario en el mundo real, usando Modbus TCP para manipular controladores ENCO en sistemas de calefacción en Lviv, Ucrania.

DNP3 (Distributed Network Protocol 3)

Historia y funcionamiento

DNP3 fue desarrollado a principios de los 90 por Westronic (ahora GE) como protocolo para la comunicación entre centros de control SCADA y estaciones remotas (RTUs) en el sector eléctrico y de distribución de agua. Es ampliamente utilizado en Norteamérica y Australia. Opera sobre TCP (puerto 20000) o serial.

DNP3 es más sofisticado que Modbus: soporta comunicaciones no solicitadas (unsolicited responses), timestamps en los datos, múltiples tipos de datos, y un modelo de eventos que reduce el tráfico de red reportando solo cambios.

Vulnerabilidades

DNP3 tiene más funcionalidad que Modbus, pero comparte la ausencia fundamental de seguridad:

• Sin autenticación nativa. DNP3 original no verifica la identidad del remitente. La extensión DNP3 Secure Authentication (SA, IEEE 1815-2012) añade autenticación HMAC, pero su adopción es limitada.
• Sin cifrado. Los datos viajan en texto plano, incluyendo comandos de control.
• Funciones peligrosas. DNP3 incluye funciones como "Cold Restart" (reinicio del dispositivo), "Warm Restart", "Initialize Data" y "Direct Operate" que pueden ser abusadas sin autenticación.
• Complejidad del protocolo. La riqueza de funciones de DNP3 (fragmentación, unsolicited responses, múltiples modos de operación) aumenta la superficie de ataque y la complejidad de monitorización.

DNP3 Secure Authentication

La extensión Secure Authentication (SA) añade autenticación basada en HMAC-SHA256 a los mensajes críticos de DNP3. El problema: requiere gestión de claves entre todas las estaciones maestras y remotas, lo que complica significativamente la operación. Muchos operadores desactivan SA o nunca lo implementan.

OPC DA y OPC UA

OPC DA (OLE for Process Control, Data Access)

OPC DA, desarrollado en 1996 por la OPC Foundation, es un estándar para el acceso a datos de proceso en tiempo real. Está basado en la tecnología COM/DCOM de Microsoft.

Vulnerabilidades críticas de OPC DA:

• Dependencia de DCOM. DCOM es notoriamente inseguro: autenticación débil, puertos dinámicos (dificultan la configuración de firewalls), y un historial extenso de vulnerabilidades de ejecución remota de código.
• Solo Windows. OPC DA solo funciona en Windows, limitando las opciones de hardening.
• Autenticación heredada de Windows. Depende de la autenticación NTLM/Kerberos de Windows, que en entornos OT suele estar mal configurada.

Havex (2013) usó OPC DA para enumerar dispositivos industriales en las redes comprometidas. Industroyer (2016) incluyó un payload específico para OPC DA.

OPC UA (Unified Architecture)

OPC UA, lanzado en 2008, es el sucesor de OPC DA y fue diseñado con la seguridad como prioridad. Es multiplataforma, independiente de COM/DCOM y soporta:

• Autenticación: certificados X.509, usuario/contraseña, tokens
• Cifrado: TLS 1.2/1.3 para la capa de transporte
• Autorización: control de acceso basado en roles (RBAC) a nivel de nodo
• Integridad: firma digital de mensajes
• Auditoría: registro de todas las operaciones de seguridad

A pesar de estas capacidades, las implementaciones reales de OPC UA presentan vulnerabilidades:

• Configuraciones con "Security Mode = None" (sin cifrado ni autenticación) por "simplicidad"
• Certificados autofirmados aceptados sin validación
• Vulnerabilidades en las implementaciones del stack OPC UA (Claroty Team82 ha reportado más de 70 vulnerabilidades en stacks OPC UA de distintos vendors)
• Ataques a la cadena de certificados si la PKI no está correctamente gestionada

S7comm (Siemens S7 Communication)

Funcionamiento

S7comm es el protocolo propietario de Siemens para la comunicación entre estaciones de ingeniería (PCs con software STEP 7/TIA Portal), HMIs y PLCs de las familias S7-300, S7-400, S7-1200 y S7-1500. Opera sobre ISO-TSAP (puerto TCP 102).

S7comm permite operaciones críticas:

• Lectura y escritura de memoria del PLC (inputs, outputs, data blocks, timers, counters)
• Descarga y carga de programas
• Control de estado del PLC (RUN, STOP, RESET)
• Diagnóstico y configuración del hardware

Vulnerabilidades

• Sin autenticación (S7-300/400). Los PLCs S7-300 y S7-400 no requieren autenticación para las operaciones de S7comm. Cualquier dispositivo con conectividad TCP al puerto 102 puede leer/escribir memoria, cambiar el programa o detener el PLC.
• Contraseña débil (S7-1200/1500). Las generaciones más recientes implementan protección por contraseña, pero la contraseña se transmite de forma predecible y existen herramientas públicas para extraerla.
• Sin cifrado. Todo el tráfico S7comm viaja en texto plano, incluyendo el código del programa y los datos de proceso.

Stuxnet explotó S7comm para inyectar su payload en los PLCs S7-315 y S7-417 de Natanz. El rootkit PLC de Stuxnet interceptaba las comunicaciones S7comm para ocultar el código malicioso inyectado.

S7comm Plus

Siemens introdujo S7comm Plus (también llamado S7commPlus o S7-1500 protocol) para la familia S7-1500, con mejoras de seguridad:

• Protección de acceso por contraseña (mejorada respecto a S7-1200)
• Protección de know-how (cifrado de bloques de función)
• Integridad de la comunicación

Sin embargo, investigadores han demostrado bypass de varias de estas protecciones.

IEC 61850 y IEC 104: protocolos del sector eléctrico

IEC 61850

IEC 61850 es el estándar moderno de comunicación para subestaciones eléctricas. Define un modelo de datos abstracto para equipos eléctricos y utiliza MMS (Manufacturing Message Specification) como protocolo de transporte.

Funcionalidades de seguridad:

• IEC 62351 define extensiones de seguridad para IEC 61850 (autenticación, cifrado TLS)
• En la práctica, la adopción de IEC 62351 es baja por complejidad de implementación

Industroyer implementó un cliente IEC 61850/MMS completo para descubrir y operar interruptores eléctricos automáticamente.

IEC 60870-5-104 (IEC 104)

IEC 104 es un protocolo de telecontrol utilizado en el sector eléctrico europeo para la comunicación entre centros de control SCADA y subestaciones remotas. Opera sobre TCP (puerto 2404).

Vulnerabilidades:

• Sin autenticación nativa. Como Modbus, acepta comandos de cualquier fuente que pueda establecer una conexión TCP.
• Sin cifrado. Datos de proceso y comandos de control viajan en texto plano.
• Comandos de control directo. IEC 104 permite enviar comandos de control (single command, double command, setpoint) que operan directamente equipos eléctricos.

Industroyer e Industroyer2 usaron IEC 104 como vector de ataque principal. COSMICENERGY (2023) también interactúa con dispositivos via IEC 104.

IEC 62351-3 define seguridad basada en TLS para IEC 104, pero la adopción es limitada.

BACnet (Building Automation and Control)

BACnet (ASHRAE Standard 135) es el protocolo estándar para sistemas de automatización de edificios: HVAC (calefacción, ventilación, aire acondicionado), iluminación, control de acceso, ascensores. Opera sobre UDP (puerto 47808) y Ethernet.

Vulnerabilidades:

• Sin autenticación. BACnet no requiere credenciales para leer o escribir propiedades de objetos.
• Broadcast por diseño. BACnet/IP usa broadcast para descubrimiento de dispositivos, exponiendo toda la red de automatización.
• Acceso a control. Permite modificar setpoints de temperatura, forzar salidas de HVAC, desbloquear puertas, controlar ascensores.

Un atacante con acceso a la red BACnet puede alterar temperaturas de data centers (causando apagado de servidores), desactivar sistemas de ventilación (riesgo de seguridad para ocupantes), o desbloquear accesos físicos.

EtherNet/IP y CIP

EtherNet/IP (Ethernet Industrial Protocol) es un protocolo industrial que encapsula CIP (Common Industrial Protocol) sobre Ethernet estándar. Utilizado ampliamente por Allen-Bradley/Rockwell Automation y otros fabricantes. Opera sobre TCP/UDP (puerto 44818).

Vulnerabilidades:

• CIP sin autenticación. Los servicios CIP no requieren autenticación para lectura ni escritura.
• Funciones de configuración. CIP permite reprogramar PLCs, cambiar configuraciones y forzar I/O de forma remota.
• Broadcast. La lista de dispositivos EtherNet/IP en la red se obtiene por broadcast, facilitando el reconocimiento.

Tabla comparativa de vulnerabilidades por protocolo

Protocolo	Puerto	Autenticación	Cifrado	Integridad	Usado por malware
Modbus TCP	502	No	No	No	FrostyGoop
DNP3	20000	SA (opcional)	No	SA HMAC (opcional)	No directamente
OPC DA	DCOM dinámico	DCOM/NTLM	No	No	Havex, Industroyer
OPC UA	4840	Sí (X.509, pwd)	Sí (TLS)	Sí (firma)	No conocido
S7comm	102	No (S7-300/400)	No	No	Stuxnet
IEC 61850/MMS	102	No (62351 opcional)	No (62351 opcional)	No	Industroyer
IEC 104	2404	No (62351 opcional)	No (62351 opcional)	No	Industroyer, Industroyer2, COSMICENERGY
BACnet/IP	47808	No	No	No	No conocido
EtherNet/IP	44818	No	No	No	No conocido

Escenarios de ataque por protocolo

Ataque Modbus TCP: manipulación de proceso

1. Atacante accede a la red OT (via compromiso IT/OT o acceso físico)
2. Escanea la red en busca de servicios en puerto 502
3. Envía FC 43/14 (Read Device Identification) para identificar dispositivos
4. Envía FC 03 (Read Holding Registers) para leer la configuración del proceso
5. Identifica registros críticos (setpoints de temperatura, presión, velocidad)
6. Envía FC 16 (Write Multiple Registers) para alterar setpoints a valores peligrosos
7. El PLC ejecuta el nuevo setpoint. El proceso se desvía de parámetros seguros

Ataque IEC 104: control de subestación eléctrica

1. Atacante compromete la estación maestra SCADA o se conecta directamente a la RTU
2. Establece conexión TCP al puerto 2404 de la RTU
3. Envía STARTDT (Start Data Transfer) para iniciar la comunicación
4. Envía comandos de control tipo "Double Command" a IOAs (Information Object Addresses) que controlan interruptores
5. Los interruptores se abren. La subestación queda sin servicio

Ataque S7comm: reprogramación de PLC Siemens

1. Atacante accede a la red donde opera el PLC Siemens S7-300/400
2. Establece conexión COTP al puerto TCP 102
3. Envía petición S7comm para cambiar el estado del PLC a STOP
4. Descarga (upload) el programa actual del PLC
5. Modifica el programa (inyección de código malicioso)
6. Carga (download) el programa modificado al PLC
7. Cambia el estado a RUN. El PLC ejecuta el código malicioso

Detección: Zeek y Suricata para tráfico ICS

Zeek (anteriormente Bro)

Zeek es un framework de monitorización de red que incluye parsers para múltiples protocolos industriales:

• Modbus: analiza function codes, registros leídos/escritos, valores
• DNP3: analiza tipos de datos, function codes, objetos
• S7comm: analiza operaciones de lectura/escritura y cambios de estado

Zeek genera logs estructurados que permiten crear alertas basadas en:

• Function codes de escritura fuera de horario de mantenimiento
• Comunicaciones desde IPs no autorizadas
• Volúmenes anómalos de peticiones de lectura (reconocimiento)
• Cambios de estado del PLC (STOP/RUN) no planificados

Suricata con reglas ICS

Suricata soporta reglas específicas para protocolos industriales:

Reglas del Emerging Threats ICS ruleset que detectan:

• Escaneo de dispositivos Modbus (Read Device Identification)
• Comandos de escritura Modbus (FC 05, 06, 15, 16)
• Reinicio de dispositivos DNP3 (Cold/Warm Restart)
• Comunicaciones S7comm sospechosas
• Comandos IEC 104 de control

Ejemplo conceptual de regla Suricata para Modbus:

Detección de escritura masiva en registros Modbus (FC 16, Write Multiple Registers): alertar cuando se detecte un function code 16 desde una IP que no pertenece a la lista de HMIs/SCADA autorizados. Un alto número de registros modificados en una sola petición puede indicar un ataque de manipulación.

Otras herramientas de detección ICS

Herramienta	Tipo	Protocolos soportados
Dragos Platform	Comercial	Modbus, DNP3, IEC 104, IEC 61850, S7comm, OPC, EtherNet/IP, BACnet
Nozomi Networks	Comercial	60+ protocolos industriales
Claroty CTD	Comercial	Modbus, DNP3, S7comm, EtherNet/IP, BACnet, OPC
GRASSMARLIN	Open source (NSA)	Análisis pasivo de redes OT
SCADA Shutdown Tool (detección)	Open source	Modbus, DNP3, IEC 104
Malcolm	Open source (CISA)	Zeek + Suricata + Arkime para ICS

Hardening: cómo proteger protocolos legacy

Estrategia de defensa en profundidad

Los protocolos legacy no pueden securizarse internamente, pero se pueden proteger con capas de seguridad externas.

Capa 1: segmentación de red

• Segmentar la red OT según el modelo Purdue (zonas y conductos IEC 62443)
• Firewalls ICS entre zonas que inspeccionan protocolos industriales (no solo IP/puerto)
• VLANs dedicadas para cada celda de proceso
• No permitir tráfico directo entre red IT y dispositivos de Nivel 1 (PLCs/RTUs)

Capa 2: control de acceso basado en red

• Listas de acceso (ACLs) que limiten qué IPs pueden comunicarse con cada PLC/RTU
• Solo permitir comunicación desde las estaciones HMI/SCADA autorizadas
• Bloquear tráfico de protocolos industriales desde la red IT

Capa 3: monitorización y detección

• Desplegar Zeek + Suricata con parsers ICS en puntos de inspección de la red OT
• Crear baseline de tráfico normal de protocolos industriales
• Alertar sobre cualquier desviación: nuevas conexiones, function codes no habituales, horarios inusuales

Capa 4: túneles seguros

• Para comunicaciones remotas (RTUs en campo, subestaciones remotas), encapsular el tráfico de protocolos industriales en túneles VPN/TLS
• Usar gateways de seguridad ICS que actúen como proxy de protocolo con autenticación

Capa 5: migración a protocolos seguros

• Para nuevas instalaciones, seleccionar OPC UA con Security Mode = SignAndEncrypt
• Activar IEC 62351 para protocolos del sector eléctrico donde esté disponible
• Activar DNP3 Secure Authentication donde los dispositivos lo soporten
• Planificar la migración gradual de protocolos legacy en modernizaciones de planta

Recursos

• MITRE ATT&CK for ICS: Techniques (técnicas de ataque a protocolos ICS)
• NIST SP 800-82 Rev 3 (guía de seguridad OT con cobertura de protocolos)
• IEC 62443 Series (estándar de seguridad para automatización industrial)
• Zeek ICS Protocol Parsers (parsers Zeek para Modbus, DNP3, S7comm)
• Suricata ICS Rules (ET Open) (reglas de detección para tráfico ICS)
• CISA Malcolm (plataforma de análisis de tráfico ICS de CISA)
• OPC Foundation Security (guías de seguridad de OPC UA)
• Claroty Team82 Research (vulnerabilidades en protocolos y stacks ICS)