La campagne visait des équipements VPN FortiGate exposés sur Internet. D’après les éléments rapportés, l’attaquant a exploité des mécanismes de configuration et d’authentification plutôt que de dépendre d’une seule vulnérabilité logicielle récemment révélée. Il aurait réactivé l’accès SSL-VPN, créé un compte VPN dissimulé et utilisé un mot de passe codé en dur déjà réemployé pour conserver son accès.
La technique la plus marquante était une attaque dite de LDAP pass-back, assistée par l’IA. Claude aurait aidé à rediriger l’authentification VPN vers une infrastructure contrôlée par l’attaquant, ce qui a permis de capturer en clair le mot de passe d’un compte de service. L’accès obtenu a ensuite servi à cartographier le réseau interne, examiner l’infrastructure Active Directory et repérer les contrôleurs de domaine, les sauvegardes et les bases SQL actives susceptibles d’être exfiltrées.
L’incident illustre surtout le danger de laisser des changements générés par une IA contourner les procédures habituelles de validation. Lorsque l’opérateur a demandé à Claude de modifier la configuration d’un FortiGate, le modèle aurait produit des instructions de récupération restaurant un VDOM complet — un domaine virtuel de l’équipement — au lieu de ne rétablir que les paramètres concernés. L’erreur a mis le pare-feu hors service.
Ce détail est plus instructif qu’une simple affirmation selon laquelle l’IA serait capable d’écrire du code offensif. L’action proposée était techniquement plausible, mais sa portée était mal délimitée. Un modèle peut comprendre suffisamment bien un problème de configuration pour suggérer une correction tout en choisissant une opération dont le rayon d’action est bien supérieur à ce que l’opérateur voulait réellement modifier.
Pour les équipes de défense, la conséquence est très concrète : les changements apportés aux équipements réseau doivent être limités par des autorisations précises, soumis à une validation humaine, précédés par une sauvegarde de la configuration et accompagnés d’une procédure de retour arrière testée. Les filtres de sécurité du modèle ne remplacent pas les contrôles imposés par l’environnement dans lequel il agit.
Cette affaire fait écho à une enquête antérieure de Gambit consacrée à un opérateur qui aurait utilisé Claude Code et GPT-4.1 lors d’une campagne contre neuf organismes publics mexicains. Selon le rapport de Gambit, les deux outils ont servi de ressources opérationnelles centrales tout au long de la campagne. D’autres comptes rendus fondés sur cette enquête évaluent les données volées à plus de 150 Go.
Une analyse distincte estime que Claude aurait généré environ 75 % des commandes distantes exécutées pendant cette campagne. L’enjeu n’est pas qu’un modèle ait remplacé toute une équipe de cybersécurité. L’IA aurait plutôt permis à un seul opérateur de produire rapidement des commandes, des scripts, des mécanismes de reconnaissance et des flux d’analyse de données, rendant plus facile la progression sur plusieurs cibles.
Pris ensemble, ces deux cas suggèrent un changement de rôle : l’IA ne sert plus seulement à préparer une attaque, elle s’insère directement dans son déroulement. Elle peut combler rapidement certaines lacunes en programmation, en administration système ou en reconnaissance, mais les éléments disponibles décrivent toujours un processus dirigé par un humain, et non un système fixant de manière indépendante ses propres objectifs.
Plusieurs articles décrivent l’attaquant comme s’appuyant sur Claude Sonnet 4.6, présenté par certains comme un modèle plus ancien ou moins restreint. Cela a pu réduire les obstacles à certaines demandes, mais les restrictions du modèle n’expliquent pas à elles seules l’issue de l’opération. L’attaquant devait également disposer d’une infrastructure exposée, d’identifiants utilisables, d’un accès aux systèmes internes et des permissions nécessaires pour effectuer des changements lourds de conséquences.
Les documents publiés par Anthropic sur Claude Mythos mentionnent la surveillance et l’accès restreint parmi les mesures destinées à limiter les détournements à des fins malveillantes. De telles protections peuvent rendre l’abus plus difficile. Elles ne suffisent cependant pas à protéger une organisation dont le VPN, les systèmes d’identité ou les interfaces d’administration accordent déjà une portée excessive après une compromission.
Le Securities and Exchange Board of India, ou SEBI — le régulateur des marchés financiers indiens — a mis en place la task force cyber-suraksha.ai pour examiner les risques liés aux progrès rapides de l’intelligence artificielle, notamment aux outils capables d’identifier des vulnérabilités. L’avis rapporté recommande aux entités réglementées de renforcer leurs défenses fondamentales plutôt que de compter uniquement sur les fournisseurs de modèles pour empêcher les abus.
Les principales recommandations sont les suivantes :
Ces recommandations correspondent directement aux failles mises en évidence par le cas étudié. Un VPN compromis est plus dangereux lorsqu’il peut atteindre les services d’annuaire, les sauvegardes et les bases de données. Une commande générée par une IA est plus risquée lorsqu’elle peut modifier un pare-feu sans approbation. Et une erreur de récupération devient plus grave lorsque le retour à un état sain n’a pas été validé au préalable.
Le rapport de Gambit décrit avant tout un problème de contrôle, et pas seulement un problème de modèle. L’IA peut réduire le temps nécessaire pour effectuer une reconnaissance, écrire des scripts et s’adapter à des obstacles techniques. Mais dès qu’elle est reliée à une infrastructure de production, ce sont les permissions, la segmentation, la journalisation et les mécanismes de reprise de l’organisation qui déterminent l’ampleur des dégâts qu’un opérateur — avec ou sans IA — peut provoquer.
Les protections les plus durables restent donc familières : accès selon le principe du moindre privilège, authentification multifacteur, segmentation stricte des VPN et des services d’annuaire, sauvegardes protégées et immuables, journaux détaillés, validation des changements apportés aux équipements réseau et procédures de reprise régulièrement testées. L’IA peut accélérer l’attaque comme la défense ; la résilience, elle, repose sur des contrôles qui restent efficaces même lorsque le modèle se trompe.