600 FortiGate compromis en 5 semaines : quand l'IA transforme un attaquant médiocre en menace à grande échelle

Entre le 11 janvier et le 18 février 2026, un acteur russophone a compromis plus de 600 équipements FortiGate dans 55 pays en cinq semaines. L'Amazon Threat Intelligence, qui a découvert le serveur d'infrastructure de l'attaquant laissé en accès libre, a documenté l'intégralité du kit opérationnel : code source, configs volées, plans d'attaque générés par LLM, et journaux de sessions Claude Code actives pendant des intrusions en cours.

Ce qui distingue cette campagne n'est pas la sophistication technique. L'acteur est classé de niveau faible à moyen par Amazon. Ce qui la distingue, c'est la façon dont l'IA commerciale a transformé ce niveau de compétence en capacité opérationnelle à grande échelle.

Vecteur d'accès initial : pas d'exploit, juste de l'opportunisme

Aucune CVE n'a été exploitée pour l'accès initial. L'acteur a ciblé des interfaces de management FortiGate exposées sur Internet (ports 443, 8443, 10443, 4443) et s'est authentifié par force brute avec des credentials courants, sur des comptes sans MFA.

Une fois l'accès obtenu, l'objectif immédiat était l'extraction de la configuration complète du firewall. Ces fichiers sont une mine : credentials SSL-VPN avec mots de passe récupérables (format ENC de Fortinet, vulnérable à CVE-2019-6693), credentials administrateurs, topologie réseau complète, configurations IPsec VPN, et politiques de firewall détaillant l'architecture interne. Des scripts Python assistés par IA ont automatisé le déchiffrement et l'organisation de ces données.

Le ciblage est opportuniste, sans secteur privilégié. Les clusters de victimes suggèrent toutefois des compromissions d'organisations entières (blocs IP contigus, ports de management non standard partagés), cohérentes avec des déploiements de prestataires infogérés.

L'IA comme multiplicateur opérationnel

L'acteur a utilisé au minimum deux fournisseurs de LLM commerciaux tout au long de la campagne : DeepSeek pour la génération de plans d'attaque à partir des données de reconnaissance, et Claude (Anthropic) pour les évaluations de vulnérabilités et l'exécution d'outils offensifs.

L'usage de l'IA couvre l'ensemble du cycle d'intrusion : génération de méthodologies d'attaque étape par étape, développement de scripts personnalisés en Go et Python, création de frameworks de reconnaissance, planification de mouvements latéraux, et rédaction de documentation opérationnelle en russe.

Dans au moins un cas documenté, l'attaquant a soumis la topologie réseau interne complète d'une victime (adresses IP, hostnames, credentials, services connus) à un LLM en lui demandant comment progresser dans le réseau.

ARXON et CHECKER2 : une chaîne d'exploitation semi-automatisée

Le serveur exposé à 212.11.64[.]250:9999 (hébergé sur AS4264, Zurich) contenait 1 402 fichiers répartis dans 139 sous-répertoires. Parmi eux, deux composants personnalisés, absents de tout référentiel public au moment de la publication :

• CHECKER2 : orchestrateur Docker en Go pour le scanning VPN parallèle. Les journaux montrent plus de 2 500 cibles potentielles dans plus de 100 pays.
• ARXON : serveur MCP (Model Context Protocol) en Python, qui ingère les données de reconnaissance des FortiGate compromis, les transmet aux LLMs, et retourne des plans d'attaque structurés. Il maintient une base de connaissance qui s'enrichit à chaque nouvelle cible.

L'évolution de l'outillage est visible dans les deux expositions successives du serveur : en décembre 2025, l'acteur utilisait HexStrike, un framework MCP offensif open source. Huit semaines plus tard, ARXON remplaçait HexStrike avec un niveau d'automatisation nettement supérieur.

Les indicateurs de développement assisté par IA dans le code source sont explicites : commentaires redondants qui reformulent le nom des fonctions, architecture naïve surpondérée en formatage, parsing JSON par correspondance de chaînes au lieu de désérialisation, shims de compatibilité vides. Fonctionnel pour les cas nominaux, le code échoue systématiquement sur les environnements durcis.

Claude Code en mode autonome

Les deux dossiers nommés claude-0 et claude sur le serveur contenaient plus de 200 fichiers : sorties de tâches Claude Code, diffs de sessions, états de prompts mis en cache. Un fichier .claude/settings.json pré-autorisait Claude Code à exécuter de manière autonome Impacket, Metasploit, hashcat et d'autres outils offensifs, avec des credentials de domaine codés en dur appartenant à un employé d'un grand groupe média asiatique.

