AdStrike

Authorized use only. Do not run this tool against systems without explicit written permission.

Release status: beta/research build. Menu and import health checks pass; individual modules still depend on target state, credentials, network reachability, and installed third-party tools.

Overview

AdStrike is a modular, terminal-based Active Directory attack framework. It helps operators move through discovery, enumeration, exploitation, credential access, lateral movement, persistence, and reporting while keeping session state in one place.

The framework stores target details, credentials, Kerberos state, findings, executed commands, and output paths in a shared session. Modules can reuse that context instead of forcing the operator to re-enter the same data repeatedly.

🔑 No API key required. AdStrike now ships an MCP server that exposes all 53 tools (52 attack modules + set_engagement) over the Model Context Protocol. Plug it into an MCP host you already use — Claude Code, Cursor, Claude Desktop — and that host's LLM drives the whole engagement with its own subscription. No Ollama, no ANTHROPIC_API_KEY, no local model to download. See MCP Server (No API Key) below and docs/mcp.md.

Core capabilities:

• 58 interactive menu entries: 52 attack modules, 4 utilities, 2 management functions
• 9 kill-chain phase groups, from reconnaissance through advanced operations
• Kerberos-aware workflows for NTLM-disabled and LDAP-signing-enforced environments
• Smart Analyst for parsing output and ranking next actions
• Optional AdStrike Agent for AI-assisted planning or tool orchestration
• MCP server exposing all 53 tools — no API key, driven by your existing MCP host (Claude Code / Cursor / Claude Desktop)
• Report generation in HTML, Markdown, and JSON
• Wrappers for common AD tooling such as Impacket, NetExec, Certipy, Kerbrute, BloodHound, PowerView, Rubeus, and related utilities

Screenshots

AD Enumeration	BloodHound Helper

AdStrike Agent	Smart Analyst

How to use

Quick Start

git clone https://github.com/capture0x/AdStrike.git
cd AdStrike   
chmod +x install.sh run.sh
bash install.sh
source venv/bin/activate
bash run.sh
OR
git clone https://github.com/capture0x/AdStrike.git && cd AdStrike && chmod +x install.sh run.sh && bash install.sh && source venv/bin/activate && bash run.sh

Do not run install.sh or run.sh with sudo. The installer creates repo-local files such as venv/, .env, and output/; running as root can leave those files root-owned.

If you already ran it with sudo, fix ownership once:

sudo chown -R "$(id -un):$(id -gn)" .

Requirements

Key external tools:

impacket-scripts    nxc / netexec       bloodhound-python    certipy-ad
evil-winrm          kerbrute            responder            ldap-utils
hashcat             john                nmap / masscan       krb5-user
dnstool.py          dig                 ldapsearch

Most dependencies are installed by install.sh. Some optional tools are installed or repaired by scripts/repair_tools.sh when possible.

Configuration

The installer copies .env.example to .env. Edit .env before an engagement:

DC_IP=10.10.10.10
DC_FQDN=dc1.corp.local
DOMAIN=corp.local
BASE_DN=DC=corp,DC=local
USERNAME=user
PASSWORD=
NT_HASH=
USE_KERBEROS=false
KRB5_CCACHE=
ATTACKER_IP=10.10.14.5
ATTACKER_IFACE=tun0
ENGAGEMENT_NAME=Corp-Internal-2026
ADSTRIKE_SHOW_SECRETS=false

You can also enter these values interactively from the Session Manager. The session carries them across modules automatically.

Never commit real engagement data. Keep .env, output/, ticket files, hashes, dumps, reports, and captured loot private and redacted.

Useful environment flags:

Usage

Start the interactive menu:

bash run.sh

Recommended first-run flow:

[57] Session Manager  -> configure target and credentials
[58] Tool Checker     -> verify external tools and module imports
[10] AD Enumeration   -> collect baseline LDAP/SMB/GPO data
[54] Smart Analyst    -> parse output and rank next steps
[56] Generate Report  -> export findings and evidence

Direct module execution:

python -m venv venv     
source venv/bin/activate
python3 main.py --module 10
python3 main.py --module 58 --no-banner
python3 main.py --session output/session.json --no-banner

Health check:

python3 -m py_compile main.py
python3 main.py --check

Current local health check:

Menu numbering is contiguous and unique
Module health OK: 56/56

Module Map

Reconnaissance

Initial Access

Enumeration

Privilege Escalation

Lateral Movement

Credential Access

