IA et cybersécurité industrielle : l'exploit PLC automatisé est-il possible ?
- Des chercheurs de Vedere Labs ont utilisé l'IA Claude pour adapter un exploit RCE d'un automate WAGO 750-852 vers un modèle 750-831.
- L'opération a nécessité 8 heures et 32 minutes de travail, ainsi qu'un investissement de 535,74 dollars en frais d'API.
- L'intervention humaine est restée indispensable pour corriger les erreurs de l'IA et fournir le contexte technique.
- Une tentative d'extension vers un implant de commande et contrôle a fini par détruire physiquement l'automate (bricking).
L'idée qu'une intelligence artificielle puisse, d'un simple prompt, paralyser une infrastructure industrielle est un scénario récurrent des films de science-fiction. Pourtant, la réalité technique est plus nuancée. Une expérience menée par les chercheurs de Vedere Labs, une division de Forescout, vient d'apporter un éclairage crucial sur la capacité réelle des LLM à orchestrer des cyberattaques complexes sur des systèmes de contrôle industriel (ICS).
Le défi technique du portage d'exploit
L'objectif des chercheurs était ambitieux : porter un exploit d'exécution de code à distance (RCE) déjà connu d'un modèle d'automate programmable industriel (PLC) WAGO 750-852 vers un autre modèle, le WAGO 750-831. Le point de départ était la vulnérabilité CVE-2021-31886, un dépassement de tampon (buffer overflow) situé dans le serveur FTP Nucleus. Cette faille permet normalement à un attaquant non authentifié d'exécuter du shellcode ARM arbitraire sur la cible.
Dans le domaine des systèmes embarqués, et particulièrement pour les PLC dont le code est fermé, une telle opération est complexe. Elle exige une compréhension profonde de la disposition de la mémoire et des chemins de traitement spécifiques à chaque version du firmware. Ce n'est pas une simple traduction de code, mais une adaptation structurelle où la moindre erreur d'adresse mémoire peut rendre l'attaque inopérante ou provoquer un crash système.
L'arsenal utilisé pour l'expérience
Pour tester les limites de l'IA, l'équipe n'a pas utilisé un simple chat, mais une configuration intégrée. Ils ont déployé Claude Code, en lui donnant un accès direct à un terminal, à des fichiers de référence et à l'outil de rétro-ingénierie Ghidra. L'IA a pu ainsi jongler entre les modèles Claude Sonnet 4.6 et Claude Opus 4.6 selon la complexité des tâches.
Le processus a débuté par une phase de reconnaissance. L'IA a combiné des sondages en direct et une analyse statique du firmware pour confirmer la présence de la vulnérabilité. La première étape a été relativement simple : générer un payload capable de faire planter l'automate. Ce déni de service (DoS) a prouvé que la faille existait sur le modèle 750-831, mais le passage d'un simple crash à une exécution de code contrôlée s'est avéré bien plus ardu.
Un coût financier et humain non négligeable
L'un des enseignements majeurs de cette étude, détaillée sur SecurityWeek, est que l'IA ne remplace pas l'expert, elle l'assiste. Le succès final n'a pas été instantané. Il a fallu 8 heures et 32 minutes de travail intensif, durant lesquelles les chercheurs ont dû constamment corriger les hypothèses erronées de l'IA et lui fournir le contexte de désassemblage nécessaire.
L'aspect financier est également frappant. L'utilisation intensive des API de Claude a coûté 535,74 dollars. Ce chiffre démontre que, si l'IA peut accélérer certaines phases de recherche, le coût opérationnel pour atteindre un exploit fonctionnel reste significatif. L'IA a notamment buté sur un problème technique précis : le traitement standard du protocole FTP effaçait le shellcode. C'est l'intervention humaine qui a permis d'identifier cette cause racine et de guider l'IA vers une solution de préservation du buffer.
Quand l'IA provoque un dommage physique
L'expérience a pris un tournant critique lorsque les chercheurs ont tenté d'aller plus loin. L'objectif était de transformer l'exploit RCE en un implant de commande et contrôle (C2) permanent. C'est à ce stade que la limite de l'autonomie de l'IA est devenue tangible et destructrice.
L'IA a généré une instruction d'écriture incorrecte dans la mémoire flash de l'automate, ce qui a entraîné le bricking permanent du matériel.
Cet incident souligne un risque majeur : l'IA, dans sa volonté d'optimiser ou de résoudre un problème, peut produire des commandes syntaxiquement correctes mais logiquement désastreuses pour le matériel physique. Dans un environnement industriel réel, une telle erreur pourrait ne pas seulement détruire un automate de test, mais provoquer des dommages matériels graves ou des arrêts de production massifs.
Analyse des résultats et livrables
Malgré l'échec de l'implant C2, l'expérience a abouti à la création d'un exploit RCE fonctionnel pour le WAGO 750-831. Les chercheurs ont réussi à envoyer des payloads UDP délivrant une chaîne de caractères 'PWNED' et un payload d'écho ICMP, prouvant la prise de contrôle du système. Le bilan de l'opération peut être résumé ainsi :
Le flux de travail a suivi une progression linéaire : analyse du firmware, reproduction du crash, correction humaine des erreurs de l'IA, identification du problème de nettoyage du buffer et, enfin, exécution du code. Cette méthodologie prouve que l'IA peut réduire le temps de développement d'un exploit, mais qu'elle reste dépendante d'un superviseur capable de valider chaque étape technique.
L'impact pour le tissu industriel français
Pour les entreprises françaises, particulièrement celles opérant dans les secteurs de l'énergie, de l'eau ou de l'industrie lourde, cette nouvelle est un signal d'alerte sur l'évolution des menaces. La France, avec son plan France 2030, mise massivement sur la numérisation de l'industrie et l'intégration de l'IA. Cependant, cette accélération technologique élargit la surface d'attaque.
Le cadre réglementaire européen, via l'AI Act, commence à encadrer les risques liés à l'IA, mais la menace offensive évolue plus vite que la norme. Pour un PME industrielle française, le risque n'est plus seulement l'attaquant expert, mais l'attaquant 'augmenté' par l'IA, capable de porter des vulnérabilités connues sur des équipements spécifiques en quelques heures.
La leçon pour les responsables de la sécurité (RSSI) en France est claire : la segmentation des réseaux OT (Operational Technology) et la mise à jour rigoureuse des firmwares ne sont plus optionnelles. L'expérience de Forescout démontre que même des systèmes fermés peuvent être compromis si l'attaquant dispose d'un accès au firmware et d'un LLM performant. La souveraineté industrielle passera nécessairement par une capacité de défense proactive, capable d'anticiper ces portages automatisés d'exploits.
Questions fréquentes
L'IA peut-elle créer des exploits PLC seule ?
Non. L'expérience montre que l'IA a besoin d'un expert humain pour corriger ses erreurs, fournir le contexte technique et guider la recherche, sous peine de ne pas aboutir ou de détruire le matériel.
Quel a été le coût total de l'expérience pour obtenir l'exploit ?
L'opération a coûté 535,74 dollars en frais d'API et a nécessité 8 heures et 32 minutes de travail humain.
Qu'est-ce que le 'bricking' mentionné dans l'article ?
Le bricking est la corruption irréversible du firmware d'un appareil, le rendant totalement inutilisable, comme une brique. Ici, cela a été causé par une mauvaise écriture en mémoire flash générée par l'IA.
Quelle vulnérabilité a été utilisée comme base ?
Les chercheurs se sont basés sur la CVE-2021-31886, un dépassement de tampon dans le serveur FTP Nucleus des automates WAGO.
Sources: Securityweek, Dev, Letsdatascience ·
Scrivila qui: Susanna, l assistente AI di glacom, ti risponde via email con un approfondimento gratuito.
Nessuna consulenza personalizzata (finanziaria, legale o medica): solo informazione e fonti. Email usata solo per rispondere.
oppure scrivile su: WhatsApp · Telegram · SimpleX · Delta Chat · Email
