CyberStrikeAI en conditions réelles : un orchestrateur LLM a atteint le statut d’administrateur de domaine sur des cibles du secteur de l’éducation en Amérique latine et en Afrique

Le 2 novembre 2026, Kaspersky a publié un rapport Securelist et un communiqué de presse décrivant des intrusions au sein d’organisations du secteur de l’éducation dans plusieurs pays d’Amérique latine et d’Afrique, où les travaux de post-exploitation ont été dirigés par un grand modèle de langage. L’outil était CyberStrikeAI, un framework de tests d’intrusion open source basé sur Go, dont le serveur de commande et de contrôle héberge un LLM qui sélectionne les outils et écrit les commandes, tandis qu’un implant ordinaire les exécute sur l’hôte victime. Dans l’unique cas que Kaspersky reconstitue en détail, un opérateur humain est entré via un Microsoft SQL Server compromis, a marqué une pause de deux semaines, puis a laissé l’agent agir : les comptes d’administrateur de domaine ont été compromis en trois à quatre jours, et la dernière étape — mouvement latéral, extraction massive d’identifiants et exportation d’une base de données — s’est achevée en moins d’une heure. Kaspersky ne nomme aucune institution ni aucun pays, ne donne aucun nombre de victimes et indique avoir observé l’activité entre septembre et octobre 2026. Le dossier complet de cette campagne, avec son niveau de gravité, son niveau de confiance et sa liste complète des sources, est consigné dans le Orca AI Incident Archive, aux côtés des autres entrées sur les intrusions assistées par IA.

Ce que Kaspersky a réellement publié

Le document principal est « CyberStrikeAI in the wild: the use of AI in real-world attacks on organizations », publié sur Securelist le 2 novembre 2026 et attribué à Kirill Antonov, Vladislav Vlasov et Dmitry Chizhmak de l’équipe de recherche sur les menaces de Kaspersky. Il est accompagné du communiqué de presse de Kaspersky, publié le même jour, qui résume les mêmes conclusions. La note de confiance A de l’archive décrit dans quelle mesure ces deux documents concordent entre eux et à quel point les détails techniques sont précis ; elle n’indique pas qu’une seconde organisation a vérifié l’intrusion de manière indépendante.

La couverture secondaire de ce rapport ne fournit pas cette deuxième organisation. Cybersecuritynews.com, Cyberpress, SecurityOnline et TechTrends Kenya, basé à Nairobi, ont tous publié des comptes rendus entre le 2 et le 3 novembre 2026, et chacun d’eux découle du communiqué de Kaspersky plutôt que de sa propre enquête ; l’article du média kényan est construit autour de la même citation de communiqué de presse de Nikita Nazarov, responsable de Threat Exploration chez Kaspersky. Au 9 novembre 2026, aucune université touchée, aucun ministère de l’Éducation ni aucune équipe nationale de réponse aux incidents informatiques n’avait confirmé publiquement les intrusions, et Kaspersky n’a pas publié l’identité des victimes. Cette absence fait elle-même partie du dossier : ce qui est documenté en détail, ce sont les méthodes employées, et non le préjudice subi par une institution nommée.

La déclaration de périmètre de Kaspersky est délibérément étroite. Les victimes confirmées, selon ses termes, étaient « des organisations du secteur de l’éducation dans plusieurs pays d’Afrique et d’Amérique latine ». Elle ne précise ni combien, ni quels pays, ni comment la campagne a été détectée au départ — seulement que l’équipe l’a trouvée « dans le cadre d’une surveillance proactive des menaces ».

Une distinction importe ici, car il est facile de la brouiller. Des organisations indépendantes ont désormais signalé CyberStrikeAI dans de véritables intrusions — mais pas dans celles-ci. Team Cymru a relié l’infrastructure exploitant l’outil à la campagne de janvier-février 2026 contre plus de 600 appareils FortiGate, après avoir observé 21 adresses IP uniques le diffusant entre le 20 janvier et le 26 février 2026. L’unité TrendAI de Trend Micro, dans des recherches publiées le 23 octobre 2026, a décrit un opérateur exécutant 44 agents CyberStrikeAI coordonnés qui ont soumis au moins 19 organisations identifiables, dont au moins 16 au Japon, à une activité de validation sur une courte période ce mois d’octobre-là. La note de recherche de la Cloud Security Alliance du 28 octobre 2026 réunit les deux et conclut qu’aucune source publiée n’avait encore établi de lien entre les campagnes CyberStrikeAI distinctes et un acteur unique. Cet ensemble de travaux corrobore la prémisse — selon laquelle ce framework est utilisé pour attaquer de vrais réseaux — et ne dit rien des victimes du secteur de l’éducation en Amérique latine et en Afrique dans le rapport de Kaspersky.

