Investigadores de Forescout lograron que la IA adaptara un buffer overflow entre dos modelos de controlador industrial, pero el proceso requirió 8 horas de supervisión experta y terminó con un dispositivo físico permanentemente inutilizado.
Investigadores de Forescout acaban de responder una pregunta que venía circulando en la comunidad de seguridad industrial: ¿puede una IA portar un exploit funcional de un PLC a otro modelo distinto sin acceso a código fuente ni debugger? La respuesta es sí, pero con matices que importan más que el resultado binario. El experimento costó 535,74 dólares en llamadas a la API de Claude, consumió más de ocho horas de trabajo supervisado y culminó con un payload generado por IA que destruyó permanentemente el hardware durante las pruebas de extensión del ataque.
El punto de partida fue CVE-2021-31886, un buffer overflow de pre-autenticación en el servidor FTP Nucleus que el equipo ya había explotado previamente en un PLC WAGO 750-852. El objetivo esta vez era portar ese exploit funcional al modelo WAGO 750-831 versión V01.04.16, un dispositivo relacionado pero con parámetros específicos distintos: direcciones de función, offsets y ubicaciones de memoria que no coincidían con el exploit original. Claude Code recibió acceso a terminal, Ghidra y el dispositivo físico real para realizar el análisis y desarrollo.
Por qué portar firmware embebido es más difícil que explotar software convencional
Trabajar con firmware embebido sin código fuente ni debugger es cualitativamente distinto de los exploits de software que la IA ya había manejado antes. Claude tuvo que probar el servidor FTP en vivo, analizar el binario del firmware con Ghidra y escribir sus propios scripts en Python para asistir el análisis. Eventualmente logró crashear el PLC, confirmando que el buffer overflow podía ser disparado, pero encontrar la vulnerabilidad no fue la parte más difícil.
El verdadero desafío fue pasar de un crash a la ejecución controlada de código del atacante. Ese salto requirió mucho más trabajo y el progreso se ralentizó considerablemente en esa etapa. El punto de inflexión llegó cuando Claude identificó por qué el shellcode inyectado seguía desapareciendo antes de poder ejecutarse: el procesamiento normal de comandos FTP estaba borrando el buffer de memoria que contenía el payload malicioso inmediatamente después de completar el comando de login. La solución fue evitar deliberadamente esa ruta de procesamiento normal omitiendo el terminador CRLF, lo que preservó el buffer controlado por el atacante intacto.
Doce minutos de exploits funcionales después de resolver el problema específico del objetivo
Una vez que Claude resolvió ese problema específico del objetivo, las cosas avanzaron mucho más rápido. En solo doce minutos pasó de un payload de prueba inofensivo a dos exploits funcionales: uno que hacía que el PLC enviara pings ICMP a una máquina remota y otro que enviaba un paquete UDP conteniendo la palabra PWNED. La mayor parte del tiempo y esfuerzo se invirtió en resolver el problema específico del objetivo que impedía la ejecución del payload; después de eso, generar los exploits funcionales fue relativamente sencillo.
El proceso completo de la etapa final de desarrollo del exploit consumió 535,74 dólares en uso de API, basado en 2,6 mil tokens de entrada y 1,3 millones de tokens de salida. La sesión correspondiente duró ocho horas y treinta y dos minutos, distribuidos a lo largo de varios días de investigación. Los investigadores tuvieron que guiar a Claude a través de varios callejones sin salida, proporcionar detalles de desensamblado y cambiar a un modelo de contexto más grande cuando las sesiones más pequeñas se quedaron sin espacio.
Cómo un payload de extensión destruyó permanentemente el dispositivo físico
El momento más revelador del experimento ocurrió después de que el exploit ya funcionaba. Los investigadores pidieron a Claude que extendiera los payloads funcionales de ICMP y UDP en un implante completo de comando y control. Mientras sondeaba el layout de memoria del PLC para construir esa capacidad, uno de los payloads generados escribió en una región mapeada a almacenamiento flash, inutilizando permanentemente el dispositivo. Nadie le dijo a Claude que rompiera nada; estaba haciendo exactamente lo que se le pidió y aun así destruyó el hardware en el proceso.
Este punto de datos es genuinamente inquietante para cualquiera que imagine agentes de IA más autónomos operando contra infraestructura física real con menos supervisión. El hallazgo más importante aquí puede no ser que Claude portó exitosamente el exploit, sino qué tan frágil sigue siendo el proceso y qué tan impredecibles pueden ser las consecuencias cuando la IA opera con acceso a sistemas físicos sin restricciones explícitas sobre qué regiones de memoria o almacenamiento puede modificar.
Exposición estructural en América Latina por dependencia de PLCs sin segmentación
Forescout señala incidentes reales donde atacantes interrumpieron servicios de agua en Estados Unidos abusando de PLCs expuestos a internet directamente, sin necesidad de un exploit sofisticado. Esa observación debería preocupar a los defensores en América Latina, donde la exposición de sistemas de control industrial a internet sin segmentación adecuada es un patrón documentado en sectores como agua, energía y manufactura en países como México, Brasil y Argentina. Si la IA sigue reduciendo el tiempo, costo y expertise necesarios para desarrollar ataques más avanzados contra PLCs, la brecha entre la capacidad de ataque y la madurez defensiva en infraestructura crítica regional se amplía.
El caso del WAGO 750-831 es particularmente relevante porque estos controladores se usan en automatización de edificios y procesos industriales distribuidos, sectores donde la visibilidad de activos y la aplicación de parches en América Latina suelen ser inconsistentes. CVE-2021-31886 fue publicado en 2021; que un exploit portado con IA en 2026 todavía encuentre dispositivos vulnerables en producción no es una hipótesis — es el estado base de muchas redes OT en la región.
Nuestro análisis
El experimento de Forescout no demuestra que la IA haya democratizado el desarrollo de exploits de PLC — todavía requiere supervisión experta, contexto técnico detallado y un presupuesto no trivial — pero sí demuestra que la barrera de entrada está bajando de manera medible. Lo que antes requería semanas de ingeniería inversa manual ahora puede lograrse en horas con guía adecuada, y esa compresión temporal importa en escenarios donde un atacante ya tiene acceso inicial y necesita moverse lateralmente hacia sistemas OT.
El detalle más preocupante no es el éxito del porte sino la destrucción accidental del hardware durante la extensión del ataque. Ese evento sugiere que los modelos actuales de IA no tienen una comprensión robusta de las consecuencias físicas de escribir en regiones de memoria mapeadas a almacenamiento persistente en sistemas embebidos. Si un equipo de investigadores supervisando activamente el proceso no anticipó ese resultado, ¿qué pasa cuando actores menos cuidadosos usen estas herramientas contra infraestructura en producción? La pregunta no es retórica: ya hay precedentes de ataques a PLCs que causaron interrupciones físicas sin intención explícita de destruir hardware, simplemente por falta de comprensión del sistema objetivo. La IA podría acelerar ese patrón sin necesariamente hacerlo más controlable.
¿Cuánto tiempo falta para que un atacante sin experiencia previa en firmware embebido pueda replicar este proceso con menos supervisión y a menor costo, y qué tan preparadas están las redes OT en América Latina para detectar y contener ese tipo de actividad antes de que llegue a sistemas críticos?