Comment un acteur augmenté par l’IA a compromis plus de 600 appareils FortiGate sans exploit

Entre le 11 janvier et le 18 février 2026, un acteur russophone à motivation financière a compromis plus de 600 appliances pare-feu FortiGate dans plus de 55 pays — et ce sans exploiter la moindre vulnérabilité du produit. Amazon Threat Intelligence, qui a publié l'enquête le 20 février 2026, indique que l'acteur a trouvé des interfaces de gestion exposées à internet sur les ports 443, 8443, 10443 et 4443 et s'est introduit avec des mots de passe couramment réutilisés sur des comptes dépourvus d'authentification multifacteur. Les configurations d'équipement qu'il a extraites contenaient des identifiants SSL-VPN avec des mots de passe récupérables, des identifiants administrateur, des politiques de pare-feu et la topologie du réseau. Des grands modèles de langage commerciaux ont été mobilisés tout au long de l'opération, rédigeant des outils de reconnaissance et ébauchant des plans d'attaque ; selon un autre chercheur ayant découvert le propre serveur de l'acteur, l'un des modèles était également configuré pour exécuter des commandes offensives. Cet incident est une entrée de the Orca AI Incident Archive, qui contient le dossier complet, ses sources et sa notation, aux côtés des cas voisins de la série.

Ce qu'Amazon a rapporté, et comment il l'a découvert

Le rapport « Un acteur de menace augmenté par l’IA accède à grande échelle aux appareils FortiGate » est attribué à CJ Moses, RSSI d’Amazon Integrated Security, et a été publié sur le blog AWS Security le 20 février 2026. Son premier constat substantiel est négatif : « Aucune exploitation des vulnérabilités FortiGate n’a été observée. » L’accès initial a reposé à chaque fois sur des identifiants : un balayage systématique des interfaces de gestion sur les quatre ports ci-dessus, suivi de tentatives d’authentification avec des identifiants couramment réutilisés.

Ce qui a rendu la campagne visible, c’est la sécurité opérationnelle de l’acteur lui-même. Amazon affirme avoir identifié l’infrastructure hébergeant les outils malveillants grâce à un travail de routine de renseignement sur les menaces, et que le même serveur contenait des plans d’attaque générés par IA, des configurations de victimes et le code source d’outils personnalisés, stockés sans chiffrement. Cette négligence a donné à Amazon une vue quasi complète de la méthodologie. « C’est comme une chaîne de montage alimentée par l’IA pour la cybercriminalité », indique le rapport.

Les fichiers de configuration volés constituent le pivot entre l’appareil et le réseau situé derrière lui. Selon Amazon, ils contiennent des identifiants d’utilisateur SSL-VPN avec des mots de passe récupérables, des identifiants administratifs, la topologie réseau complète et les informations de routage, des politiques de pare-feu qui révèlent l’architecture interne, ainsi que des configurations de pairs VPN IPsec. L’acteur a écrit des scripts Python assistés par IA pour les analyser, les déchiffrer et les organiser.

La post-exploitation, selon les propres mots d’Amazon

Une fois à l’intérieur, l’acteur a suivi un parcours standard et bien documenté. Sa documentation opérationnelle, rédigée en russe, décrit l’utilisation de Meterpreter avec le module mimikatz pour lancer des attaques DCSync contre des contrôleurs de domaine et extraire des hachages de mots de passe NTLM depuis Active Directory. Dans des compromissions confirmées, il a obtenu des bases de données complètes d’identifiants de domaine. Amazon note au moins un cas où le compte Administrateur de domaine utilisait un mot de passe en clair qui avait soit été réutilisé depuis la configuration FortiGate, soit été faible en soi.

À partir de là, les techniques documentées sont le pass-the-hash et le pass-the-ticket contre d’autres infrastructures, le relais NTLM à l’aide d’outils d’empoisonnement standard, et l’exécution de commandes à distance sur des hôtes Windows. L’acteur a spécifiquement ciblé les serveurs Veeam Backup & Replication avec des scripts PowerShell, des outils de déchiffrement compilés et des tentatives contre des vulnérabilités Veeam connues — un comportement qu’Amazon décrit comme « cohérent avec des opérations préalables à une attaque par rançongiciel », bien que le rapport ne fasse pas état du déploiement d’un rançongiciel.

