AdStrike: A Menu-Driven AD Attack Framework With an MCP Server Instead of an API Key
AI-powered modular Active Directory red-team framework for authorized penetration testing, AD enumeration, attack-path analysis, Kerberos/ADCS workflows, reporting, operator automation, and MCP server integration.
At a glance
- What is it?
- AdStrike wraps Impacket, Certipy, NetExec and BloodHound in a single Python session and exposes 53 tools over the Model Context Protocol. The interesting design choice is that the LLM driving it is your existing MCP host's, not a bundled model.
- Who is it for?
- AdStrike suits operators already fluent with Impacket, Certipy and NetExec who want one session file instead of retyping domain, DC IP and hash into every tool. It is the wrong choice for anyone without written authorization, for Windows-only testers, and for engagements where the report must be reproducible from raw tool output alone.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 97 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Problem AdStrike Solves Is Context Loss Between AD Tools
An Active Directory assessment is not one tool. It is Impacket for Kerberos, Certipy for ADCS, NetExec for SMB and WinRM, BloodHound for path analysis, hashcat for cracking. Each has its own flags, its own credential syntax, its own output format. The operator retypes the domain, the DC IP, the base DN and the NT hash dozens of times per engagement, and a typo in a base DN produces an empty LDAP result that looks like a hardened target.
AdStrike's answer is a shared session. The README states that the framework stores target details, credentials, Kerberos state, findings, executed commands and output paths in one place, and that modules reuse that context. That is the whole pitch: not a new exploitation primitive, but a state layer over tools you already have. The target audience is a red teamer on Kali or Parrot who is tired of shell history archaeology. It is explicitly not a point-and-click tool for someone who has never run Certipy by hand, because the wrappers still depend on target state, credentials, network reachability and installed third-party tools, as the README's own release-status note admits.
How the Session, Kill-Chain Groups and MCP Server Fit Together
The architecture visible in the repository is a Python entry point (main.py) driving a menu of 58 entries: 52 attack modules, 4 utilities and 2 management functions, grouped into 9 kill-chain phases running from reconnaissance through advanced operations. Each module is a wrapper. It reads its parameters from the session object, shells out to an external binary or Python tool, captures stdout, and writes findings and output paths back into the session. The Smart Analyst then parses that captured output and ranks next actions, which is a parsing and prioritisation layer rather than an autonomous planner.
The MCP server is the more unusual piece. According to the README it exposes all 53 tools (52 attack modules plus set_engagement) over the Model Context Protocol, so an MCP host you already run (Claude Code, Cursor, Claude Desktop) can drive the engagement using that host's own subscription. The README is emphatic that no ANTHROPIC_API_KEY is required, no Ollama install, no local model download. The optional AdStrike Agent, by contrast, does list ANTHROPIC_API_KEY in the environment table, so the two AI paths are distinct: one borrows the host's model, the other can use a direct Claude backend key. Whether the Agent path is deprecated in favour of MCP is not stated in the material.
Installing AdStrike and the .env Keys That Matter
The documented install is a clone, chmod on the two shell scripts, then bash install.sh, which creates a virtual environment and copies .env.example to .env. The README warns twice against sudo: the installer creates repo-local files such as adrt_venv/, .env and output/, and running as root leaves them root-owned. It supplies a repair command, sudo chown -R "$(id -un):$(id -gn)" ., for anyone who already made that mistake.
The .env file carries DC_IP, DC_FQDN, DOMAIN, BASE_DN, USERNAME, PASSWORD, NT_HASH, USE_KERBEROS, KRB5_CCACHE, ATTACKER_IP, ATTACKER_IFACE, ENGAGEMENT_NAME and ADSTRIKE_SHOW_SECRETS. You can also enter these interactively from the Session Manager, and the README states the session carries them across modules automatically. Other environment flags worth knowing: ADSTRIKE_SHOW_SECRETS defaults to false and masks passwords, hashes and loot in logs and reports unless enabled; ADSTRIKE_OPSEC takes loud, normal or stealth; TGT_AUTO_RENEW defaults to true. Direct module execution bypasses the menu entirely: python3 main.py --module 10, with --no-banner and --session output/ as documented variants. The recommended first-run order is [57] Session Manager, then [58] Tool Checker, then [10] AD Enumeration, [54] Smart Analyst, [56] Generate Report.
The Wrapper Dependency Is AdStrike's Real Failure Mode
The README's own status line is the honest part: menu and import health checks pass, but individual modules still depend on target state, credentials, network reachability and installed third-party tools. That sentence describes the framework's central weakness. AdStrike does not implement Kerberos or ADCS itself. It orchestrates impacket-scripts, nxc/netexec, bloodhound-python, certipy-ad, evil-winrm, kerbrute, responder, ldap-utils, hashcat, john, nmap/masscan, krb5-user, dnstool.py, dig and ldapsearch. When one of those changes a flag name or an output format, the wrapper that parses it breaks, and the failure surfaces as an empty result rather than a clean error unless you read the captured output.
install.sh installs most dependencies, and scripts/repair_tools.sh attempts to install or repair optional tools "when possible", which is not a guarantee. The practical consequence is that AdStrike is a poor fit for an air-gapped or tightly version-pinned host, and a poor fit for anyone who needs byte-level reproducibility of an exploit command. It is also the wrong tool on Windows-only infrastructure, since the requirements table names Kali Linux 2024+ or Parrot OS. And note the licence mismatch in the repository metadata: the README badge and LICENSE link point to GPLv3 while the repository's declared license field says MIT. That conflict needs resolving before you redistribute anything, and it is not a question this article can answer for you.
AdStrike Versus Running Impacket and Certipy Directly
The obvious alternative is no framework at all: run the underlying tools yourself. Impacket's own example scripts, Certipy's certipy find and certipy req, and NetExec's nxc smb and nxc ldap commands each do one job and print their own output. The difference in approach is state. Direct invocation means every command is self-contained and auditable: you can paste it into a report, rerun it verbatim, and diff the output. AdStrike trades that for continuity, so a Kerberos ticket obtained in one module is available to the next without re-exporting KRB5CCACHE by hand.
That trade is real in both directions. If your engagement requires a clean command log as evidence, the wrapper indirection costs you the exact argv that ran, unless AdStrike's executed-command record in the session captures it, which the README implies but does not demonstrate. If your engagement is long and credential-heavy, retyping is the slower and more error-prone path. A second alternative for the AI-assisted angle is to skip AdStrike's MCP server and give an MCP host direct shell access to the same tools; you lose the session store and the Smart Analyst ranking, but you also lose a parsing layer that can silently swallow tool errors.
Maintenance Cost and What the MIT/GPLv3 Conflict Implies
AdStrike is a beta/research build with no retrieved releases, so there is no versioned upgrade path to plan around. The last push recorded is 2026-06-11, and the README labels the current state v5.0. In practice, maintenance means tracking upstream churn in Impacket, Certipy, NetExec and BloodHound, because a breaking change in any of them can invalidate a module wrapper. Budget for re-running [58] Tool Checker after every dependency update, and for reading scripts/repair_tools.sh rather than trusting it.
On licensing, the repository declares MIT while the README badge and LICENSE link say GPLv3. Those two positions are not compatible for a redistribution decision, and the difference matters if you plan to bundle AdStrike into a commercial service. This is a factual conflict in the repository, not a legal opinion, and it is the first thing to clarify with the maintainer if redistribution is on your roadmap. Also treat the operational hygiene rules as non-negotiable: the README states you should never commit real engagement data and should keep .env, output/, ticket files, hashes, dumps, reports and captured loot private and redacted. ADSTRIKE_SHOW_SECRETS=false is the default for a reason.
Editorial conclusion
AdStrike suits operators already fluent with Impacket, Certipy and NetExec who want one session file instead of retyping domain, DC IP and hash into every tool. It is the wrong choice for anyone without written authorization, for Windows-only testers, and for engagements where the report must be reproducible from raw tool output alone. Before adopting it, run bash install.sh, then menu entry [58] Tool Checker, and confirm on a lab domain that your Kerberos and ADCS modules actually execute rather than failing at the wrapper boundary.
Community notes