L’outil, et l’endroit où l’IA se trouvait réellement

CyberStrikeAI, tel que Kaspersky le décrit, est « une plateforme modulaire open source écrite en Go pour l’automatisation des tests d’intrusion ». Son choix de conception déterminant est que toute la couche intelligente réside sur le serveur de contrôle de l’attaquant, et non sur la machine de la victime. Les utilitaires de reconnaissance et d’exploitation, la gestion des webshells, l’attribution des tâches aux agents et la lecture des résultats sont tous exposés au modèle sous forme d’outils MCP au sein d’un unique processus serveur, et c’est le modèle qui décide lequel d’entre eux appeler ensuite.

L’implant est l’autre moitié, et il est délibérément stupide. Kaspersky écrit qu’il s’agit « d’un agent C2 classique dépourvu de toute fonctionnalité d’IA — aucune clé d’API, aucun appel aux API de services d’IA et aucune logique autonome ». Il interroge le listener via HTTP/S, TCP ou WebSocket, exécute des commandes shell et accède au système de fichiers. Ce n’est pas un modèle exécuté dans le réseau d’une victime, et il ne contacte jamais un fournisseur d’IA. La répartition des tâches est la phrase que Kaspersky utilise pour expliquer tout le schéma : « Les décisions sont réparties sur deux niveaux : l’opérateur définit la tâche en termes généraux, tandis que le modèle détermine comment l’exécuter. »

Le contrôle humain est conservé plutôt que supprimé. Kaspersky note un mécanisme de validation humaine selon lequel « l’opérateur conserve le contrôle total du processus », et que les commandes générées par le modèle « peuvent nécessiter une approbation ou une correction manuelle avant d’être exécutées ». L’IA rédige les étapes ; une personne peut toujours les refuser.

Une intrusion reconstituée, dans l’ordre où Kaspersky la date

Le rapport retrace un seul incident au sein de la campagne, et sa première phase ressemble à un travail manuel ordinaire au clavier. Les commandes exécutées sur les systèmes de la victime provenaient du processus sqlservr.exe, ce qui désigne « un serveur SQL Server compromis (version 16.0.1000) » comme point d’entrée probable. L’opérateur a ensuite collecté des informations de base sur l’hôte, déployé des outils et cartographié le réseau manuellement. Cela a pris « près d’une journée », après quoi les attaquants sont restés silencieux pendant environ deux semaines.

La deuxième phase est celle où le tempo change. Une fois l'agent CyberStrikeAI déployé, la persistance et la reconnaissance locale ont été réalisées « en 2 minutes » — une tâche planifiée nommée SystemUpdate pointant vers l'implant, avec une clé Run du registre sous HKCU\Software\Microsoft\Windows\CurrentVersion\Run comme alternative du framework sous Windows, et une entrée crontab @reboot ou une ligne nohup dans ~/.bashrc comme alternatives sous Linux. La reconnaissance de domaine s'est déroulée « sur les 5 heures suivantes », à l'aide de scripts PowerShell générés par le modèle et de requêtes LDAP contre Active Directory, y compris les recherches nécessaires pour préparer le Kerberoasting et l'AS-REP Roasting ainsi que des vérifications pour LAPS, Azure et les répertoires .azcopy. Après « une brève pause de plusieurs jours », l'étape finale — le mouvement latéral via SMB et WMI, l'extraction massive d'identifiants et l'export d'une base de données — a pris « pas plus d'une heure ».

La phrase de synthèse de Kaspersky mérite d’être retenue : toute l’attaque, « du déploiement de l’agent à la compromission des administrateurs de domaine – a été menée à bien en 3 à 4 jours ».

Le travail sur les identifiants est un catalogue de techniques Windows bien connues plutôt que quelque chose de nouveau : des ruches de registre extraites avec reg.exe, lsass.exe vidé via la fonction MiniDump de comsvcs.dll en utilisant l’ID de processus plutôt que son nom afin de déjouer la correspondance sur la ligne de commande, et — une fois le compte administrateur de domaine intégré compromis — des attaques DCSync et Golden Ticket exécutées via un binaire Mimikatz renommé, wdiag2.exe. Le mouvement latéral a utilisé WMIExec d’Impacket, des dossiers administratifs partagés et WMI, avec un script de shell inverse, p1.ps1, poussé vers des hôtes distants et se connectant en retour à 185.186.245[.]144:5501. Les charges utiles ont été divisées en fragments tels que d3.b64 et réassemblées avec certutil, et une balise s’est fait passer pour svchosts.exe.

