Cinco agencias del gobierno de Estados Unidos —NSA, CISA, FBI, el Departamento de Energía y la EPA— firmaron el 19 de agosto una advertencia conjunta que conviene leer despacio: alguien está recorriendo internet en busca de PLCs Siemens S7 expuestos y atacándolos con scripts de explotación generados con IA, disfrazados de herramientas legítimas de monitoreo. No es un informe de tendencias ni un ejercicio de red team. El advisory AA26-231A usa una frase que las agencias no reparten a la ligera.
"Esto no es un riesgo teórico: es una amenaza activa." — Advisory AA26-231A, NSA / CISA / FBI / DOE / EPA
Qué pasó
Los actores no descubrieron nada nuevo. Ese es justamente el punto.
La cadena que describen las agencias es de una simplicidad incómoda: usan servicios de escaneo comerciales —Censys, ZoomEye— para localizar PLCs Siemens colgados de internet con firmware viejo o autenticación sin configurar. Sobre esos objetivos lanzan scripts en Python construidos con python-snap7, una librería open source de automatización industrial que cualquiera puede instalar con un pip install, y que habla el protocolo nativo S7comm. Con eso obtienen lectura y escritura sobre memoria del PLC, bloques de datos, configuración y programas de ladder logic.
El detalle que cambia la ecuación es quién escribió esos scripts. No un especialista en ICS con veinte años en planta: un modelo de lenguaje, iterando rápido sobre documentación pública de los S7. Las agencias lo señalan como una "evolución" en las capacidades del adversario porque reduce drásticamente el tiempo y la expertise necesarios para producir tooling funcional contra sistemas industriales.
Y hay un segundo detalle deliberado: los scripts se hacen pasar por herramientas de monitoreo OT legítimas. Para un SOC que no conoce el inventario de su planta, un proceso leyendo data blocks vía S7comm se ve exactamente como el software del integrador.
Por qué importa
La barrera de entrada al ataque industrial siempre fue el conocimiento del dominio. Explotar un S7-300 no es como tirar un WordPress: hay que entender el protocolo, la lógica del proceso, qué pasa físicamente cuando escribes un valor fuera de rango. Ese conocimiento era el foso defensivo real de OT, más que cualquier firewall.
Ese foso se está secando. La combinación que describe el advisory —CVEs conocidas + librerías de explotación accesibles + desarrollo asistido por IA— es explícitamente calificada por las agencias como un "escenario de ataque de alta probabilidad" contra instalaciones mal protegidas.
Peor aún es lo que las agencias creen que están haciendo los actores. No exfiltrar, no extorsionar: pre-posicionarse. El patrón de actividad, dicen, es reconocimiento persistente para desarrollar capacidad y prepararse para causar efectos operativos. Están leyendo ahora para saber qué escribir después. Es la misma doctrina que vimos en Volt Typhoon, pero con el costo de desarrollo de tooling recortado por un modelo.
Hay un párrafo del advisory que un SE debería llevar a cada conversación con un cliente industrial: las mitigaciones son especialmente importantes cuando hay integradores o proveedores externos con acceso remoto a los PLCs, porque el dueño del activo muchas veces no sabe que está expuesto. Ese es el caso de la mayoría de las plantas en México y LATAM: el PLC lo puso el integrador, el acceso remoto lo dejó el integrador, y el inventario vive en la cabeza del integrador.
El detalle técnico
Las técnicas van mapeadas a MITRE ATT&CK for ICS v19, lo cual da material directo para detección:
- T1596.005 — búsqueda de objetivos en bases de datos de escaneo (Censys, ZoomEye).
- T1587.004 / T1588.007 — desarrollo y obtención de capacidad de explotación; aquí entra el uso de IA para iterar el exploit.
- T1694 — abuso de credenciales inseguras: dispositivos con autenticación default o mínimamente configurada.
- T0834 — uso de librerías de terceros (snap7) para interactuar con el controlador.
- T0849 — masquerading: el script se presenta como utilería de monitoreo.
- T0893 / T0821 — operaciones de lectura y escritura sobre data blocks, para reconocimiento, prueba de capacidad o pre-posicionamiento.
En la práctica esto se traduce en tres detecciones que sí puedes montar: tráfico S7comm (TCP/102) desde orígenes que no son la HMI ni la estación de ingeniería; escrituras a data blocks fuera de ventana de mantenimiento; y cualquier PLC respondiendo a IPs públicas. Si tienes un NGFW o un sensor OT en el segmento industrial, el patrón de python-snap7 es reconocible: no negocia como el software de Siemens y suele conectar de forma cruda y repetitiva.
Lo que no trae el advisory es igual de relevante: no hay CVE nuevo, no hay atribución a un grupo conocido y no hay un parche que resuelva esto, porque el problema no es una falla puntual sino una superficie expuesta explotada con vulnerabilidades ya publicadas.
El patrón más amplio: agentes que hacen el trabajo completo
Lo de los PLCs no es un caso aislado, y ahí está la parte que me tiene más atento. La semana pasada la firma israelí Dream documentó una intrusión casi autónoma contra entidades de gobierno en Asia; el Financial Times y Reuters identificaron a Taiwán como el objetivo, y el Ministerio de Asuntos Digitales taiwanés confirmó la campaña.
Según el reporte, entre el 1 y el 4 de julio hubo 12 olas de ataque ejecutadas por un framework que orquestaba hasta ocho sub-agentes en paralelo, cada uno con su especialidad: explotación de SSO y ataques a credenciales, bypass de JWT y brute-force de CAPTCHA, reconocimiento de portales, escaneo de APIs y paneles admin, investigación de CVEs y encadenamiento, evaluación de supply chain, password spraying con OCR para resolver CAPTCHAs, y explotación profunda de endpoints. Encontraron endpoints de API no documentados que devolvían una sesión autenticada válida sin importar el cuerpo de la petición, cosecharon usuarios y rompieron 85 cuentas por password spraying. Taiwán habló de un enfoque híbrido: operadores humanos combinados con agentes de IA de uso general.
Junta las dos historias y el mensaje es el mismo desde dos ángulos distintos: el trabajo tedioso del atacante —escribir el script, probar la variante, resolver el CAPTCHA, iterar la cadena— ya se puede delegar. Lo escaso sigue siendo el criterio y el acceso; el volumen ya no cuesta nada.
Qué hacer
Nada exótico, y eso es lo frustrante: todo esto se detiene con higiene de OT que llevamos quince años recomendando.
- Inventaría. Todos los S7, modelo, firmware y quién tiene acceso remoto. Si no puedes nombrar tus PLCs, no puedes defenderlos.
- Saca los PLCs de internet. Verifícalo desde afuera, con Shodan o Censys contra tus propios rangos, no confiando en el diagrama de red. El acceso del integrador va detrás de VPN con MFA y ventana de tiempo, nunca con puerto expuesto.
- Parcha lo parchable y cambia credenciales default; buena parte de lo explotado son CVEs con fix disponible desde hace años.
- Segmenta de verdad. IT y OT separados, y dentro de OT microsegmentación por celda de proceso. El único que debería hablar S7comm con un PLC es la HMI y la estación de ingeniería.
- Monitorea el segmento industrial. Alerta por S7comm de orígenes no autorizados, escrituras fuera de ventana y cambios en ladder logic. Sin visibilidad en OT, el masquerading funciona a la perfección.
- Caza, no esperes. El advisory asume pre-posicionamiento: revisa históricos de conexiones y cambios de configuración, no solo el presente.
Si trabajas con clientes industriales, el gancho de esta conversación cambió esta semana. Ya no es "podría pasar": cinco agencias federales dicen que está pasando, y el atacante ya no necesita un experto en Siemens para intentarlo.
Fuentes
- CISA — Defending Against an Active Threat to Siemens S7 Series PLCs (AA26-231A)
- The Hacker News — AI-Generated Exploit Scripts Target Siemens S7 PLCs in U.S. Critical Infrastructure
- Dream — Inside a multi-agent AI framework used to compromise government entities in Asia
- Reuters — Taiwan says it was targeted last month by AI-driven hacking campaign