Un agent IA est allé de WordPress au disque d'un dirigeant, et la défense a repéré 14 étapes sur 15

La défense classique repose sur des règles : un outil connu ou une chaîne particulière dans un log, et l'alerte se déclenche. Un agent IA offensif brise ce modèle. Pour lui, les outils, les noms de fichiers, les ports et les techniques d'obfuscation ne sont que des variables, qu'il change en cours de route. Pendant que l'analyste écrit une règle pour un utilitaire, l'agent en a déjà pris un autre. De plus, il est difficile pour des humains de traiter un flux d'alertes au rythme imposé par la machine.

Les experts de Positive Technologies ont vérifié sur un banc d'essai si l'approche comportementale pouvait y répondre. Un agent RedTeam, imitant un attaquant, avait pour objectif d'accéder aux documents d'un dirigeant. La défense n'était pas configurée pour le laboratoire.

Comment l'agent a progressé dans le réseau

Le banc d'essai ressemblait à un petit réseau d'entreprise : WordPress en périmètre, messagerie Exchange, contrôleur de domaine, serveur de certificats ADCS et postes de travail. L'opérateur donnait des indications, mais l'agent choisissait lui-même les étapes et les outils. L'attaque a duré quelques heures.

Il a commencé par un plugin WordPress vulnérable et le téléversement d'un webshell PHP. Il a ensuite exploité une erreur de configuration de sudo : awk peut être lancé sans mot de passe, et il permet d'exécuter n'importe quelle commande en root. C'est ainsi qu'est apparu le premier tunnel. Ensuite, via ProxyLogon, il a pris Exchange, monté un deuxième tunnel, obtenu un certificat grâce à un modèle ADCS vulnérable (ESC1), extrait les hachages du domaine par DCSync et forgé un ticket Kerberos Golden Ticket. Le contrôleur de domaine est devenu le troisième point d'appui, après quoi l'agent a parcouru six postes de travail et consulté le disque du dirigeant.

La technique clé ici, ce sont les pivots : le serveur compromis devient un proxy SOCKS5, et le trafic suivant part de son adresse. Il y en a eu trois au total. Le périmètre réseau n'est pas gêné par ce trafic, car il vient de l'intérieur.

Ce qu'il y avait côté défense

Le dispositif comporte deux couches. MaxPatrol BAD, module ML intégré au SIEM, sélectionne les anomalies : écarts de comportement des processus et des utilisateurs, indépendamment de l'outil. On les appelle indicateurs de comportement. C'est un préfiltre, car un LLM ne sait pas analyser seul le flux brut d'événements du SIEM.

La seconde couche est la classification, car toute anomalie ne signifie pas une attaque. HackTracker reçoit de BAD une description du comportement et rend un verdict : malveillant ou légitime. Il ne connaît pas d'outils précis et ne fournit volontairement pas d'explications, par souci de précision. L'explication est assurée par PT Naira, un assistant IA qui analyse la chaîne de processus choisie par l'analyste, et par un agent IA interne pour BAD, qui reçoit les détections avec les événements normalisés. L'agent n'est pas encore un produit, mais une démonstration.

L'exemple d'Exchange montre comment cela fonctionne. Le pool d'applications IIS lance powershell.exe avec une fenêtre masquée et sans profil, puis viennent le contournement d'AMSI, la désactivation de la journalisation des scripts et le retrait de l'attribut « lecture seule » du webshell. Chaque action prise isolément peut être légitime, mais la chaîne forme un schéma d'attaque. Le tunnel est détecté de la même façon : certutil télécharge un fichier, qui se déguise en svchost32.exe et se connecte au C2 avec des paramètres SOCKS.

Sur l'hôte Unix avec WordPress, le tableau est différent. HackTracker ne traite pour l'instant que les événements Windows ; le verdict y a donc été établi par les indicateurs de BAD et l'agent IA : shell lancé par apache2, reconnaissance depuis www-data, téléchargement d'un binaire dans /tmp, élévation sudo via un interpréteur.

Ce qu'il faut en retenir

En pratique, la conclusion est simple : il faut détecter des chaînes de comportement, et non des noms d'utilitaires. Si la défense repose sur des signatures d'outils précis, un agent IA la contourne en changeant simplement de logiciel. Il reste toutefois à un humain d'examiner chaque détection, et l'explicateur LLM réduit le temps nécessaire au verdict. Il faut aussi vérifier les failles banales que l'agent a utilisées comme marches : sudo sans mot de passe pour awk, Exchange non corrigé, modèles ADCS vulnérables.

Il faut garder les limites en tête. Il s'agit d'un seul scénario dans un seul laboratoire, mené par l'éditeur lui-même. Le résultat « 14 sur 15 » ne dit rien du taux de faux positifs dans un réseau réel avec des milliers d'administrateurs et une infrastructure complexe. La couverture Unix de HackTracker reste incomplète, et l'agent IA n'est pas encore sorti en tant que produit. Le test montre que l'attaque par IA laisse une trace comportementale, mais ne prouve pas que la défense fonctionnera de la même manière dans votre réseau.