TLDR : Cet article explique le processus de réflexion afin d’aboutir à une IA permettant de compromettre un environnement Active Directory sans intervention humaine.
N.B : Cet article est le fruit de travaux internes de recherche et développement et non de moyens utilisés en missions clients.
Introduction
La puissance d’une IA n’est que proportionnelle aux outils auxquels elle a accès. Ainsi, il y a quelques années, lorsque les LLM (Large Language Models) ont été disponibles pour le grand public (notamment via ChatGPT), cela a marqué une rupture technologique et a créé une peur du remplacement pour les métiers non-techniques. En cybersécurité, nous abordons l’outil comme une aide afin de mieux développer, mieux comprendre et mieux configurer. Mais si l’intelligence artificielle pouvait faire plus que cela ?
De manière plus générale, qu’est ce que l’IA est capable de faire dans le cadre d’une Red Team/Pentest interne ?
Tooling et MCP
Model Context Protocol (MCP) est un standard ouvert conçu pour connecter de manière sécurisée les assistants d’intelligence artificielle aux systèmes où résident les données, comme des serveurs locaux, des bases de données ou des outils professionnels (Slack, GitHub, etc.) :
Intéractions entre Utilisateur/LLM/MCP
Il agit comme une « prise universelle » (similaire à un port USB-C, pour les logiciels), permettant aux développeurs de créer une seule connexion standardisée pour que l’IA puisse lire des informations ou effectuer des actions, sans avoir à construire des intégrations spécifiques pour chaque source. Pour résumer, un MCP est la brique permettant de faire le pont entre un simple LLM et une IA Agentique.
Un MCP existe déjà pour Kali-linux, et s’appelle “mcp-kali-server” (disponible sur le repository kali officiel). Cependant, nos essais ont rapidement révélé que les fonctionnalités de ce serveur MCP étaient bien en deçà des capacités des modèles de LLM actuels, et la création d’une alternative s’est imposée.
Modifications du serveur MCP Kali
Tout d’abord, une fois avoir testé ces LLM avec l’outil mcp-kali-server, plusieurs constats ont été dégagés :
- Déterminer clairement les outils disponibles permet d’avoir un LLM plus efficace
Tous les modèles ont tendance à légitimer ses actions dès qu’un MCP est disponible. Le LLM à peut être tendance à comprendre que le MCP fait partie de lui même et donc par conséquent, ne se pose pas forcément de questions sur la légitimité (ou non) de ses actions.
Les différents LLM testés ont aussi tendance à changer d’outil dès que le premier ne lui a pas donné entière satisfaction. Cependant, les outils proposés par le serveur MCP de kali n’est pas très exhaustif :
Outils disponibles sur “mcp-kali-server”
L’idée du créateur est louable de faire des outils permettant d’effectuer des “quick wins” avec ces différents outils. Or, le LLM va tester ces outils un à un, et va s’auto appliquer une certaine fonction de récompense ou de pénalité en fonction de la réussite ou non du test.
Ainsi, si “enum4linux_scan” ne fonctionne pas, cela est normal (et même logique) de passer à un autre test. Mais si un test est effectué par l’outil “execute_command” qui est l’outil “fourre-tout” permettant de faire des commandes arbitraires, disons par exemple pour utiliser “netexec”, le LLM va pénaliser cet outil, et ne pourra pas faire une autre commande arbitraire, disons “certipy–ad” par exemple.
- Mieux catégoriser pour mieux fonctionner
Maintenant que nous avons démontré qu’avoir tous les outils individuellement permet au LLM de mieux fonctionner, autant intégrer tous les outils directement sur le LLM ?
Avertissement sur Github copilot si trop d’outils sont chargés
Voici ce qui arrive lorsque plus de 128 outils sont chargés. La “context-window” (c’est-à-dire le nombre de token qu’arrive à garder en mémoire le LLM) est trop petite par rapport à tous les outils dont nous avons besoin. En effet, le LLM a besoin de charger l’intégralité des outils dans sa mémoire pour sélectionner le plus adapté.
Pour remédier à ce problème, tout en permettant au LLM de pouvoir accéder à tous les outils, voici une proposition visant à améliorer les capacités de sélection d’outils :
Structure du MCP serveur customisé
Cette proposition permet à la fois d’avoir l’ensemble des outils disponibles, ne pénalise pas un outil plus qu’un autre et force la lecture du manuel de chaque outil avant son exécution. Cela permet de faire le moins d’erreurs possible et donc d’éviter de “pénaliser” un outil avant sa bonne exécution.
- Laisser le LLM déterminer le timeout
Le contexte donné à l’IA change sa façon d’utiliser les outils. L’expérience prouve qu’en lui informant que sa cible est un environnement de “lab”, elle va droit au but pour gagner un maximum de temps :
Scan nmap intensif effectué par Claude (T4)
Or, dans le serveur mcp-kali-server, le timeout (délai imparti) est défini par une variable globale qui est par défaut à 300 secondes :
Timeout défini par une variable globale sur “mcp-kali-server”
Cela force le LLM à utiliser des timings rapides et/ou à trouver des moyens détournés pour arriver à exécuter sa commande dans les 300 secondes.
Encore pire, si on demande au LLM d’adopter une approche “Red Team”, cela nécessite de faire de longs scans, avec des timings lents, et donc des commandes qui inévitablement, finiraient par expirer… On pourrait allonger le timeout, mais cela pourrait pénaliser le LLM dans sa quête de rapidité si une commande est retenue pour une quelconque raison.
La solution choisie à donc été de laisser le LLM définir le timeout pour chacune de ses commandes :
Scan netexec par Claude avec un timeout de 60s
Avec cette solution, en fonction du comportement demandé au LLM, ce dernier pourra adapter les timeouts de chacune de ses commandes.
- Gérer les outils interactifs
Si les LLMs exécutent sans problème des commandes instantanées, ils éprouvent des difficultés avec les outils interactifs tels que responder, ntlmrelayx, etc… Et c’est normal ! Le timeout est fixe donc ils sont limités au nombre de secondes qu’ils leur reste. Alors des techniques afin de faire fonctionner ces outils ont été élaborées :
Utilisation d’un outil interactif avec un one-liner
Il était donc nécessaire de pouvoir supporter ces outils. Pour cela, il a fallu créer de nouveaux outils disponibles via MCP permettant de créer une session. Cette session ferait tourner le processus interactif, et grâce à un système de mémoire, permetterait au LLM d’interagir avec et de les couper.
Outils disponibles via le serveur kali MCP customisé
Avec ce système de sessions, le LLM est en capacité d’en créer en parallèle, d’interagir avec en simultané et de les couper si nécessaire. Voici un exemple avec responder :
Récupération d’un hash Net-NTLM via une session interactive par Claude
N.B : Le MCP modifié est disponible sur ce lien github. Toutes les contributions et suggestions sont bienvenues !
Prompt for the win
Nous avons modifié le serveur MCP et donc la manière d’utiliser les outils. Mais il reste une dernière brique à mettre en place : le prompt
Une personne à beau avoir le meilleur modèle possible, si ce dernier n’a pas le bon prompt, le LLM ne sera pas capable de réussir à faire ce qu’on souhaite. Après plusieurs tests empiriques, il a été trouvé qu’un bon prompt respecte ces critères :
- Persona : Le prompt doit avoir un “persona”. C’est la première phrase permettant au LLM de situer son rôle et de l’associer au contexte. Par exemple, pour une Red team interne, le persona pourrait être le suivant :
- Tooling : Le prompt doit présenter brièvement les outils qui sont à disposition du LLM. Par exemple :
- Format : Le LLM a beau avoir été entraîné avec des données humaines, il préfère un format permettant d’identifier rapidement les différentes parties du prompt. En utilisant des balises, ou en adaptant le format Markdown, le prompt est beaucoup plus lisible par le LLM :
David contre GOADliath
Une fois que nous avons modifié les capacités d’intéractions du LLM, on peut se poser la question suivante : Quelle serait leur performance face à un Active Directory, rendu vulnérable avec des mauvaises configurations, tel un GOAD ?
N.B. : GOAD est un environnement Active Directory basé sur l’univers Game of Thrones ayant des vulnérabilités volontairement introduites, afin de s’exercer à les exploiter. Créé par MayFly, disponible ici
A partir d’un seul prompt, sans aucune information sur l’environnement Active Directory, combien de temps prendrait le LLM avant de devenir Domain Administrator ? C’est ce que nous avons voulu savoir. Voici les modèles qui participeront à cette “compétition” :
- Gemini 3 Pro
- Claude Opus 4.5
N.B. : Les parties suivantes vont aborder les chemins sélectionnés par les IA. Les concepts ne seront pas vulgarisés ni expliqués, mais chaque technique possède un lien permettant au lecteur de comprendre la technique utilisée.
Claude 4.5 Opus
Dans sa première étape, Claude a constaté que l’ensemble des machines dans GOAD avaient des noms “Game Of Thrones”. Par conséquent, il a créé une liste d’utilisateurs basés sur Game Of Thrones :
Création d’une liste d’utilisateurs basée sur Game Of Thrones
Une fois cette liste faite, il a trouvé l’utilisateur “missandei”, qui n’avait pas la pré authentification Kerberos activée. Par conséquent, il a obtenu son TGT, et l’a craqué, obtenant un premier compte dans le domaine “essos.local” :
Obtention d’un premier utilisateur sur “essos.local”
Par la suite, il a obtenu également le TGT de “brandon.stark” via la même technique, lui permettant d’obtenir un compte dans le domaine enfant “north.sevenkingdoms.local” :
Obtention d’un second utilisateur sur “north.sevenkingdoms.local”
Une fois que Claude a obtenu un compte, il a pu énumérer le domaine et constater que plusieurs utilisateurs étaient vulnérable au Kerberoasting (utilisateur avec un SPN) lui permettant d’obtenir leur TGT également :
Identification d’une délégation contrainte sur “jon.snow”
Cependant, il a concentré ses efforts sur “jon.snow” car ce dernier permettait d’effectuer une Délégation contrainte sur “WINTERFELL” qui est le DC de “north.sevenkingdoms.local” :
Identification de la cible de la délégation constrainte
Une fois la délégation contrainte effectuée, Claude a pu usurper le compte administrateur “Administrator@north.sevenkingdoms.local” sur “WINTERFELL” et exfiltrer l’ensemble de la base NTLM du domaine enfant “NORTH”. Le premier domaine tombe en 21 min !
Une fois le domaine enfant obtenu, il ne reste plus qu’à forger un Golden Ticket avec le SID ‘Enterprise Admins’ injecté dans le sIDHistory (le principal groupe octroyant des droits sur l’ensemble de la forêt), ce que fait Claude :
Identification des SID nécessaires pour construire le golden ticket
Message de Claude disant que le domaine “sevenkingdoms.local” a été compromisé
Dump du domaine “sevenkingdoms.local”
Le domaine parent tombe en 26 minutes.
Gemini 3 pro
Le cheminement de Gemini était surprenamment bien différent de celui de Claude. En effet, Gemini a choisi d’exploiter le serveur Web de “CASTELBLACK”, se trouvant dans le domaine “north.sevenkingdoms.local” :
Enumération du service Web sur 192.168.10.22 (CASTELBLACK)
Une fois l’analyse du service IIS effectuée, Gemini a trouvé assez rapidement une faille de type “Upload webshell”. Ce dernier a forgé un webshell ASP et l’a téléversé afin de l’utiliser pour effectuer des commandes :
Utilisation d’un webshell sur CASTELBLACK
Encore plus surprenant, Gemini choisit de créer un reverse shell via Msfvenom, et d’utiliser une session Metasploit afin d’effectuer des commandes sur “CASTELBLACK” :
Session meterpreter ouverte permettant à Gemini de prendre le contrôle du serveur
Une fois le Meterpreter lancé, Gemini a pu obtenir tous les hashs NTLM locaux du serveur :
Utilisation de la commande “hashdump” pour obtenir les hash NTLM locaux
En utilisant l’un des hash obtenus via ce dump, Gemini a pu faire l’énumération du domaine avec bloodhound-python :
Enumération du domaine avec le compte “sql_svc” et “bloodhound-python”
L’exploitation des données provenant d’un bloodhound-python se fait généralement avec Bloodhound, un outil graphique permettant de trouver des chemins d’exploitations. Cela n’a pas empêché Gemini d’exploiter directement les résultats via les fichiers .json. Avec des commandes grep spécifiques, Gemini a pu reconstruire un chemin d’exploitation afin d’avoir un compte Administrateur du domaine :
Exploitation des fichiers .json obtenus via Bloodhound
Cette énumération faite, Gemini arrive a la même conclusion que Claude, “jon.snow” est vulnérable à une délégation contrainte :
Exploitation de la délégation contrainte avec “impacket-getST” sur le compte “jon.snow”
Le domaine enfant tombe donc en 16 minutes. La logique pour avoir le domaine parent est la même que Claude (on note le sid finissant par -519 pour cibler le groupe “Enterprise Admins”) :
Création d’un golden ticket avec “impacket-ticketer”
Le domaine parent tombe en 18 minutes.
Comparatif et conclusion
Il semble clair par rapport aux résultats techniques que le grand gagnant est Gemini 3 Pro. Cependant, notre conclusion est plus contrastée.
Gemini est le modèle le plus rapide, mais Claude est le modèle le plus “complet”. En effet, les 2 modèles ont réussi à obtenir leur objectifs, mais le reporting pendant et après les tests était beaucoup plus clair et détaillé. Et lors d’un pentest interne, ce qui reste à la fin c’est le rapport, indépendamment des techniques employées…
Gemini 3 pro a aussi eu beaucoup de mal à respecter les limites. En effet, après avoir spécifié dans le prompt que le LLM n’avait pas le droit de toucher à un fichier autre que “/tmp/ai” par exemple, Claude a compris et n’a jamais modifié de fichier en dehors, alors que Gemini a tenté par plusieurs reprises d’installer des paquets ou d’éditer le fichier /etc/hosts (ce qui est en soi, légitime mais non autorisé). C’est pourquoi nous recommandons d’utiliser ces LLM seulement dans un environnement conteneurisé.
Maintenant, est ce que le pentesteur sera remplacé par un LLM ? Il est clair qu’un pentesteur ne pourra pas forcément réussir ces tâches en si peu de temps, et qu’un niveau de technicité tel que montré par les différents LLM prend plusieurs années à obtenir.
Cependant, l’humain donne plusieurs choses que ne pourra pas offrir un LLM :
- Transparence : Un LLM a tendance à parfois cacher des actions et/ou à transgresser des règles s’il pense que le faire permet d’obtenir l’objectif. Ainsi, même si on interdit toutes les actions pouvant mener à un problème de disponibilité, le LLM peut quand même en faire.
- Conseil : Un pentester, de par son parcours et ses expériences peut donner des conseils réalistes, nuancés et débattre avec le client afin de déterminer la meilleure remédiation possible
- Confidentialité : Il est clair que les meilleurs modèles sont les modèles en source fermées, et hébergés dans des serveurs hors UE. Ainsi, il est impossible de garantir la confidentialité de ces données, d’autant plus que certaines données peuvent être sensibles (dump de domaine, certificats, etc…)
Il est plus probable que les LLM deviennent un outil pour le pentester afin de faire des tâches répétitives, telles que l’énumération et l’identification des services vulnérables par exemple. L’IA deviendrait un outil comme un autre permettant d’aider le pentester à sa tâche, et la valeur ajoutée de l’humain serait dans le prompt, l’analyse puis la validation et l’exploitation des données.
Enfin, nous avons posé des limites quant à l’utilisation de l’IA, mais qu’en est-il des organisations étatiques qui pourraient développer leurs propres modèles, parfaitement alignés et entraînés sur leurs travaux de recherche internes. Qu’en est-il des groupes d’APT qui pourraient se passer des limites que nous nous sommes fixées ? L’intelligence artificielle permettrait aussi alors l’industrialisation de cyberattaques complexes, à la portée de main de n’importe qui ayant les moyens nécessaires…