La collecte est venue en dernier. L’agent a généré des requêtes SQL adaptées à la tâche, mais a vérifié les privilèges du compte de base de données avant de les exécuter, a analysé les partages réseau de manière récursive avant de récupérer les fichiers, et a renvoyé le tout via le même canal C2 chiffré, les données étant encodées en Base64 dans du JSON. Des captures d’écran sous Windows et Linux étaient disponibles, mais, selon Kaspersky, elles n’ont été prises que lorsque l’orchestrateur a émis la commande. Le rapport indique que la collecte de données « constituait la dernière étape de l’attaque : la chaîne s’est arrêtée là et nous n’avons observé aucune activité ultérieure. »

Ce qui a été pris, et ce que le dossier ne dit pas

Kaspersky rapporte que l'agent a exporté des enregistrements de base de données depuis le serveur SQL de l'organisation du secteur de l'éducation et a collecté des fichiers sur des ressources réseau, et il décrit le mécanisme en détail. Il ne précise pas combien d'enregistrements ou de fichiers ont été exfiltrés, si l'exportation a été menée à terme, ni à qui appartenaient les données des tables. Les résumés secondaires vont plus loin que le rapport sur ce point : l'article de SecurityOnline indique que l'agent « a généré des requêtes SQL ciblées pour voler des enregistrements d'étudiants et de personnel dans des tables de base de données », tandis que le texte de Kaspersky lui-même décrit les requêtes effectuées contre un serveur SQL d'établissement d'enseignement sans préciser ce que contenaient les tables. Les lecteurs doivent considérer la description « enregistrements d'étudiants et de personnel » comme une caractérisation secondaire, et non comme une conclusion de Kaspersky.

Manquent également au dossier : si une victime a détecté elle-même l’intrusion, ce que chaque institution a fait par la suite, si les régulateurs ou les autorités de protection des données des pays concernés ont été notifiés, et si la campagne est toujours en cours. Kaspersky indique seulement que la collecte de données a été la dernière étape observée dans les incidents qu’elle a examinés. Le communiqué de presse ne contient aucune recommandation de remédiation pour les organisations affectées — ses recommandations s’adressent aux équipes de défense de manière générale.

Attribution : ce que les preuves soutiennent, et ce qu’elles ne soutiennent pas

Kaspersky affirme clairement qu’il ne peut pas nommer un acteur. « Les données disponibles ne nous permettent pas de relier l’activité à un groupe d’attaquants connu, ni d’affirmer avec certitude que le même opérateur est à l’origine des deux campagnes. » L’artefact sur lequel il s’appuie est constitué des métadonnées de compilation Go présentes dans les implants, qui portent des hachages de contrôle de version, des horodatages de commit et un indicateur de copie de travail « sale » — « une empreinte unique pour une compilation spécifique. » Sur cette base, les échantillons se répartissent en deux groupes, et au sein de chaque groupe, les charges utiles Windows et Linux partagent des métadonnées identiques, ce qui signifie qu’elles proviennent de la même copie de travail.

Les groupes ne sont pas liés. Ils « ne partagent pas d’infrastructure C2 commune », et différentes versions de CyberStrikeAI étaient exécutées sur les deux ensembles de serveurs de contrôle. Kaspersky donne deux raisons pour lesquelles l’attribution est difficile ici : le framework est disponible publiquement, de sorte que différents opérateurs ont pu construire des payloads indépendamment dans des conditions similaires, et les commandes elles-mêmes sont générées par modèle, ce qui gonfle leur variété tout en effaçant les habitudes individuelles dont dépend l’attribution comportementale.

Ce qui subsiste est suggestif plutôt que concluant. Certains scripts contenaient des commentaires en chinois, les attaquants ont utilisé le service chinois dnslog[.]cn pour confirmer l’accès à Internet depuis les hôtes victimes, et la plupart des redémarrages des serveurs de contrôle — récupérables parce que le certificat TLS auto-signé est régénéré en mémoire à chaque démarrage, de sorte que son champ not_before enregistre l’heure du redémarrage — tombaient pendant les heures ouvrables UTC+8. CyberStrikeAI lui-même a été développé au sein de la communauté chinoise de cybersécurité. Le communiqué de presse de Kaspersky trace clairement la limite : ces artefacts « n’établissent pas l’identité ni la localisation des attaquants », et l’entreprise « n’a pas pu attribuer l’activité à un groupe de menaces connu ni confirmer que le même opérateur contrôlait toutes les infrastructures identifiées ». Un opérateur sinophone est une inférence, pas une conclusion.