Les notes de l'acteur font référence à plusieurs CVE, notamment CVE-2019-7192, CVE-2023-27532 et CVE-2024-40711. BleepingComputer, qui a couvert le rapport le 21 février 2026, identifie la première comme une faille d'exécution de code à distance QNAP et les deux dernières comme des problèmes Veeam. Aucune d'elles n'était la voie d'accès. Plus révélateur encore, les mêmes notes consignent des échecs répétés : services déjà corrigés, ports fermés, exploits qui ne s'appliquaient pas au système d'exploitation cible. Pour une victime confirmée, l'évaluation de l'acteur lui-même a conclu que l'infrastructure clé était « bien protégée » avec « aucun vecteur d'exploitation vulnérable ».

Deux limites à cette attribution méritent d'être énoncées clairement. Amazon indique que l'acteur n'est « pas connu pour être associé à un quelconque groupe de menace persistante avancée disposant de ressources soutenues par un État », et que l'implication de l'infrastructure AWS dans la campagne n'a pas été observée.

Là où l'IA était réellement assise

Le compte rendu d’Amazon sur la couche d’IA est précis sur les rôles mais muet sur les produits. L’acteur a utilisé au moins deux fournisseurs commerciaux de LLM distincts, selon le rapport : l’un comme principal développeur d’outils, planificateur d’attaques et assistant opérationnel, et l’autre comme planificateur supplémentaire lorsque l’acteur avait besoin d’aide pour pivoter au sein d’un réseau particulier. Dans un cas observé, l’acteur a soumis une topologie interne complète — adresses IP, noms d’hôtes, identifiants confirmés et services identifiés — et a demandé un plan étape par étape pour atteindre des systèmes que ses outils existants ne pouvaient pas toucher.

Les preuves avancées par Amazon selon lesquelles l’outillage a été généré par une machine sont d’ordre stylistique plutôt que forensique. Elles listent des commentaires redondants qui ne font que répéter les noms de fonctions, une architecture qui investit davantage dans le formatage de la sortie que dans la fonctionnalité, du JSON analysé par correspondance de chaînes plutôt que par une véritable désérialisation, et des couches de compatibilité accompagnées de squelettes de documentation vides. Les outils fonctionnaient pour le cas étroit de l’acteur et échouaient dans les cas limites. Le volume, note Amazon, impliquerait normalement une équipe de développement ; ici, il provenait d’un seul acteur ou d’un groupe très restreint.

Ce que le rapport AWS ne contient pas, c’est le nom d’un quelconque fournisseur de modèle, d’un quelconque produit, ni aucune mention du Model Context Protocol. Ces éléments figurent dans une seconde étude publiée le lendemain.

Le serveur, et les noms qu’Amazon n’a pas publiés

Le 21 février 2026, le blog de sécurité Cyber and Ramen a publié sa propre analyse d’un répertoire ouvert à l’adresse 212.11.64[.]250:9999, hébergé sur AS4264 (Global-Data System IT Corporation, Zurich) — l’une des deux adresses qu’Amazon répertorie comme infrastructure d’acteur malveillant. Le chercheur a compté 1 402 fichiers répartis dans 139 sous-répertoires, notamment des sauvegardes de configuration FortiGate volées, des données de mappage Active Directory, des extractions d’identifiants, des modèles d’analyse Nuclei et des outils d’extraction d’identifiants Veeam, ainsi que deux dossiers nommés d’après Claude contenant plus de 200 fichiers de sortie de tâches, de diffs de session et d’états de prompt mis en cache.