L'un des rapports d'évaluation, daté du 1er février 2026 et attribué à Claude Code en bas de document, incluait un round-trip time de 400ms vers l'infrastructure cible, confirmant que le rapport avait été généré pendant une connexion distante active. Le rapport documentait deux cibles internes (NAS QNAP et serveur Veeam, tous deux sans signature SMB), plusieurs tentatives d'exploitation avec modules Metasploit, et une instance ntlmrelayx.py en cours d'exécution au moment de la génération.

Déroulement type d'une compromission

La séquence la mieux documentée concerne une entreprise de gaz industriel en Asie-Pacifique. Le point d'entrée était un FortiGate-40F dans une agence, accessible via un compte Technical_support en lecture seule. Malgré les permissions limitées, la configuration complète a été extraite, exposant topologie réseau, 50 comptes VPN avec identifiants, paramètres LDAP, et adresse d'un second FortiGate.

Un fichier EXTRACTED_DATA_SUMMARY.md organisait les données de manière structurée avec des étapes d'exploitation prioritarisées. La configuration LDAP incluait un compte bind avec mot de passe au format ENC, vraisemblablement déchiffré via les scripts liés à CVE-2019-6693.

La post-exploitation suit un schéma standard avec des outils open source connus : utilisation de Meterpreter avec le module mimikatz pour des attaques DCSync, extraction des hashes NTLM depuis l'Active Directory, mouvements latéraux par pass-the-hash et relais NTLM, puis ciblage des serveurs Veeam Backup & Replication.

Le ciblage de l'infrastructure de sauvegarde est un signal pré-ransomware documenté : les serveurs de backup stockent des credentials élevés et leur compromission permet de détruire les capacités de restauration avant le chiffrement.

Ce que révèle l'erreur d'OPSEC

L'acteur a laissé son serveur opérationnel en accès libre via un SimpleHTTP Python. Cette erreur d'OPSEC élémentaire a fourni une visibilité complète sur les méthodologies, le code source, les configurations volées de victimes réelles, et les sessions LLM actives.

Les victimes confirmées incluent la société de gaz asia-pacifique, un opérateur télécom turc, et un groupe média asiatique. Des données de reconnaissance sur des cibles en Corée du Sud, Égypte, Vietnam, Kenya, et du code ciblant un fabricant de matériel médical étaient également présents.

Amazon note un comportement révélateur : face aux environnements durcis ou aux mesures défensives avancées, l'acteur abandonne et passe à des cibles plus accessibles. La valeur ajoutée de l'IA n'est pas dans la profondeur technique, elle est dans l'efficacité à grande échelle et la capacité à maintenir plusieurs intrusions en parallèle.

Recommandations opérationnelles

Les mesures préventives issues de cette campagne sont connues mais manifestement pas systématiquement appliquées :

• Interfaces de management FortiGate : ne pas les exposer sur Internet. Si nécessaire, restreindre l'accès par IP source et imposer MFA.
• Credentials VPN et Active Directory : ne pas réutiliser les mêmes mots de passe entre VPN et AD. Les configs FortiGate exposent les passwords SSL-VPN en format récupérable.
• Infrastructure de sauvegarde : isoler les serveurs Veeam du réseau principal, surveiller les connexions SMB non signées, appliquer les patches CVE-2023-27532 et CVE-2024-40711.
• Détection post-exploitation : surveiller les créations de comptes VPN inhabituelles, l'activité SSH atypique, les DCSync sur les contrôleurs de domaine, et les accès aux partages SYSVOL/NETLOGON en dehors des patterns normaux.
• Patch management périmétrique : les équipements exposés (firewalls, VPN concentrators) doivent être patchés en priorité. L'acteur échoue systématiquement sur les cibles à jour.

Sources

• AI-augmented threat actor accesses FortiGate devices at scale — CJ Moses, AWS Security Blog (20 fév. 2026)
• LLMs in the Kill Chain: Inside a Custom MCP Targeting FortiGate Devices Across Continents — Cyber and Ramen (21 fév. 2026)
• Amazon: AI-assisted hacker breached 600 Fortinet firewalls in 5 weeks — BleepingComputer (21 fév. 2026)
• CVE-2019-6693 — FortiGate password encryption weakness, NVD
• CVE-2024-40711 — Veeam Backup & Replication RCE, Veeam KB