Pourquoi Kaspersky affirme qu’il ne s’agit pas d’une urgence de détection

La conclusion du rapport conteste l'idée qu'un LLM dans la chaîne d'attaque nécessite une nouvelle classe de défense. Parce que le modèle réside sur le serveur de l'attaquant, il « n'a laissé aucune trace de sa présence dans l'infrastructure (comme des requêtes API spécifiques vers des LLM locaux ou des schémas anormaux de consommation de ressources par les hôtes) ». Ce que les défenseurs observent à la place est une intrusion à apparence humaine : les mêmes outils, les mêmes séquences, les mêmes entrées de journaux d'événements. Le verdict de Kaspersky est que « l'introduction de l'IA dans la chaîne d'attaque ne présente pas encore de défis fondamentalement nouveaux pour la détection », que « des règles classiques et bien calibrées de corrélation et d'analyse comportementale suffisent », et que la nouveauté « ne réside pas dans les méthodes elles-mêmes, mais dans la vitesse et la facilité avec lesquelles elles ont été exécutées ».

Les détections publiées suivent cette logique plutôt que d’en inventer de nouvelles. Kaspersky Anti Targeted Attack attribue le verdict réseau Backdoor.CyberStrikeAI.HTTP.C&C au trafic de l’implant ; une règle de détection d’anomalies réseau nommée « Scanning domain records via LDAP queries » détecte la reconnaissance du domaine ; Kaspersky SIEM fournit plus de 100 règles couvrant les techniques du rapport, notamment DCSync, Golden Ticket, Kerberoasting et Impacket WMIExec ; et les implants sont classés comme HEUR:HackTool.Win64.CyberStrike.gen et HEUR:HackTool.Linux.CyberStrike.gen. Les recommandations de Kaspersky à ses clients sont classiques — détection et réponse sur les terminaux, détection réseau, renseignement sur les menaces et surveillance en dehors des heures de travail ou via un service géré.

La déclaration de Nazarov dans le communiqué de presse, c'est le même argument en une seule phrase : les attaquants « ont utilisé un agent d'IA basé sur CyberStrikeAI pour exécuter une chaîne d'attaque complète et adapter leurs étapes suivantes au sein des réseaux compromis », mais « le framework reposait toujours sur des techniques et procédures familières, notamment la découverte, le vidage d'identifiants, le mouvement latéral, ainsi que la collecte et l'exfiltration ».

Ce qui est établi, et ce qui ne l’est pas

Pour le dire clairement : le mécanisme est documenté à un niveau qui permettrait à un défenseur de le traquer dès demain — l’ascendance des processus depuis sqlservr.exe, une tâche planifiée nommée SystemUpdate, l’accès à LSASS via comsvcs.dll, un DCSync depuis une machine qui n’est pas un contrôleur de domaine, l’en-tête HTTP X-Implant-Token, et les adresses C2 listées par Kaspersky. La campagne autour de ce mécanisme ne l’est pas. Kaspersky n’a publié ni liste de victimes, ni répartition par pays, ni estimation du volume de données, ni acteur. Tout ce qu’un lecteur pourrait vouloir savoir sur qui a été touché et à quel point s’arrête au secteur et à la région.

Deux détails méritent d'être signalés pour quiconque se tourne vers le rapport en espérant davantage. Premièrement, Kaspersky décrit l'attaque comme « l'une des premières descriptions publiques d'une compromission impliquant un LLM en conditions réelles » plutôt que comme la première — une précaution qui limite l'affirmation à ce que l'équipe a pu trouver dans les publications publiques. Deuxièmement, le rapport note que la version de l'implant ne suit pas celle du serveur, que les configurations d'écoute et les clés survivent aux mises à jour de l'opérateur, et que la date de compilation d'un échantillon ne donne qu'une date de déploiement au plus tôt, et non la durée d'une compromission. Le chiffre de 3 à 4 jours est la mesure d'un seul incident reconstitué, et non une limite de la durée pendant laquelle l'une de ces intrusions a pu se poursuivre avant que quelqu'un ne s'en aperçoive.