Amazon Threat Intelligence a documenté la compromission de plus de 600 équipements FortiGate répartis dans plus de 55 pays par un acteur russophone financièrement motivé, de niveau technique faible à moyen, ayant utilisé au moins deux services LLM commerciaux distincts pour automatiser la planification d'attaques, générer des outils de reconnaissance et conduire des opérations post-exploitation à une échelle qui aurait précédemment nécessité une équipe significativement plus large et plus qualifiée.
Aucune exploitation de vulnérabilité FortiGate n'a été observée dans cette campagne. L'accès initial reposait exclusivement sur des interfaces de gestion exposées sur internet — ports 443, 8443, 10443 et 4443 — et sur l'abus d'identifiants faibles ou réutilisés avec authentification à facteur unique. C'est l'ampleur opérationnelle rendue possible par l'IA, et non la sophistication technique de l'acteur, qui distingue cette campagne : lorsque celui-ci rencontrait des environnements durcis ou des mesures défensives plus élaborées, il abandonnait la cible pour se concentrer sur des systèmes moins protégés, confirmant que son avantage réside dans l'efficacité augmentée par l'IA, non dans une capacité d'exploitation avancée.
Amazon Threat Intelligence a identifié l'utilisation d'au moins deux services LLM commerciaux distincts dans des rôles opérationnels complémentaires. Le premier servait de développeur d'outils principal, de planificateur d'attaques et d'assistant opérationnel. Le second était mobilisé comme planificateur de mouvement lorsque l'acteur avait besoin d'aide pour progresser dans un réseau victime spécifique. Dans une instance documentée, l'acteur a soumis à ce second LLM la topologie interne complète d'une victime active — adresses IP, noms d'hôtes, identifiants confirmés et services identifiés — en demandant un plan étape par étape pour compromettre des systèmes supplémentaires inaccessibles avec ses outils existants.
L'IA générait des méthodologies d'attaque complètes incluant des séquences de commandes, des taux de succès estimés, des délais d'exécution et des arbres de tâches priorisés. Ces plans référençaient de la littérature académique sur les agents IA offensifs, indiquant que l'acteur suivait activement les publications sur les tests d'intrusion assistés par IA. Cependant, une limite structurelle est documentée : l'acteur produisait des séquences techniquement correctes mais échouait systématiquement à s'adapter lorsque les conditions différaient du plan — incapable de compiler des codes d'exploitation personnalisés, de déboguer des tentatives échouées, ou de se déplacer créativement face à des défenses non standard.
Vecteur d'accès aux annuaires Active Directory
L'infrastructure de mise en scène de l'acteur, laissée publiquement accessible — défaillance de sécurité opérationnelle critique —, contenait des plans d'attaque générés par IA, des configurations de victimes et le code source des outils personnalisés. Cette exposition involontaire a fourni à Amazon Threat Intelligence une visibilité complète sur les méthodologies employées et la manière dont l'IA était intégrée à chaque phase des opérations.
Les fichiers de configuration FortiGate constituent des cibles à haute valeur dans cette chaîne d'attaque : ils contiennent des identifiants SSL-VPN avec mots de passe récupérables, des identifiants administratifs, la topologie réseau complète avec informations de routage, les politiques pare-feu révélant l'architecture interne, et les configurations de pairs IPsec VPN. Une fois ces configurations exfiltrées, l'acteur utilisait les identifiants volés pour se connecter aux réseaux internes des victimes via VPN et conduire les opérations post-exploitation.
La méthodologie post-exploitation suivait un enchaînement standardisé : déploiement de Meterpreter avec le module mimikatz pour des attaques DCSync contre les contrôleurs de domaine, extraction des hachages NTLM depuis l'annuaire Active Directory, puis mouvements latéraux via attaques par rejeu de hachage et de ticket Kerberos. Dans des compromissions confirmées, l'attaquant a obtenu des bases de données complètes d'identifiants de domaine. Dans au moins un cas documenté, le compte Administrateur de domaine utilisait un mot de passe en clair, extrait de la configuration FortiGate par réutilisation ou indépendamment faible.
L'acteur ciblait spécifiquement les serveurs Veeam Backup & Replication via plusieurs outils d'extraction d'identifiants — scripts PowerShell, outils de déchiffrement compilés et tentatives d'exploitation de vulnérabilités connues (CVE-2023-27532, CVE-2024-40711). Le ciblage prioritaire des infrastructures de sauvegarde signale une préparation cohérente avec un déploiement de rançongiciel : compromettre la capacité de récupération avant le chiffrement est une tactique documentée dans les opérations structurées de rançongiciel. Les propres notes opérationnelles de l'acteur enregistrent cependant des échecs répétés contre des cibles à jour de correctifs ou configurées avec des ports non standard.
Une boîte à outils générée par IA
L'analyse du code source de l'outil de reconnaissance personnalisé — disponible en versions Go et Python — révèle des marqueurs caractéristiques de génération par IA : commentaires redondants se limitant à reformuler les noms de fonctions, architecture simpliste avec investissement disproportionné dans le formatage au détriment de la fonctionnalité, analyse syntaxique JSON naïve par correspondance de chaînes plutôt que par désérialisation appropriée, et stubs de documentation vides. L'outil automatise le flux de reconnaissance post-VPN : ingestion des réseaux cibles depuis les tables de routage VPN, classification par taille, découverte de services via le scanner de ports gogo, identification automatique des hôtes SMB et contrôleurs de domaine, et analyse de vulnérabilités via Nuclei sur les services HTTP découverts.
Le volume et la variété des outils personnalisés — analyseurs de configuration, outils d'extraction d'identifiants, automatisation de connexion VPN, orchestration de balayage massif, tableaux de bord d'agrégation de résultats — indiqueraient normalement une équipe de développement bien dotée en ressources. CJ Moses, RSSI d'Amazon Integrated Security, qualifie le modèle de « chaîne d'assemblage IA pour la cybercriminalité, aidant des intervenants moins qualifiés à produire à l'échelle ». L'ensemble de cette boîte à outils a été généré par un acteur individuel ou un très petit groupe via développement assisté par IA, sans maîtrise suffisante pour corriger les défaillances sous des conditions non anticipées.
Le ciblage géographique apparaît opportuniste plutôt que sectoriel, cohérent avec un balayage automatisé massif : des concentrations d'équipements compromis ont été observées en Asie du Sud, Amérique latine, Caraïbes, Afrique de l'Ouest, Europe du Nord et Asie du Sud-Est. Des regroupements suggèrent des compromissions au niveau organisationnel — blocs d'adresses IP contigus ou ports de gestion non standard partagés — indiquant des déploiements de fournisseurs de services managés ou de grands réseaux d'entreprise. Pour les RSSI, le périmètre géographique de cette campagne confirme qu'aucune région ni aucun secteur ne constitue un périmètre hors d'atteinte d'un acteur de faible niveau opérant avec une augmentation par IA.