Deux composants personnalisés sont nommés dans cette analyse. ARXON est décrit comme un serveur Python du Model Context Protocol qui ingère des données de reconnaissance par cible, appelle DeepSeek pour générer des plans d’attaque et tient une base de connaissances qui s’enrichit à chaque cible ; il contient aussi des scripts pour la création par lots de comptes VPN FortiGate via SSH et pour la validation des identifiants Domain Admin. CHECKER2 est un orchestrateur Go basé sur Docker pour l’analyse parallèle de VPN, avec des journaux montrant 2 516 cibles dans 106 pays. Le chercheur indique qu’aucune référence publique à l’un ou l’autre de ces outils n’a pu être trouvée, ce qui indique que les deux ont été conçus pour cette opération.

La même analyse décrit une exposition de décembre 2025 du même serveur, celui-ci contenant une copie de HexStrike, un framework MCP offensif open source, et un fichier de paramètres .claude qui avait préautorisé Claude Code à exécuter les outils Impacket, Metasploit et hashcat contre des identifiants de domaine codés en dur appartenant à un employé d'une grande entreprise asiatique de médias. En février, selon le chercheur, l'acteur était passé de ce point de départ open source à ARXON et CHECKER2 — une progression d'environ huit semaines.

BleepingComputer a relayé ces conclusions dans une mise à jour de son article du 21 février. La distinction est importante : ARXON, CHECKER2, DeepSeek et Claude Code relèvent de l'interprétation par le chercheur des fichiers, journaux et paramètres d'un répertoire non sécurisé. Amazon, qui avait un accès indépendant à la même infrastructure, n'a cité aucun d'entre eux. Aucun fournisseur de modèle n'a confirmé aucun de ces éléments.

Ce qui est établi, ce qui repose sur une seule source

Trois affirmations reposent sur deux parties indépendantes. L’article de blog de Fortinet lui-même du 6 mars 2026, « Attacks at the Speed of AI », indique que Fortinet « n’a observé aucune exploitation des vulnérabilités FortiGate » et que la campagne a réussi grâce à des ports de gestion exposés et à des identifiants faibles avec authentification à facteur unique, au moyen de pulvérisation de mots de passe. Cela corrobore le mécanisme d’Amazon du point de vue du fournisseur, sans qu’aucune des parties n’ait vu les preuves publiées par l’autre.

Amazon est à elle seule la source de l’ampleur — plus de 600 appareils, plus de 55 pays, la fenêtre de janvier à février — et du profil de l’acteur : russophone, motivé financièrement, niveau technique de base faible à moyen, forte dépendance à l’IA, faible profondeur de post-exploitation, sécurité opérationnelle inadéquate. Aucun tiers n’a repris le chiffre de 600.

Cyber et Ramen constituent à eux seuls la source pour l’outillage nommé, les fournisseurs de modèles, les décomptes de fichiers et les 2 516 cibles de scan. Ses propres documents de preuve ont confirmé des compromissions chez une entreprise de gaz industriel en Asie-Pacifique, un fournisseur de télécommunications en Turquie et la société de médias concernée par la divulgation de décembre, avec des reconnaissances faisant référence à la Corée du Sud, à l’Égypte, au Vietnam et au Kenya — un ensemble de victimes confirmées dans au moins cinq pays, bien loin des 55 cités par Amazon. Les deux nombres mesurent des choses différentes, et aucun des deux n’a fait l’objet d’une conciliation publique.

La réponse de Fortinet, et l’ampleur qu’il n’a pas confirmée

La publication de Fortinet, signée Carl Windsor et datée du 6 mars 2026, s'accorde avec Amazon sur le mécanisme et diverge sur l'ampleur. « D'après les investigations et la surveillance de Fortinet, quelques clients ont été touchés par cette attaque », peut-on y lire. « Nous sommes en train de notifier ces organisations. » Elle ne confirme pas les 600 appareils, n'adopte pas le décompte de pays d'Amazon et ne nomme pas l'acteur.

Le positionnement de Fortinet est que la technique est ancienne et que l'automatisation est nouvelle : la pulvérisation de mots de passe contre des équipements de périphérie mal protégés, désormais pilotée par des conversations basées sur des invites, sans code. Il indique que l'attaque « aurait été impossible avec l'authentification multifacteur (MFA) en place » et « très peu probable de réussir » avec une politique de complexité des mots de passe activée. Il a également publié des indicateurs : un accès administrateur depuis 212[.]11.64[.]250 ou 185[.]196.11[.]225, la création de comptes nommés fortiuser, fortinet-support ou fortinet-tech-support, des configurations ou utilisateurs VPN inattendus, et des scripts planifiés pour s'exécuter comme mécanisme de persistance.

