VEXAIoT : des agents LLM qui enchaînent reconnaissance et exploitation IoT en laboratoire

De quoi s’agit-il ?

VEXAIoT (« Vulnerability EXploitation using AI agents for IoT ») est un cadre de recherche, publié sur arXiv le 13 juillet 2026 par Katherine Swinea, Kshitiz Aryal, Lopamudra Praharaj et Maanak Gupta, qui relie deux agents à grand modèle de langage en un pipeline offensif de bout en bout contre des équipements IoT. Un agent gère la reconnaissance et la planification ; l’autre choisit l’outillage et exécute les étapes d’exploitation. Sur 260 exécutions d’attaque dans des environnements de test isolés et volontairement vulnérables, les auteurs rapportent un taux de succès global de 95 %, la plupart des attaques se terminant en moins de deux minutes.

Le cadrage important — énoncé clairement par les auteurs — est que l’ensemble a été exécuté uniquement contre des cibles de laboratoire volontairement vulnérables (IoTGoat, un firmware d’entraînement basé sur OpenWrt, et Metasploitable2), dans des machines virtuelles cloisonnées. Le papier précise explicitement que ses résultats ne doivent pas être lus comme la preuve qu’un système d’IA pourrait compromettre de façon fiable des appareils réels arbitraires. Ce qu’il démontre, c’est le degré atteint par l’automatisation d’un workflow de test d’intrusion déjà existant.

Comment ça fonctionne

VEXAIoT répartit la chaîne d’attaque classique entre deux agents LLM qui coopèrent et échangent leurs sorties en boucle :

• Un agent de détection de vulnérabilités effectue la reconnaissance, énumère les services et protocoles exposés, associe les logiciels découverts à des vulnérabilités connues et rédige un plan d’attaque ordonné.
• Un agent d’exécution d’attaque choisit l’outil ou le script d’exploit public approprié, génère les commandes concrètes, les exécute et rend compte. En cas d’échec d’une étape, la boucle permet de vérifier, d’avancer ou de réessayer avec une approche modifiée.

Le cadre orchestre de l’outillage offensif standard et public, rien de nouveau : Nmap pour le scan, SearchSploit/Exploit-DB pour faire correspondre vulnérabilités et exploits publics, et des utilitaires comme Bettercap et John the Ripper à l’exécution. Dans le montage évalué, les chercheurs ont piloté les deux agents avec un modèle de raisonnement de pointe, et chaque commande générée, plan et sortie était journalisé et présenté à un humain, conservant un point de supervision dans la boucle.

La valeur apportée par la couche LLM est celle du liant : elle transforme des objectifs vaguement spécifiés en invocations d’outils, corrèle les sorties de scan avec des exploits candidats et gère la logique de réessai qu’un opérateur humain effectuerait sinon à la main. Le papier associe ses dix scénarios à neuf catégories de l’OWASP IoT Top 10 — récupération d’identifiants par défaut, gestion non sécurisée des mises à jour, interception d’identifiants, divulgation d’informations, etc. La fiabilité était la plus élevée pour les attaques à étapes déterministes et conditions de succès claires (plusieurs scénarios atteignant 100 % sur leurs essais), et plus faible pour les attaques spécifiques à un service où la construction des commandes et la variabilité de l’environnement pèsent davantage. Parmi les échecs observés, une part notable venait du refus du modèle ou de commandes malformées — les limites de sûreté et de fiabilité du modèle sous-jacent, pas du pipeline.

Pourquoi c’est important

L’enjeu n’est pas une nouvelle classe de vulnérabilité — chaque technique employée ici est une faiblesse IoT documentée disposant d’un correctif existant. C’est la compression de la charge de travail de l’opérateur. Reconnaissance, corrélation de vulnérabilités, sélection d’exploit, exécution, validation et réessai sont des étapes qui exigent traditionnellement du temps humain qualifié ; les câbler derrière deux agents coopérants les ramène à une exécution largement automatique qui se termine en quelques minutes. Cela abaisse le seuil de compétence requis pour des attaques opportunistes contre la vaste population d’appareils IoT et embarqués exposés et mal corrigés, et signifie que les défenseurs doivent anticiper une hausse de l’échelle et de la vitesse des attaques peu coûteuses, même à sophistication constante.

Deux réserves pour rester honnête. Les taux de succès élevés ont été mesurés contre des cibles conçues pour être cassées : ils représentent une borne supérieure, pas une performance de terrain. Et les refus et erreurs du modèle lui-même ont été une source réelle d’échec — l’entraînement à la sûreté et la génération fragile de commandes imposent encore des frictions. La conclusion défensive reste la même dans les deux cas : une flotte IoT déjà exploitable par un humain patient l’est désormais par une boucle automatisée, donc les fondamentaux comptent davantage, pas moins.

Défenses

Les contrôles qui neutralisent VEXAIoT sont les bases mêmes du durcissement IoT que ses propres scénarios ciblent — et c’est précisément le point :

• Éliminer les identifiants par défaut. Imposez le changement des identifiants au premier démarrage et bloquez les couples identifiant/mot de passe par défaut connus. La récupération d’identifiants par défaut était l’un des scénarios du pipeline.
• Réduire la surface de services. Désactivez les services réseau, protocoles et interfaces de gestion inutilisés (UPnP, telnet, backdoors de débogage/développement) pour que la reconnaissance trouve moins de matière à corréler.
• Corriger et inventorier les firmwares. Tenez un inventaire d’actifs précis et appliquez les mises à jour ; l’étape de correspondance SearchSploit/Exploit-DB ne fonctionne que si l’appareil exécute une version disposant d’un exploit public.
• Sécuriser le canal de mise à jour. Signez et vérifiez les mises à jour de firmware afin qu’une gestion non sécurisée des mises à jour ne puisse servir à livrer du code.
• Chiffrer le trafic sensible. TLS et une validation correcte des certificats font échouer le scénario d’interception d’identifiants par l’homme du milieu.
• Centraliser et protéger les journaux. Exportez les journaux hors de l’appareil vers un stockage inviolable, afin que les étapes de suppression de journaux n’effacent pas les preuves, et que la détection d’anomalies puisse repérer le schéma scan-puis-exploit rapide et scripté que ces agents produisent.
• Segmenter le réseau. Isolez les appareils IoT et OT des réseaux bureautiques et d’Internet ; c’est un appareil exposé qui rend viable, en premier lieu, une exécution agentique sans surveillance.

Aucune de ces mesures n’est nouvelle. Ce que VEXAIoT change, c’est le rapport coût/bénéfice : la fastidieuse besogne qui protégeait autrefois les appareils négligés — les heures qu’un attaquant devait y consacrer — est exactement la part qui s’automatise.

Statut

Élément	Détail
Type	Cadre de recherche (papier académique)
Publication	arXiv 2607.09653, 13 juillet 2026
Auteurs	K. Swinea, K. Aryal, L. Praharaj, M. Gupta
Testé contre	IoTGoat (OpenWrt) et Metasploitable2, VM isolées
Résultat rapporté	~95 % de succès sur 260 exécutions ; plupart des attaques < 2 min
Périmètre	Neuf catégories de l’OWASP IoT Top 10 sur dix scénarios
Portée réelle	Les auteurs avertissent explicitement que les résultats n’impliquent pas une compromission fiable d’appareils réels arbitraires