Persistence

Cloud / Hybrid

Advanced Operations

Utilities

Output

Runtime files are written under output/:

Review and redact everything in output/ before sharing.

Automatic Target Discovery

During first-run session setup, entering a DC IP triggers a fast discovery pass:

1. LDAP rootDSE query to derive DOMAIN, BASE_DN, and DC_FQDN when available.
2. NetExec SMB fallback when LDAP does not reveal the domain.
3. Optional quick nmap check of common AD ports.

Force the port check:

ADSTRIKE_PORT_CHECK=true bash run.sh

If a DC FQDN is discovered, AdStrike prints an /etc/hosts line for environments where DNS resolution is unreliable. If clock skew is detected, it prints a time-sync hint before Kerberos-heavy workflows.

Kerberos and NTLM-Disabled Environments

For targets where NTLM is disabled or unreliable, use:

[18] Kerberos Attacks -> [A] NTLM-Disabled Attack Workflow

This workflow can:

• Generate target-specific krb5.conf
• Add the DC FQDN mapping guidance
• Request a TGT with Impacket
• Set KRB5CCNAME and KRB5_CONFIG
• Enable Kerberos mode for later modules
• Print ready-to-use Kerberos commands for NetExec, Impacket, BloodHound, and Evil-WinRM

Common Kerberos checks:

date
klist
cat "$KRB5_CONFIG"
echo "$KRB5CCNAME"

AdStrike Agent

AdStrike Agent is optional. Manual modules do not require AI. Want to try just the agent? → github.com/capture0x/AdAgent

Supported backends:

Ollama example:

ollama serve
ollama pull mistral
bash run.sh
# choose [51] AdStrike Agent (AI)
# choose Backend [1] Ollama

Claude example:

export ANTHROPIC_API_KEY="sk-ant-..."
bash run.sh
# choose [51] AdStrike Agent (AI)
# choose Backend [2] Claude

Agent modes:

OPSEC modes:

MCP Server (No API Key)

No ANTHROPIC_API_KEY, no Ollama, no local model. On this path AdStrike runs no LLM of its own. It exposes its AD-attack tools over the Model Context Protocol, and an MCP host you already have — Claude Code, Cursor, Claude Desktop — drives the engagement with its own subscription. The host is the brain; AdStrike is the toolbox.

All 53 tools are published — the 52 attack tools (nmap_scan, enumerate_ldap, adcs_scan, evil_winrm, gmsa_read, dcsync_attack, kerberoast, …) plus set_engagement — using the exact same schemas the standalone agent uses (modules/agent/_core.py), so there is one source of truth and no duplication.

1. Verify the server can load (uses the project venv):

./venv/bin/python3 -c "import mcp; from modules.agent._core import TOOLS; print('ok', len(TOOLS))"

2. Register in Claude Code. The repo already ships a project .mcp.json with repo-relative paths, so if you start Claude Code from the AdStrike folder (step 3) you can skip this step — it is picked up automatically:

{
  "mcpServers": {
    "adstrike": {
      "command": "venv/bin/python3",
      "args": ["mcp_server.py"]
    }
  }
}

To register it globally (so it works from any directory) use absolute paths via CLI:

claude mcp add adstrike -- /path/to/AdStrike/venv/bin/python3 /path/to/AdStrike/mcp_server.py

Cursor and Claude Desktop use the same command + args shape in their MCP config.

3. Start Claude Code from the AdStrike folder. A project .mcp.json is only loaded when claude launches from the directory that contains it, so run it there:

cd /path/to/AdStrike
claude

On first launch Claude Code asks you to approve the adstrike MCP server — accept it. Confirm the tools are live with /mcp inside Claude Code (or claude mcp list from the shell). Cursor and Claude Desktop pick the server up after a restart.

4. Use it. Set the engagement once, then let the host drive:

set_engagement: dc_ip 10.0.0.1, domain corp.local, username alice, password … (or nt_hash)

AdStrike stores the target and credentials in the session and injects them into every later tool call, so the host LLM never has to repeat the password and can't accidentally target the wrong host or account. From there the host reads each tool's output and picks the next tool — nmap → LDAP enum → BloodHound → the matching abuse primitive — just like the built-in agent loop, but funded by the host subscription.

Example prompt — paste this into Claude Code (adjust the target) to set the engagement once and have the host drive the standard AdStrike workflow:

Use the adstrike MCP server. Call set_engagement with dc_ip 192.168.56.1,
domain corp.local, username tester, password 'Pass123!'.

Then run the same workflow as the AdStrike agent:
  1. nmap_scan
  2. no_cred_surface_recon
  3. enumerate_ldap
  4. enumerate_shares
  5. collect_bloodhound
  6. query_bloodhound_paths
  7. adcs_scan
  8. acl_abuse_scan
  9. kerberoast
  10. asrep_roast
  11. discover_winrm_access
  12. chain_planner

After each tool result, analyze the output and choose the next best AdStrike
MCP tool. Do not ask me for the password again — use the session credential
injected by set_engagement.

You only pass the credential inside set_engagement; every later tool reuses the session value, so the host never needs it again.

Full walkthrough (requirements, config for each host, OPSEC notes): docs/mcp.md.

Performance / GPU Acceleration

Why the Ollama agent may feel slow

The agent uses a rule engine for most decisions (no LLM call). Rounds that require LLM input call Ollama locally. If Ollama runs on CPU instead of GPU, each call takes 15–30 seconds instead of 2–5 seconds.

Verify which processor Ollama is using:

ollama ps
# PROCESSOR column should show "GPU", not "100% CPU"

Fix: Ollama not detecting the GPU (Kali / systemd)

On some Kali Linux setups the ollama systemd service starts before CUDA libraries are on the library path, so GPULayers:[] appears in the logs and inference falls back to CPU.

Step 1 — add CUDA environment variables to the service:

sudo nano /etc/systemd/system/ollama.service

Add these three lines inside the [Service] block:

Environment="CUDA_VISIBLE_DEVICES=0"
Environment="LD_LIBRARY_PATH=/usr/local/lib/ollama/cuda_v12:/usr/lib/x86_64-linux-gnu"
Environment="OLLAMA_GPU_OVERHEAD=0"

Full [Service] block example after the edit:

[Service]
ExecStart=/usr/local/bin/ollama serve
User=ollama
Group=ollama
Restart=always
RestartSec=3
Environment="PATH=..."
Environment="CUDA_VISIBLE_DEVICES=0"
Environment="LD_LIBRARY_PATH=/usr/local/lib/ollama/cuda_v12:/usr/lib/x86_64-linux-gnu"
Environment="OLLAMA_GPU_OVERHEAD=0"

Step 2 — reload and restart:

sudo systemctl daemon-reload
sudo systemctl restart ollama

Step 3 — confirm GPU is in use:

ollama ps
# Expected: PROCESSOR = GPU (or a percentage, not "100% CPU")

Note: The CUDA path /usr/local/lib/ollama/cuda_v12 is created by the official Ollama Linux installer. If you installed Ollama a different way, adjust the path to match where libcublas.so.12 lives on your system.

Recommended Ollama model for speed vs quality

Pull a model:

ollama pull qwen2.5-coder:7b

Repair and Troubleshooting

Check installed tools and module imports:

python3 main.py --module 58 --no-banner

Repair missing tools where possible:

bash scripts/repair_tools.sh --check
bash scripts/repair_tools.sh -y

Scoped repairs:

bash scripts/repair_tools.sh --no-apt
bash scripts/repair_tools.sh --no-pip
bash scripts/repair_tools.sh --no-github

If the virtual environment is missing:

bash install.sh
source venv/bin/activate
python3 main.py --check

If NetExec or Impacket fails, verify versions and rerun the repair script:

which nxc
nxc --version
which impacket-secretsdump
bash scripts/repair_tools.sh -y

If reports include sensitive values, confirm redaction is enabled:

ADSTRIKE_SHOW_SECRETS=false

Then review .env, output/session.json, and generated reports manually before sharing.

Documentation

Additional guides:

• AdStrike and Agent Guide
• MCP Server — No API Key (Claude Code / Cursor / Claude Desktop)

Security policy:

• SECURITY.md

License:

• GPLv3

Legal Disclaimer

This software is provided for authorized security testing, red team engagements, and educational purposes only.

Use against systems without explicit written authorization from the system owner is illegal and may violate the Computer Fraud and Abuse Act (CFAA), the Computer Misuse Act (CMA), and equivalent laws in your jurisdiction.

The author accepts no liability for damage, data loss, service disruption, or legal consequences arising from misuse.

Developer

tmrswrr - GitHub: capture0x contact - Mail : tmrswrr -at- gmail.com

Maintained for authorized offensive security research, lab validation, and professional red team operations.