Il s’agit d’une divergence d’ampleur, et non d’une contestation de la réalité de la campagne. Aucune personne nommée dans le dossier ne conteste l’intrusion ; l’archive lui attribue la note A, sans indicateur de contestation, et consigne un préjudice réel.

Qu’est-ce qui a changé par la suite ?

Il n’y a ni CVE ni correctif, car il n’y avait pas de vulnérabilité. La remédiation passe par la configuration, et les deux organisations sont parvenues à la même liste. Amazon affirme avoir partagé des indicateurs de compromission avec les partenaires concernés, collaboré avec des partenaires du secteur et aidé les organisations à prendre des mesures qui ont réduit l’efficacité de l’acteur ; le rapport ne donne aucun nombre d’organisations notifiées. Fortinet indique qu’il notifie directement les clients concernés.

Les recommandations techniques sont cohérentes dans les deux cas : supprimer l’accès administratif des interfaces exposées à Internet et gérer l’administration via un chemin interne ou hors bande ; imposer l’authentification multifacteur (MFA) pour l’accès administratif et l’accès VPN ; appliquer une complexité des mots de passe ; renouveler les identifiants SSL-VPN sur tout équipement dont l’interface de gestion a été ou a pu être accessible ; auditer la réutilisation de mots de passe entre les comptes VPN FortiGate et Active Directory ; et isoler l’infrastructure de sauvegarde, la corriger et conserver des copies immuables.

Pour la détection, Amazon pointe l'activité DCSync (ID d'événement 4662 avec des GUID liés à la réplication), de nouvelles tâches planifiées nommées pour imiter des services Windows légitimes, des connexions de gestion à distance inhabituelles provenant de pools d'adresses VPN, des artefacts d'empoisonnement LLMNR et NBT-NS, ainsi qu'un accès non autorisé aux magasins d'informations d'identification de sauvegarde. Il avertit également que la détection par signatures a ici une valeur limitée, car l'outillage est constitué d'utilitaires open source légitimes — Impacket, gogo, Nuclei — qui apparaissent lors de tests d'intrusion ordinaires.

Pourquoi ce record est un événement marquant

Les archives qualifient cette entrée de jalon, et la raison en est visible dans le contraste entre ce que l’acteur a accompli et ce dont il était capable. Un opérateur unique ou un groupe très restreint, évalué à un niveau de compétence faible à moyen, a mené des intrusions concurrentes dans des dizaines de pays, produit une boîte à outils qui impliquerait normalement une équipe de développement, et généré des plans d’attaque par cible assez rapidement pour maintenir plusieurs intrusions en cours simultanément.

Le même rapport fournit le plafond. L’acteur ne pouvait pas compiler d’exploits sur mesure, ne pouvait pas déboguer les tentatives d’exploitation échouées et ne pouvait pas improviser lorsqu’un plan se heurtait à une cible durcie — il est donc passé à autre chose plutôt que de persévérer. Son code généré par IA échouait dans les cas limites. Ses notes opérationnelles sont un relevé de services corrigés et de ports fermés. Ce que les modèles ont supprimé, c’est du travail, pas du jugement : la reconnaissance, l’analyse syntaxique, la documentation et la planification ont été automatisées ; les parties qui exigeaient une adaptation sont restées hors de portée.

C’est aussi pourquoi les questions ouvertes sont ternes et précises. Le nombre d’organisations que Fortinet a réellement notifiées permettrait de résoudre l’écart entre « quelques clients » et plus de 600 appareils. Un second examen du répertoire ARXON, indépendant du chercheur qui l’a découvert, permettrait d’établir ce qu’était l’outillage et quels modèles il appelait. D’ici là, le dossier étaye une conclusion ferme sur la méthode et une conclusion bien plus faible sur l’ampleur.