VR de firmware mains libres : un agent LLM rétro-ingénie un interphone OT de bout en bout

De quoi s’agit-il ?

Le 2 juin 2026, l’équipe Team82 de Claroty a publié Hands Free: What LLM Driven Vulnerability Research Looks Like (Tomer Goldschmidt). L’équipe a repris une cible qu’elle avait déjà rétro-ingénierée à la main — le Zenitel TCIV-3+, un interphone vidéo IP durci déployé dans des bâtiments industriels et à haute sécurité — et a demandé à un modèle disponible publiquement, Claude Opus 4.6, de refaire le travail de zéro.

Fin 2025, l’analyse manuelle de cet appareil par Team82 avait produit cinq vulnérabilités divulguées : trois injections de commande OS (CVE-2025-64126, CVE-2025-64127, CVE-2025-64128, toutes CVSS 9.8), une écriture hors limites (CVE-2025-64129) et un XSS réfléchi (CVE-2025-64130). Ce travail avait demandé plusieurs heures d’effort expert. L’agent a redécouvert l’essentiel de ces mêmes classes de problèmes — et a fait remonter des findings supplémentaires de corruption mémoire et de mauvaise configuration — en moins de dix minutes, et a rédigé seul un rapport de qualité divulgation. Les bugs sont déjà corrigés ; l’intérêt, c’est le déroulé de travail.

Comment ça marche

Ce n’est pas l’exclusivité d’un modèle frontière. Le run a utilisé Claude Opus 4.6, et non le Claude Mythos restreint derrière Project Glasswing — c’est précisément ce qui rend le résultat notable. L’attelage est banal :

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 cadre la tâche (rétro-ingénierie binaire, comment chasser les classes de bugs) et pointe l’agent vers un serveur MCP Ghidra maison pour piloter le décompilateur par programme. La seule entrée fournie était l’archive firmware publiquement téléchargeable du fournisseur. La chronologie rapportée par 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

Un des findings rapportés est une injection de commande sur une route authentifiée : l’agent a fait remonter le sink décompilé, a noté que l’entrée attaquant est formatée dans une commande système et — fait utile — a signalé que la validation d’adresse IP de la route pouvait être contournée. Aucun payload n’est reproduit ici ; le point est la répartition du travail, pas un exploit. Le modèle a géré le dépaquetage, la navigation dans le décompilateur, le tri des sinks et la rédaction du rapport sans s’égarer, en conservant le contexte sur toute la session.

Pourquoi c’est important

Le titre n’est pas « une IA a trouvé des bugs dans un appareil ». C’est que la recherche de vulnérabilités firmware de bout en bout a tourné à partir d’un seul artefact public, avec un modèle de gamme intermédiaire, en quelques minutes. Trois conséquences en découlent.

D’abord, la barrière à la VR en boîte blanche s’effondre. Le cadrage de Team82 est sans détour : avec un firmware ou une mise à jour logicielle disponible publiquement et le bon outillage, un agent peut faire toute la boucle. L’intrant rare n’est plus l’expertise en rétro-ingénierie — c’est une copie du logiciel cible. Attendez-vous à ce que la première vague touche les cibles en boîte blanche où le code est facile à obtenir : les projets open source et tout fournisseur livrant du firmware téléchargeable.

Ensuite, l’OT et l’embarqué sont pleinement concernés. Il ne s’agissait pas d’un endpoint SaaS, mais d’un interphone de contrôle d’accès du type qui reste non corrigé sur le terrain pendant des années. Le délai entre découverte et rapport tend vers zéro, tandis que les fenêtres de correctif OT se comptent en trimestres. C’est cet écart qui constitue le risque réel.

Enfin, l’obscurité du firmware est un compte à rebours, pas un contrôle. Un firmware chiffré ou sous accès restreint achète du temps face à ce pipeline, mais Team82 s’attend à ce que ces limites finissent par être contournées. Considérer que « notre firmware n’est pas public » est une défense durable est une erreur de planification.

Défenses

Les correctifs des bugs Zenitel existent déjà (Zenitel conseille de passer au firmware 9.3.3.0 ou ultérieur). Les défenses transposables portent sur la gestion de l’exposition, pas sur ce seul appareil.

1. Traitez chaque mise à jour firmware/logicielle publique comme une surface d’attaque accessible à l’adversaire. Si un client peut la télécharger, un agent peut en énumérer les classes de bugs. Inventoriez les produits qui livrent des images téléchargeables publiquement et classez-les par exposition.

2. Reproduisez le pipeline en interne — décalez la VR vers l’amont. L’attelage ici est reproductible sans accès de classe Mythos : un agent de code, un MCP de décompilateur et une image firmware. Lancez-le sur vos propres builds avant la sortie, et relancez-le sur le firmware livré pour trouver les analogues latents de CVE divulguées.

3. Recalibrez les SLA de correctif OT/embarqué et les contrôles compensatoires. Les appareils de terrain qui se mettent à jour lentement ont besoin d’une mitigation réseau dès maintenant : segmentez les interfaces de gestion, restreignez les surfaces d’administration web/SIP aux réseaux de confiance et surveillez-les. Partez du principe que la moitié « découverte » de la course est plus rapide que votre moitié « correctif ».

4. Ne misez pas sur l’obscurité du firmware. Le chiffrement et les téléchargements sous condition augmentent le coût mais ne changent pas l’état final. Anticipez le cas où votre firmware est obtenu et analysé à la vitesse machine.

5. Priorisez par classe de bug, pas seulement par CVE. Un sink d’injection de commande et une validation d’entrée contournable vivent rarement seuls dans les serveurs web embarqués. Quand un avis en nomme un, considérez les routes voisines et les parseurs similaires du même binaire comme dignes d’une relecture — exactement le type de couverture qu’un agent fait remonter rapidement.

Statut

Élément	Référence	Date	Notes
Compte-rendu VR mains libres	Claroty Team82	2026-06-02	Claude Opus 4.6 + MCP Ghidra maison, run < 10 min
Divulgation manuelle Zenitel TCIV-3+	Claroty	fin 2025	CVE-2025-64126/64127/64128 (injection cmd, 9.8), 64129 (écriture hors limites), 64130 (XSS)
Firmware corrigé	Zenitel	—	Passer à 9.3.3.0 ou ultérieur
Contexte gamme frontière	LLM Hacking	2026-05	Mythos/Glasswing est sous accès restreint ; ce run a utilisé un modèle disponible publiquement

La bonne lecture, c’est celle d’une ligne de base de capacité, pas d’un incident. Un modèle de gamme intermédiaire, disponible publiquement, fait déjà une VR firmware de bout en bout compétente à partir d’un seul téléchargement. La tâche défensive est de supposer que vos attaquants disposent du même attelage — et de le lancer sur votre propre code en premier.