TLDR: This article explains the thought process behind developing an AI capable of compromising an Active Directory environment without human intervention.
NB : This article is the result of internal research and development and does not reflect methods used during client engagements.
Introduction
The power of an AI is only proportional to the tools it has access to. Thus, a few years ago, when LLMs (Large Language Models) became available to the general public (notably via ChatGPT), it marked a technological breakthrough and created a fear of replacement for non-technical roles. In cybersecurity, we approach the tool as an aid to better develop, better understand, and better configure. But what if artificial intelligence could do more than that?
More generally, What is AI capable of doing in the context of an internal Red Team/Pentest?
Tooling et MCP
Model Context Protocol (MCP) is an open standard designed to securely connect artificial intelligence assistants to systems where data resides, such as local servers, databases, or professional tools (Slack, GitHub, etc.) :
Interactions between User, LLM and MCP
It acts as a “universal plug” (similar to a USB-C port for software), allowing developers to create a single, standardized connection for AI to read information or perform actions, without having to build specific integrations for each source. In short, an MCP is the building block that bridges the gap between a simple LLM and an agentic AI.
An MCP already exists for Kali Linux, and it’s called “mcp-kali-server” (available on the official Kali repository). However, our tests quickly revealed that the features of this MCP server were far below the capabilities of current LLM models, and the creation of an alternative became necessary.
Kali MCP server modifications
First, once these LLMs have been tested with the tool mcp-kali-server, Several observations were made:
- Clearly defining the available tools allows for a more effective LLM
All models tend to legitimize their actions as soon as a MCP is available. The LLM may tend to understand that the MCP is part of itself and therefore, does not necessarily ask himself questions about the legitimacy (or not) of his actions.
The different LLMs tested also have the tendency to change tools as soon as the first one did not give complete satisfaction. However, the tools offered by the Kali MCP server are not very comprehensive :
Tools available on “mcp-kali-server”
The creator’s idea of developing tools to achieve “quick wins” with these various tools is smart. However, LLM will test these tools one by one and will automatically apply a reward or penalty function based on the success or failure of the test.
Thus, if “enum4linux_scan” doesn’t work, it’s normal (and even logical) to move on to another test. But if a test is performed by the tool “execute_command” which is the “catch-all” tool allowing you to make arbitrary commands, say for example to use “netexec“, the LLM will penalize this tool, and will not be able to make another arbitrary command, let’s say “certipy–ad” for example.
- Enhanced categorization leads to better results
Now that we have demonstrated that having all the tools individually allows the LLM to function better, why not integrate all the tools directly into the LLM?
Warning on Github copilot if too many tools are loaded
Here’s what happens when more than 128 tools are loaded. The context window (that is the number of tokens the LLM can store in memory) is too small for all the tools we need. This is because the LLM needs to load all the tools into its memory to select the most appropriate one.
To address this issue, while still allowing LLM access to all tools, here is a proposal to improve tool selection capabilities :
Custom server MCP structure
This proposal allows for the inclusion of all available tools, thereby avoiding penalizing one tool more than another, and encourages reading the manual of each tool before its execution. This helps to minimize errors and therefore avoid “penalizing” a tool before it can be executed correctly.
- Let the LLM determine the timeout
The context given to the AI changes how it uses the tools. Experience shows that by informing it that its target is a “lab” environment, it goes straight to the point to save as much time as possible :
Intensive nmap scan performed by Claude (T4)
In the mcp-kali-server, the timeout is defined by a global variable which is set to 300 seconds by default:
Timeout defined by a global variable on “mcp-kali-server”
This forces the LLM to use fast timings and/or find roundabout ways to execute its command within 300 seconds.
Even worse, if we ask the LLM to adopt a “Red Team” approach, this requires long scans, with slow timings, and therefore commands that would inevitably end up expiring… We could lengthen the timeout, but this could penalize the LLM in its quest for speed if a command is held for any reason.
The chosen solution was therefore to let the LLM define the timeout for each of its commands :
Netexec scan by Claude with a 60s timeout
With this solution, depending on the behavior requested from the LLM, the model will be able to adapt the timeouts of each of its commands.
- Managing interactive tools
While LLMs execute instant commands without any issue, they experience difficulties with interactive tools such as responder, ntlmrelayx, etc… And that’s normal! The timeout is fixed, so they are limited to the number of seconds they have left. Therefore, tricks have been developed by those models to make these tools work :
Using an interactive tool with a one-liner
To support these tools, we developed new capabilities via MCP to handle session creation. These sessions run the interactive process, allowing the LLM to interact with and interrupt them through a memory system.
Tools available via the customized Kali MCP server
With this session system, the LLM can create sessions in parallel, interact with them simultaneously, and terminate them if necessary. Here’s an example using responder :
Retrieving a Net-NTLM hash via an interactive session by Claude
Note : The modified MCP is available on this github link. Any contribution or suggestions are welcome !
Prompt for the win
We have modified the MCP server and therefore the way the tools are used. But there is one last piece of the puzzle to put in place : the prompt
Even if someone has the best possible model, if they don’t have the right prompt, the LLM won’t be able to achieve the desired result. After several empirical tests, it was found that a good prompt meets these criteria :
- Persona : The prompt must have a “persona”. This is the first sentence that allows the LLM to define its role and connect it to the context. For example, for an internal Red Team, the persona could be the following :
- Tooling : The prompt should briefly present the tools available to the LLM. For example :
- Format : Although LLM was trained with human data, it prefers a format that allows for quick identification of the different parts of the prompt. This can be achieved by using tags or adapting the Markdown format :
David vs GOADliath
Once we have modified the LLM’s interaction capabilities, we can ask the following question: How would their performance be against an Active Directory made vulnerable by poor configurations, like a GOAD?
N.B. GOAD is an Active Directory environment based on the Game of Thrones universe with intentionally introduced vulnerabilities, designed for practice in exploiting them. Created by MayFly, available here
From a single prompt, without any information about the environment Active Directory, How long would it take for an LLM to become a Domain Administrator? That’s what we wanted to find out. Here are the models that will participate in this “competition” :
- Gemini 3 Pro
- Claude Opus 4.5
The following sections will address the paths selected by AI. The concepts will not be simplified or explained, but each technique will have a link allowing the reader to understand the technique used.
Claude 4.5 Opus
In his first step, Claude observed that all the machines in GOAD had “Game of Thrones” names. Therefore, he created a list of Game of Thrones-based users :
Creating a user list based on Game of Thrones
Once this list was compiled, he found the user “missandei”, who did not have Kerberos pre-authentication enabled. Consequently, he obtained his TGT and cracked it, obtaining his first account in the “essos.local” domain :
Acquiring the first user on “essos.local”
Subsequently, he also obtained the TGT of “brandon.stark” via the same technique, allowing him to obtain an account in the “north.sevenkingdoms.local” child domain :
Obtaining a second user on “north.sevenkingdoms.local”
Once Claude obtained an account, he was able to list the domain and see that several users were vulnerable to Kerberoasting (user with an SPN) allowing them to obtain their TGT as well :
Identification of a constrained delegation on “jon.snow”
However, he focused his efforts on “jon.snow” since it allowed him to perform a Constrained delegation on “WINTERFELL”, which is the DC of “north.sevenkingdoms.local”:
Identification of the target of the constrained delegation
Once the constrained delegation was carried out, Claude was able to usurp the administrator account “Administrator@north.sevenkingdoms.local” on “WINTERFELL” and exfiltrate the entire NTLM database from the child domain “NORTH”. The first domain is compromised in 21 min !
Once the child domain is obtained, all that remains is to forge a Inter-Realm Golden Ticketwith the ‘Enterprise Admins’ SID injected into the sIDHistory (the primary group that allows rights over the entire forest), which Claude does :
Identification of the SIDs needed to build the golden ticket
Message from Claude saying that the domain “sevenkingdoms.local” has been compromised
Dump of the domain “sevenkingdoms.local”
The parent domain is compromised in 26 minutes.
Gemini 3 pro
Gemini’s path was surprisingly quite different from Claude’s. Indeed, Gemini chose to use the “CASTELBLACK” web server, located in the “north.sevenkingdoms.local” domain :
Web service discovery on 192.168.10.22 (CASTELBLACK)
Once this was done, Gemini quickly discovered a “webshell upload” vulnerability. It then forged an ASP webshell and uploaded it to execute commands :
Using a webshell on CASTELBLACK
Even more surprisingly, Gemini chose to create a reverse shell via Msfvenom, and to use a Metasploit session to execute commands on “CASTELBLACK” :
An open Meterpreter session allowing Gemini to take control of the server
Once Meterpreter was launched, Gemini was able to obtain all the local NTLM hashes from the server :
Using the “hashdump” command to obtain local NTLM hashes
Using one of the hashes obtained from this dump, Gemini was able to enumerate the domain with bloodhound-python :
Domain enumeration with the account “sql_svc” and “bloodhound-python”
The exploitation of data from a bloodhound-python is usually done with Bloodhound, a graphical tool for finding exploitation paths. This did not prevent Gemini from directly exploiting the results via the .json files. Using specific grep commands, Gemini was able to reconstruct an exploitation path in order to compromise a domain administrator account :
Using the .json files obtained via Bloodhound
Having made this list, Gemini arrives at the same conclusion as Claude: “jon.snow” is vulnerable to constrained delegation :
Exploiting constrained delegation with “impacket-getST” on the “jon.snow” account
The children’s domain is compromised in 16 minutes. The logic for obtaining the parent domain is the same as Claude’s (note the sid ending in -519 to target the “Enterprise Admins” group):
Creating a golden ticket with “impacket-ticketer”
The parent domain is compromised in 18 minutes.
Comparatif et conclusion
It seems clear from the technical results that the big winner is Gemini 3 Pro. However, our conclusion is more nuanced.
Gemini is the fastest model, but Claude is the most “complete” model. Indeed, both models achieved their objectives, but the reporting during and after the tests was much clearer and more detailed. And in an internal penetration test, what remains in the end is the report, regardless of the techniques used.
Gemini 3 Pro also had a lot of trouble respecting the boundaries. Indeed, after specifying in the prompt that the LLM was not allowed to touch any file other than “/tmp/ai”, for example, Claude understood and never modified any file outside of that, whereas Gemini has repeatedly attempted to install packages or edit the /etc/hosts file.(which is in itself legitimate but not authorized). That is also why we recommend to use those LLM only in a containerized environment.
Now, will the pentester be replaced by an LLM? It is clear that a pentester will not necessarily be able to accomplish these tasks in such a short time, and that a level of technical expertise such as that shown by the various LLMs takes several years to achieve.
However, humans offer several things that an LLM cannot:
- Transparency: A LLM may sometimes conceal actions and/or break rules if they believe doing so will help them to achieve their objectives. Therefore, even if all actions that could lead to an availability issue are prohibited, the LLM may still perform them.
- Advice : A penetration tester, through their background and experience, can provide realistic and nuanced advice and discuss with the client to determine the best possible remediation.
- Confidentiality : It is clear that the best models are closed-source models hosted on servers outside the EU. Therefore, it is impossible to guarantee the confidentiality of this data, especially since some of the data may be sensitive (domain dumps, certificates, etc.).
It is more likely that LLMs will become a tool for the penetration tester to perform repetitive tasks, such as enumerating and identifying vulnerable services, for example. AI would become just another tool, allowing the pentester to perform their task, and the added value of the human element would lie in the initial prompt and the analysis, validation, and exploitation of the data obtained.
Finally, while we have set limits on the use of AI, what about state organizations that could develop their own models, perfectly aligned and trained on their internal research? What about APT groups that could simply bypass the boundaries we have set for ourselves? AI would then enable the industrialization of complex cyberattacks, placing them within reach of anyone with the necessary means…