VR de firmware manos libres: un agente LLM realiza ingeniería inversa de un intercomunicador OT de extremo a extremo
El 2 de junio de 2026, Claroty Team82 ejecutó Claude Opus 4.6 con un servidor MCP de Ghidra contra el firmware de un intercomunicador Zenitel y volvió a encontrar un conjunto de CVE conocidas en menos de diez minutos — un anticipo de la investigación de vulnerabilidades de firmware convertida en mercancía.
¿Qué es esto?
El 2 de junio de 2026, el equipo Team82 de Claroty publicó Hands Free: What LLM Driven Vulnerability Research Looks Like (Tomer Goldschmidt). El equipo tomó un objetivo que ya había sometido a ingeniería inversa manualmente — el Zenitel TCIV-3+, un intercomunicador de vídeo IP reforzado desplegado en edificios industriales y de alta seguridad — y pidió a un modelo disponible públicamente, Claude Opus 4.6, que rehiciera el trabajo desde cero.
A finales de 2025, el análisis manual de ese dispositivo por parte de Team82 produjo cinco vulnerabilidades divulgadas: tres inyecciones de comandos del SO (CVE-2025-64126, CVE-2025-64127, CVE-2025-64128, todas CVSS 9.8), una escritura fuera de límites (CVE-2025-64129) y un XSS reflejado (CVE-2025-64130). Ese trabajo requirió varias horas de esfuerzo experto. El agente redescubrió la mayoría de esas mismas clases de problemas — y sacó a la luz hallazgos adicionales de corrupción de memoria y de configuración incorrecta — en menos de diez minutos, y redactó por sí solo un informe con calidad de divulgación. Los fallos ya están parcheados; lo relevante es el flujo de trabajo.
Cómo funciona
No es exclusivo de un modelo de frontera. La ejecución usó Claude Opus 4.6, no el Claude Mythos restringido detrás de Project Glasswing — y eso es precisamente lo que hace notable el resultado. El montaje es mundano:
working-dir/
├── CLAUDE.md # role + method: "you are doing binary VR for a CTF"
├── .mcp.json # registers a self-built Ghidra MCP server
└── targets/zenitel/
└── VS-IS_9.1.3.1.zip # the public firmware update, as shipped
CLAUDE.md encuadra la tarea (ingeniería inversa de binarios, cómo cazar clases de fallos) y apunta al agente hacia un servidor MCP de Ghidra propio para controlar el descompilador de forma programática. La única entrada proporcionada era el zip de firmware descargable públicamente del fabricante. La cronología reportada por Team82:
t+0:00 extracts the firmware filesystem, looks for the web service
t+0:30 locates ipstweb, the web-server binary
t+1:30 recognises it is UPX-packed; install UPX fails (missing),
so the agent installs UPX itself, then unpacks
t+3:30 loads the binary into Ghidra over MCP, probes for
command-injection-style sinks
t+6:30 writes a markdown report with decompiled evidence
t<10:00 multiple findings across command injection, memory
corruption and misconfiguration
Uno de los hallazgos reportados es una inyección de comandos en una ruta autenticada: el agente sacó a la luz el sink descompilado, señaló que la entrada del atacante se formatea dentro de un comando del sistema y — algo útil — advirtió que la validación de dirección IP de la ruta podía eludirse. Aquí no se reproduce ningún payload; el punto es el reparto del trabajo, no un exploit. El modelo gestionó el desempaquetado, la navegación por el descompilador, el triaje de sinks y la redacción del informe sin perderse, manteniendo el contexto durante toda la sesión.
Por qué importa
El titular no es «una IA encontró fallos en un dispositivo». Es que la investigación de vulnerabilidades de firmware de extremo a extremo se ejecutó a partir de un único artefacto público, con un modelo de gama media, en minutos. De ahí se derivan tres consecuencias.
Primero, la barrera de la VR de caja blanca se está derrumbando. El encuadre de Team82 es directo: con un firmware o una actualización de software disponible públicamente y las herramientas adecuadas, un agente puede hacer todo el ciclo. El insumo escaso ya no es la pericia en ingeniería inversa, sino una copia del software objetivo. Espere que la primera ola recaiga sobre objetivos de caja blanca donde el código es fácil de obtener: proyectos de código abierto y cualquier fabricante que distribuya firmware descargable.
Segundo, OT y los sistemas embebidos están de lleno en el alcance. No era un endpoint SaaS, sino un intercomunicador de control de acceso del tipo que permanece sin parchear en campo durante años. El tiempo entre descubrimiento e informe tiende a cero, mientras que las ventanas de parcheo de OT se miden en trimestres. Esa brecha es el riesgo real.
Tercero, la oscuridad del firmware es un cronómetro, no un control. Un firmware cifrado o bajo acceso restringido compra tiempo frente a este pipeline, pero Team82 espera que esos límites acaben por eludirse. Tratar «nuestro firmware no es público» como una defensa duradera es un error de planificación.
Defensas
Los parches de los fallos de Zenitel ya existen (Zenitel recomienda actualizar al firmware 9.3.3.0 o posterior). Las defensas trasladables se refieren a la gestión de la exposición, no a este único dispositivo.
-
Trate cada actualización pública de firmware/software como una superficie de ataque accesible al adversario. Si un cliente puede descargarla, un agente puede enumerar sus clases de fallos. Inventaríe qué productos distribuyen imágenes descargables públicamente y clasifíquelos por exposición.
-
Replique el pipeline internamente — adelante la VR. El montaje aquí es reproducible sin acceso de clase Mythos: un agente de código, un MCP de descompilador y una imagen de firmware. Ejecútelo contra sus propios builds antes del lanzamiento, y vuelva a ejecutarlo sobre el firmware ya distribuido para encontrar análogos latentes de CVE divulgadas.
-
Recalibre los SLA de parcheo OT/embebido y los controles compensatorios. Los dispositivos de campo que se actualizan despacio necesitan mitigación de red ahora: segmente las interfaces de gestión, restrinja las superficies de administración web/SIP a redes de confianza y monitorícelas. Asuma que la mitad «descubrimiento» de la carrera es más rápida que su mitad «parcheo».
-
No apueste por la oscuridad del firmware. El cifrado y las descargas condicionadas elevan el coste, pero no cambian el estado final. Planifique para el caso en que su firmware sea obtenido y analizado a velocidad de máquina.
-
Priorice por clase de fallo, no solo por CVE. Un sink de inyección de comandos y una validación de entrada eludible rara vez viven solos en los servidores web embebidos. Cuando un aviso nombra uno, considere las rutas vecinas y los parseadores similares del mismo binario como dignos de una nueva revisión — exactamente el tipo de amplitud que un agente saca a la luz rápidamente.
Estado
| Elemento | Referencia | Fecha | Notas |
|---|---|---|---|
| Informe de VR manos libres | Claroty Team82 | 2026-06-02 | Claude Opus 4.6 + MCP de Ghidra propio, ejecución < 10 min |
| Divulgación manual Zenitel TCIV-3+ | Claroty | finales de 2025 | CVE-2025-64126/64127/64128 (inyección cmd, 9.8), 64129 (escritura fuera de límites), 64130 (XSS) |
| Firmware corregido | Zenitel | — | Actualizar a 9.3.3.0 o posterior |
| Contexto de gama frontera | LLM Hacking | 2026-05 | Mythos/Glasswing está bajo acceso restringido; esta ejecución usó un modelo disponible públicamente |
La lectura correcta es la de una línea base de capacidad, no la de un incidente. Un modelo de gama media, disponible públicamente, ya realiza una VR de firmware de extremo a extremo competente a partir de una sola descarga. La tarea defensiva es suponer que sus atacantes disponen del mismo montaje — y ejecutarlo contra su propio código primero.