Comment un amateur, à l'aide d'agents d'IA volés, a compromis quatorze entreprises – et ce que les journaux d'attaque révèlent sur votre propre exposition
Un attaquant a demandé à son agent d'IA de l'aider à mettre à jour son CV. C'est le genre d'erreur qui fait dérailler une carrière : le document contenait son nom complet, son parcours, son adresse et son profil LinkedIn, et il se trouvait sur le même serveur que les journaux qui documentaient déjà tout le reste de son activité.
«
Le document se trouvait sur le même serveur que les journaux qui documentaient déjà tout le reste.
Les chercheurs d'OALABS ont pu récupérer ces journaux grâce à une seconde erreur : l'attaquant exécutait ses outils sur le serveur compromis d'un tiers, et non sur une infrastructure qu'il maîtrisait. Le propriétaire du serveur a repéré l'intrusion, téléchargé l'intégralité du répertoire de travail et l'a remis aux analystes. Comme les agents d'IA étaient installés localement, l'ensemble des sessions a été préservé : les instructions de l'attaquant, les outils employés, le raisonnement interne du modèle et les rares refus déclenchés. Au total, plus de mille sessions.
Ce qu'elles montrent n'a rien d'une opération sophistiquée. L'attaquant se servait de deux agents – Claude Code d'Anthropic pour l'essentiel, et, dans une moindre mesure, Codex d'OpenAI –, tous deux volés à d'autres utilisateurs plutôt qu'acquis légitimement. Il donnait des consignes vagues et laissait l'agent faire le reste : repérer les services exposés, rechercher les vulnérabilités, écrire du code d'exploitation sur mesure, valider les accès et exfiltrer les données. Sur la base des journaux et d'autres éléments concordants, dont un moment où il a confirmé par inadvertance son adresse IP personnelle à l'agent, les chercheurs estiment qu'il s'agit d'un jeune homme établi à Addis-Abeba, en Éthiopie.
Au terme de l'analyse, les journaux documentaient la compromission d'au moins quatorze entreprises. L'IA avait aussi produit, à la demande de l'attaquant, des estimations chiffrées de la valeur des données volées et une liste de pistes de monétisation : extorsion, revente d'accès, compromission de messagerie professionnelle et détournement direct de fonds. Rien dans les journaux ne confirme toutefois qu'il ait réussi à tirer de l'argent de ces intrusions.
L'histoire prêterait à sourire si le nombre de victimes n'était pas bien réel.
Le seuil de compétence a disparu
Il existe en sécurité une notion de « seuil de compétence » : le niveau minimal de connaissances techniques dont un attaquant a besoin pour causer des dégâts réels. Pendant des décennies, ce seuil est resté relativement stable. Exploiter une vulnérabilité supposait de la comprendre. Écrire un outil d'attaque sur mesure supposait de savoir programmer. Assembler une intrusion en plusieurs étapes supposait de l'expérience, de la patience et une communauté d'opérateurs chevronnés auprès de qui apprendre.
Le cas OALABS ne met pas en scène un attaquant chevronné qui se trouverait utiliser l'IA. Il montre un attaquant sans compétences réelles, rendu capable par l'IA. L'agent a fourni l'expertise qui lui manquait, comblé les lacunes et pris en charge l'exécution technique dont il aurait été incapable seul. Face à un service exposé, il lui suffisait souvent d'écrire « recon this » et de laisser l'agent enchaîner recherche de failles, écriture de l'exploit et exécution, presque sans autre intervention.
Le risque n'a rien d'hypothétique. Les journaux existent. Les entreprises ont été compromises. Un épisode donne la mesure de ce qui devient possible : ayant mis la main sur le portefeuille d'un nœud Bitcoin détenant près de 70 bitcoins, soit environ quatre millions de dollars, l'attaquant a chargé l'agent de répartir une attaque par force brute sur quatorze machines déjà compromises. La tentative a échoué, mais l'orchestration, elle, a bien eu lieu.
Un détail supplémentaire mérite attention. Sur plus de mille sessions, les modèles n'ont opposé que dix refus au total – neuf pour Claude, un pour Codex. L'attaquant a contourné la plupart d'entre eux en présentant ses requêtes comme un test d'intrusion autorisé. Ce cadrage fonctionne précisément parce qu'il est aussi celui qu'emploient chaque jour des milliers de testeurs légitimes. Les modèles ne peuvent pas vérifier la déclaration, et les contraindre à refuser tout ce qui ressemble à un test de sécurité nuirait, selon les chercheurs, bien davantage aux défenseurs qu'aux attaquants, ces derniers pouvant se rabattre sur des modèles plus anciens ou moins encadrés. Les garde-fous ont d'ailleurs surtout réagi lorsque l'attaquant est passé à la monétisation explicite ; ils ont même opposé un refus ferme lorsqu'il a voulu viser un particulier et sa famille. Compter sur les mesures de sécurité des fournisseurs d'IA comme couche de défense sérieuse relève, au vu des éléments disponibles, du vœu pieux.
Ce que cela signifie pour votre organisation
Les conséquences sont les plus nettes pour les organisations qui ne sont pas de grands groupes dotés d'un centre d'opérations de sécurité : cabinets d'avocats, family offices, gérants d'actifs, entreprises de services financiers de taille intermédiaire. Ces organisations détiennent des données précieuses et hautement sensibles. Leurs systèmes communiquent avec d'autres systèmes, avec des intégrations bancaires, des dossiers clients et des échanges dont la compromission serait dommageable. Elles ne disposent généralement pas d'une équipe interne à temps plein chargée de tester leurs propres défenses.
«
La limite se situe désormais du côté de la motivation et du temps, non de l’expertise technique.
Jusqu'à récemment, cette position était défendable. Les attaquants capables de les menacer sérieusement étaient qualifiés, peu nombreux et concentrés sur des cibles plus grandes ou plus exposées. L'IA modifie directement ce calcul. Elle dissocie la compétence de l'intention, et la limite se situe désormais du côté de la motivation et du temps de l'attaquant plutôt que de son expertise technique, deux ressources largement disponibles.
La réponse appropriée relève de la réévaluation plutôt que de l'inquiétude. Les questions utiles sont concrètes. Lesquels de vos services sont exposés sur l'extérieur ? Quels identifiants sont partagés ou réutilisés d'un système à l'autre ? Votre supervision recherche-t-elle des anomalies de comportement, ou seulement les signatures d'attaques connues ? Un attaquant assisté par IA trouvera les réponses à ces questions plus vite que la plupart des organisations ne les ont trouvées elles-mêmes.
L'attaquant d'Addis-Abeba a commis assez d'erreurs pour être identifié. La plupart n'en commettront pas. L'environnement de menace a changé, et les défenses qui suffisaient il y a deux ans peuvent ne plus suffire aujourd'hui. Mettez ce point à votre ordre du jour ; nous pouvons vous aider à y répondre.
Références
Zeljka Zorz, « Low-skilled attacker used Claude, Codex to breach 14 companies », Help Net Security, 17 juin 2026. helpnetsecurity.com
OALABS (Open Analysis), « Captured Logs Reveal Hackers Using Claude and Codex to Breach Companies », research.openanalysis.net, 16 juin 2026. research.openanalysis.net
Mohannad AbouHammoud
Consultant senior
Mohannad est un stratège en technologie et en affaires, fort de plus de 25 ans d'expérience dans la technologie d'entreprise, la finance et le marketing. Il écrit sur les interactions entre la technologie, les affaires et la société, avec un intérêt particulier pour la manière dont les technologies émergentes transforment les organisations, les secteurs d'activité et la façon dont les personnes travaillent.