Forescout Vedere Labs publicó el 1 de septiembre de 2026 un experimento controlado en el que un investigador, apoyado por modelos de IA, adaptó un exploit funcional de ejecución remota de código entre dos controladores lógicos programables WAGO. El resultado no demuestra que una IA pueda atacar por sí sola una planta industrial: demuestra que la distancia entre una vulnerabilidad conocida y una variante utilizable contra otro equipo puede empezar a reducirse.
El punto de partida fue CVE-2021-31886, un desbordamiento de búfer previo a la autenticación en el servidor FTP Nucleus utilizado por determinados PLC. Ya existía un exploit para el modelo WAGO 750-852. El equipo logró portarlo al WAGO 750-831 con firmware V01.04.16 y ejecutarlo contra un dispositivo físico de laboratorio. Para llegar allí necesitó análisis humano, desensamblado, correcciones explícitas y varios intentos fallidos.
La prueba duró ocho horas y 32 minutos en su etapa final y consumió 535,74 dólares en tokens de API. Es una cifra relevante, pero no debe leerse como el precio universal de comprometer un PLC: corresponde a un exploit, una versión concreta y un objetivo de prueba. Aun así, ofrece una señal para fabricantes, operadores de agua, energía, manufactura y edificios: las vulnerabilidades antiguas no pierden importancia cuando una herramienta nueva facilita adaptar conocimiento ofensivo existente.
Qué hizo exactamente Forescout con la IA y los PLC
Los investigadores eligieron dos controladores de la misma familia, pero con diferencias suficientes en memoria, firmware y arquitectura de software para que el exploit original no funcionara sin modificaciones. El objetivo no era pedir a un modelo que inventara un ataque desde cero. Era medir cuánto podía ayudar a trasladar una técnica conocida desde el WAGO 750-852 hacia el WAGO 750-831.
El entorno combinó Claude Code, acceso a terminal, Ghidra para ingeniería inversa y un PLC real. Los primeros intentos con Claude Sonnet 4.6 siguieron una hipótesis incorrecta, produjeron un exploit inválido y provocaron un fallo del dispositivo. Después, el investigador cambió a Claude Opus 4.6 con una ventana de contexto mayor y le entregó fragmentos de desensamblado, observaciones del comportamiento y correcciones sobre la ruta que debía analizar.
Con esa intervención, el sistema identificó las diferencias necesarias y produjo shellcode ARM capaz de obtener ejecución remota sin credenciales. Una vez resuelto el obstáculo principal, generó rápidamente cargas de red funcionales. La velocidad posterior no borra el trabajo previo: la parte difícil fue encontrar el desplazamiento correcto, entender el entorno y distinguir un bloqueo accidental de una ejecución controlada.
Lo que la prueba demuestra y lo que no
| Hallazgo | Interpretación correcta | Conclusión que debe evitarse |
|---|---|---|
| El exploit fue adaptado en 8 h 32 min. | La IA puede acelerar partes de una labor especializada cuando recibe herramientas, contexto y revisión. | “Cualquier atacante puede vulnerar cualquier PLC en ocho horas”. |
| Hubo RCE sin credenciales. | Una debilidad previa a la autenticación puede conceder control del dispositivo expuesto. | “Existe una campaña activa contra plantas de agua”. |
| El modelo produjo cargas funcionales. | Después de resolver la causa técnica, automatizar variantes puede ser mucho más rápido. | “La IA descubrió y ejecutó el ataque completo de forma autónoma”. |
| Un intento dejó inoperable el PLC. | La experimentación ofensiva en OT puede afectar disponibilidad y exige aislamiento físico. | “Más automatización siempre produce un exploit mejor y estable”. |
La última fila es especialmente importante. Cuando el equipo intentó extender el resultado hacia un implante con mando y control, el dispositivo quedó inutilizable. En tecnología operativa, un fallo de disponibilidad no es solo un error de laboratorio: en producción puede alterar un proceso, detener una línea o exigir recuperación manual. Por eso las pruebas deben usar réplicas, ventanas aprobadas, límites técnicos y un procedimiento de retorno.
Por qué cambia la lectura del riesgo OT
Muchas organizaciones priorizan vulnerabilidades industriales con una fórmula estática: antigüedad, puntuación CVSS y disponibilidad de un exploit público. El experimento sugiere añadir una variable dinámica: la facilidad con la que conocimiento existente puede adaptarse a una versión vecina. Un fallo sin prueba pública exacta para el firmware instalado no debería considerarse automáticamente inexplotable.
Esto tampoco convierte cada CVE histórica en una emergencia. La probabilidad real depende de si el servicio vulnerable está activo, si el atacante puede alcanzarlo, qué privilegio obtiene, qué función controla el equipo y qué barreras existen entre la red corporativa y el proceso físico. Una evaluación de vulnerabilidades útil debe combinar versión, configuración, exposición, rutas de red y consecuencia operativa; una lista de identificadores no basta.
El valor de negocio aparece al conectar esos elementos. Un PLC que gobierna una función redundante, aislada y recuperable tiene un perfil distinto de otro que controla dosificación, presión, temperatura o protección de maquinaria. La dirección necesita saber qué escenario puede interrumpir producción, comprometer seguridad física o contaminar datos usados por operadores y sistemas de supervisión.
FTP, servicios heredados y exposición innecesaria
CVE-2021-31886 afecta una función FTP, un protocolo frecuente en dispositivos antiguos para transferencia y mantenimiento. Si el servicio no es necesario para la operación normal, mantenerlo accesible amplía la superficie sin aportar valor continuo. La primera decisión no siempre es instalar un parche durante una ventana compleja; puede ser deshabilitar el servicio, restringirlo a una estación de ingeniería o bloquearlo en la zona industrial.
El mismo análisis debe aplicarse a Telnet, administración web, protocolos de descubrimiento y acceso remoto de proveedores. Cada servicio necesita una justificación, un propietario y una ruta autorizada. Las conexiones temporales deben caducar. Los equipos de soporte no deberían alcanzar directamente todos los controladores desde una VPN general; conviene usar saltos controlados, grabación de sesión, privilegio mínimo y aprobación vinculada a una orden de trabajo.
Cuando un firmware no puede actualizarse de inmediato, la compensación debe ser verificable. Una regla de firewall que existe en un diagrama, pero no bloquea desde todas las rutas, crea una falsa tranquilidad. El inventario debe incluir las interfaces activas, las versiones reales y las dependencias necesarias para restaurar el dispositivo si una prueba o un incidente lo deja fuera de servicio.
Cómo priorizar los PLC durante los próximos siete días
- Localizar el activo. Identificar modelos WAGO y otros PLC con Nucleus FTP, confirmar firmware, función física, responsable y repuestos disponibles.
- Comprobar alcance. Verificar desde qué redes, estaciones, VPN y accesos de terceros se llega a FTP y a las interfaces de administración.
- Reducir servicios. Deshabilitar funciones no utilizadas o limitar origen, horario y usuario mediante controles externos al PLC.
- Revisar la corrección. Contrastar el aviso del fabricante y la compatibilidad del firmware antes de intervenir un proceso productivo.
- Preparar recuperación. Respaldar lógica, parámetros y configuraciones; validar el procedimiento de restauración en un equipo equivalente.
- Definir vigilancia. Alertar sobre sesiones FTP inusuales, reinicios, fallos repetidos, cambios de programa y comunicaciones salientes no previstas.
La secuencia evita dos extremos: dejar el activo expuesto porque el parche requiere coordinación, o actualizar a ciegas y crear una interrupción. Un Ethical Hacking en OT debe acordar de antemano qué equipos pueden tocarse, qué comandos están prohibidos, cómo se detiene la prueba y quién confirma que el proceso volvió a estado estable.
Señales que deben unir SOC y operaciones
Un intento contra un PLC puede producir indicadores técnicos pequeños antes de generar una consecuencia visible. Entre ellos están conexiones FTP desde un origen que nunca administra el equipo, comandos o longitudes anómalas, reinicios repetidos, cambios de estado, pérdida temporal de comunicación, nuevas conexiones salientes y modificaciones fuera de una ventana autorizada.
El SOC no puede interpretar esas señales sin contexto operativo. Una caída de comunicación durante mantenimiento planificado puede ser normal; la misma caída después de una conexión desde una estación corporativa exige investigación. Conviene correlacionar telemetría de firewall industrial, switches, estaciones de ingeniería, jump servers, VPN, historiadores y sistemas de gestión de cambios.
Cuando el dispositivo ofrece pocos registros, la red se convierte en evidencia. Las capturas selectivas, la línea base de protocolos y el inventario pasivo permiten detectar desviaciones sin instalar agentes en un controlador. También es útil registrar la versión de la lógica y comparar cambios autorizados, siempre con procesos que no interfieran en tiempos críticos.
La IA también necesita gobierno dentro del equipo defensor
Las mismas herramientas pueden ayudar a explicar firmware, resumir avisos, construir consultas de detección o revisar código de dispositivos. Sin embargo, el experimento muestra por qué un resultado plausible no es igual a uno correcto. Sonnet siguió una pista falsa y el investigador tuvo que redirigir el análisis. En defensa, una consulta defectuosa puede ocultar actividad; en una prueba ofensiva, una carga incorrecta puede detener el equipo.
Las organizaciones deberían separar entornos, limitar los datos enviados al modelo, registrar las instrucciones y exigir revisión por una persona competente antes de ejecutar código. Ninguna salida generada debería conectarse directamente a producción. El criterio de aceptación debe incluir seguridad funcional, impacto en disponibilidad, protección de propiedad intelectual y capacidad de reproducir el resultado.
Un Security GAP Assessment puede incorporar estas preguntas al diagnóstico: qué herramientas de IA usan los equipos técnicos, a qué repositorios y consolas acceden, qué información industrial reciben y quién aprueba una acción derivada. El objetivo no es prohibirlas, sino evitar que la velocidad elimine controles que existen por razones operativas.
Lectura para infraestructura crítica en Colombia y España
La publicación no identifica una víctima ni confirma explotación en Colombia o España. Su utilidad regional está en el patrón: agua, manufactura, energía, logística, alimentos y edificios utilizan controladores con ciclos de vida largos, servicios heredados y ventanas limitadas de mantenimiento. La capacidad de adaptar exploits puede crecer más rápido que la renovación del parque instalado.
En Colombia, operadores y proveedores deberían revisar las rutas entre redes empresariales, centros de control, accesos remotos y activos de campo. La responsabilidad no termina en el propietario del PLC: integradores, mantenedores y fabricantes pueden compartir credenciales, estaciones y túneles que cambian la exposición real.
En España, la misma revisión debe alinearse con continuidad, gestión de terceros y obligaciones aplicables al sector, sin convertir el cumplimiento en una lista separada de la ingeniería. Un CISO as a Service puede coordinar operaciones, seguridad, mantenimiento, compras y dirección para traducir el riesgo técnico en prioridades, presupuesto, aceptación formal y ejercicios de respuesta.
Límites de la evidencia pública
Forescout realizó la prueba en un entorno controlado y sobre una combinación específica de hardware y firmware. El tiempo y el coste no pueden generalizarse a otros PLC. El modelo recibió acceso a herramientas, desensamblado y orientación de un especialista; por tanto, el resultado no acredita explotación autónoma.
Tampoco hay evidencia pública, en las fuentes revisadas, de una campaña que utilice esta adaptación. El valor del trabajo es prospectivo: muestra una capacidad que puede madurar y una forma de medir cómo cambia la economía del ataque. La respuesta adecuada es comprobar exposición y recuperación, no atribuir incidentes inexistentes ni ejecutar pruebas sobre producción.
Compruebe si una vulnerabilidad de laboratorio puede alcanzar su proceso
Insylux puede identificar rutas hacia controladores, validar segmentación y servicios, revisar accesos de terceros y diseñar una prueba segura sobre un entorno representativo. El entregable prioriza hallazgos por impacto físico, continuidad y posibilidad real de explotación.
Solicite al Equipo Insylux una evaluación prioritaria de su exposición OT.
Fuentes y alcance
- Forescout Vedere Labs, experimento de portabilidad de exploits para PLC asistido por IA, 1 de septiembre de 2026.
- NIST National Vulnerability Database, registro de CVE-2021-31886.
- Cybersecurity Dive, cobertura independiente del experimento y sus límites, 1 de septiembre de 2026.
Fuentes consultadas el 1 de septiembre de 2026. Los detalles del laboratorio, modelos, tiempos, coste y resultados proceden de Forescout y su cobertura técnica. La priorización, la lectura regional y las recomendaciones son análisis defensivo del Equipo Insylux.
