Overview

An end-to-end, AI-assisted Active Directory assessment connecting the BloodHound Community Edition graph to Claude Desktop through the Model Context Protocol (MCP): install the bloodhound_mcp server, generate a BloodHound API token, and collect IGNITE.LOCAL with bloodhound-python. Natural-language prompts then drive the analysis — enumerating users, computers, and Domain Admins, surfacing every dangerous primitive (Kerberoasting, AS-REP roasting, DCSync, ForceChangePassword, AllExtendedRights with LAPS, Shadow Credentials, GenericAll over Tier Zero, GPO abuse, an AdminSDHolder backdoor, and all three delegation types), and consolidating them into a prioritised attack-surface map with remediation.

Introduction

BloodHound stores Active Directory relationships and attack paths as a Neo4j graph, normally explored through its interface or hand-written Cypher. bloodhound_mcp exposes that query surface to the Model Context Protocol, so once Claude Desktop loads it, the assistant turns plain requests into REST API queries and returns structured answers.

A single dangerous edge is a finding; the whole graph is a story. This guide moves from setup and enumeration into the misconfigurations that chain toward Domain Admin, then characterises the domain as an attacker would — which objects control Tier Zero, which paths reach Domain Admin fastest, and where delegation creates impersonation routes. Every prompt runs through the bloodhound_mcp server against the loaded IGNITE.LOCAL graph, and each result is a lead to validate inside an authorised, isolated lab.

Lab Environment

The workflow runs inside an isolated VMware lab for authorised, educational testing, combining an attacker workstation, the BloodHound stack, and a small Active Directory domain:

• Kali Linux — attacker node running bloodhound_mcp, bloodhound-python, Claude Desktop, and follow-up tooling such as Impacket and hashcat.
• BloodHound Community Edition with a Neo4j backend, reachable on the local web interface.
• Windows Server 2019 Domain Controller (DC1) hosting the IGNITE.LOCAL domain at 192.168.1.4.
• MSEDGEWIN10 — a domain-joined Windows 10 workstation with LAPS deployed, plus additional hosts referenced by the graph, such as WIN-SQL, FAKEPC, and DEMO.

All credentials, tokens, account names, IP addresses, and findings shown here belong to the lab and carry no value outside it.

Table of Contents

• Installing BloodHound MCP
• Launching BloodHound Community Edition
• Generating the BloodHound API Token
• Configuring the Environment File
• Integrating BloodHound MCP with Claude Desktop
• Collecting Active Directory Data
• Ingesting Data into BloodHound
• Querying the Domain Through Claude
• Identifying Kerberoastable Accounts
• Enumerating Domain Admins
• Enumerating All Domain Users
• Inspecting the Backup Operators Group
• Hunting for DCSync Rights
• Finding AS-REP Roastable Accounts
• Checking for Password-Not-Required Accounts
• Mapping ForceChangePassword Edges
• Abusing AllExtendedRights and LAPS
• Shadow Credentials via AddKeyCredentialLink
• GenericAll over Domain Admins
• Self-Adding to Backup Operators
• Auditing GPO Abuse
• Enumerating Domain Computers
• Sweeping Outbound Object-Control ACLs
• Uncovering the AdminSDHolder Backdoor
• Finding the Shortest Paths to Domain Admin
• Checking RDP Access
• Hunting Constrained Delegation
• Hunting Unconstrained Delegation
• Detecting Resource-Based Constrained Delegation
• Rolling Up Dangerous Privileges
• Prioritising the Attack Surface
• Identifying Collection Gaps
• Mitigation Strategies
• Conclusion

Installing BloodHound MCP

Clone the bloodhound_mcp repository onto the Kali host and enter it. The uv package manager builds an isolated Python environment; uv sync installs every dependency at once — a CPython 3.11.15 environment with all 55 packages.

git clone https://github.com/mwnickerson/bloodhound_mcp.git
cd bloodhound_mcp
uv sync

Launching BloodHound Community Edition

Start the BloodHound Community Edition stack with bloodhound-start, which launches Neo4j and the web app. Once it reports a process ID, the interface is live on the local loopback; sign in with the default credentials, changed on first login.

bloodhound-start

BloodHound now serves its web UI at http://127.0.0.1:8080 with the default user admin and password admin.

Generating the BloodHound API Token

The MCP server authenticates through the REST API, not the web session, so it needs a token. Under Administration, then Manage Users, use the gear menu beside the admin account to Generate / Revoke API Tokens, recording the token ID and key.

Configuring the Environment File

Now configure the server’s .env file, which was created manually and holds the host, token ID, key, port, and scheme. Paste your token ID and key into the matching variables, keeping the rest aligned with your instance.

cd bloodhound_mcp
cat .env

The file defines the following variables, with the token values masked here for safety:

BLOODHOUND_DOMAIN=localhost
BLOODHOUND_TOKEN_ID=ce133fef-b1b...
BLOODHOUND_TOKEN_KEY=0YwlrtxkgHE...bR2jWpQA3Rg=
BLOODHOUND_PORT=8080
BLOODHOUND_SCHEME=http

Integrating BloodHound MCP with Claude Desktop

Now, bridge the server into Claude Desktop. Launch Claude Desktop on Kali, click the account chevron at the bottom of the sidebar, and open Settings from the menu.

In Settings, open Developer under the Desktop app group. The Local MCP servers page registers servers Claude can call; with none defined, click Edit Config to open the raw file.

Edit Config opens the Claude configuration directory. The file is claude_desktop_config.json, in the hidden .config/Claude folder, declaring every MCP server Claude Desktop loads at startup.

The README provides the configuration block: a server that launches with uv and points –directory at the cloned project before running main.py. Copy it and set the placeholder to your clone’s path.

Set —directory to the cloned repository’s absolute path — here /home/kali/bloodhound_mcp — so Claude Desktop starts the server with uv run main.py.

{
  "mcpServers": {
    "bloodhound_mcp": {
      "command": "uv",
      "args": [
        "--directory",
        "/home/kali/bloodhound_mcp",
        "run",
        "main.py"
      ]
    }
  }
}

Save and restart Claude Desktop. The Local MCP servers page now shows bloodhound_mcp running, confirming Claude launched it and can call its tools.

Collecting Active Directory Data

With the bridge running, gather the Active Directory data that BloodHound will analyse. Use the Python collector bloodhound-python with a set of valid domain credentials to query the Domain Controller over LDAP. The -c All switch tells the collector to harvest every available data category. The run below authenticates as the user raaz, targets the name server at 192.168.1.4, and enumerates the ignite.local domain.

bloodhound-python -u raaz -p Password@1 -ns 192.168.1.4 -d ignite.local -c All

The collector discovers IGNITE.LOCAL and pulls down 3 computers, 24 users, 53 groups, 3 GPOs, 2 OUs, and 19 containers into timestamped JSON files.

Ingesting Data into BloodHound

Back in the BloodHound web interface, use Quick Upload and drag the collector’s JSON files into the drop zone.

The dialogue lists each staged file — users, OUs, groups, GPOs, domains, and containers. Confirm and click Upload to push the data into the Neo4j graph.

BloodHound runs this as an ingest job ID 62; once Complete, all 7 files are merged into the graph and IGNITE.LOCAL is ready to query.

Querying the Domain Through Claude

With the graph and server running, drive the analysis in natural language. The help prompt lists the categories — enumeration, attack paths, and misconfigurations — with examples.

help

Ask Claude for a high-level picture of the domain. The assistant calls the bloodhound_mcp integration and returns a full domain overview for IGNITE.LOCAL, including the domain SID, the Windows Server 2016 functional level, and the totals for users, computers, groups, and OUs, along with the absence of any domain trusts.

find all domain information

The same query also reports the domain structure, listing the objects the domain directly contains. The output highlights the Domain Controllers OU as Tier Zero, alongside the TECH OU, the standard containers, and a managed service account group.

Identifying Kerberoastable Accounts

Move to attack-surface discovery: ask for every Kerberoastable account. The integration runs a Cypher query for enabled accounts carrying a Service Principal Name.

find all kerberoastable users

The result narrows to one live target, [email protected] — an enabled, low-privilege user with an SPN. The disabled KRBTGT account is skipped, leaving RAJ the ideal Kerberoasting candidate.

With RAJ the only target, Claude supplies commands to crack the ticket offline: an unauthenticated TGS request where allowed, an authenticated request with any valid account, and an offline hashcat crack of the krb5tgs hash.

impacket-GetUserSPNs IGNITE.LOCAL/raj -no-pass -dc-ip <DC_IP> -outputfile raj.hash

impacket-GetUserSPNs IGNITE.LOCAL/<user>:<pass> -dc-ip <DC_IP> -request -outputfile raj.hash

 hashcat -m 13100 raj.hash /usr/share/wordlists/rockyou.txt -r /usr/share/hashcat/rules/best64.rule

To study kerbroasting in detail, click here.

Enumerating Domain Admins

Next, the domain’s most sensitive group: the two Domain Admins, built-in ADMINISTRATOR and KRISHNA. Both are enabled with adminCount, and ADMINISTRATOR also carries password-never-expires, worth noting for the report.

show me all Domain Admins in ignite.local

Enumerating All Domain Users

With the privileged accounts mapped, ask Claude for a complete user inventory. The integration runs a Cypher query and returns all 19 accounts in IGNITE.LOCAL, scoring each one against the attributes that matter for attack planning — Enabled, AdminCount, Kerberoastable, AS-REP Roastable, password-never-expires, and password-not-required. The first page of the breakdown already flags useful leads: ADMINISTRATOR carries a password-never-expires setting, RAM and SITA hold adminCount, RAJ is Kerberoastable, and KOMAL is AS-REP roastable.

show all users in IGNITE.LOCAL

The remainder of the table lists the standard accounts — RUDRA, SANJEET, SHIVAM, SHREYA, and TOM — as enabled with no special flags, while the built-in KRBTGT and GUEST accounts appear disabled.

Inspecting the Backup Operators Group

Privileged groups come next. Backup Operators has one member, [email protected], already Tier Zero — concentrating risk. Claude’s path: compromise RAM, copy NTDS.dit from the DC via a VSS shadow copy, and dump every domain hash offline.

Show members of the backup operator group

The remote session uses Evil-WinRM against the Domain Controller with RAM’s credentials:

evil-winrm -i DC1.IGNITE.LOCAL -u ram -p ‘<pass>’

Hunting for DCSync Rights

DCSync rights allow an account to replicate directory data — including password hashes — directly from the Domain Controller, so they warrant a dedicated check. Claude queries the principals that hold the replication rights on the domain object and returns the expected groups (Administrators, Domain Controllers, Enterprise Domain Controllers, and Enterprise Read-Only Domain Controllers) marked Normal, plus one entry marked Critical: [email protected]. SHIVAM appears twice because both GetChanges and GetChangesAll are assigned, which is the exact combination a full DCSync requires.

check for DCSync rights

SHIVAM is a standard domain user with no admin memberships, yet holds explicit DCSync rights on the domain object — anyone compromising it can dump every credential in IGNITE.LOCAL without touching a Domain Admin. Once SHIVAM’s password is recovered, DCSync runs:

impacket-secretsdump IGNITE.LOCAL/shivam:'<password>’@DC1.IGNITE.LOCAL

This dumps the NT hashes of every domain account, including ADMINISTRATOR, KRISHNA, and the krbtgt hash that enables Golden Ticket persistence. Claude also supplies the remediation: using ADSI Edit, remove the GetChanges and GetChangesAll ACEs from SHIVAM — the Replicating Directory Changes and Replicating Directory Changes All entries on the domain root.

Finding AS-REP Roastable Accounts

AS-REP roasting targets accounts without Kerberos pre-authentication, whose blob is crackable offline without credentials. Claude finds exactly one, [email protected] — a clean, enabled, low-privilege target — and recaps the surface: KOMAL for AS-REP, RAJ for Kerberoasting.

find all AS-REP roastable users

Request KOMAL’s AS-REP hash without authentication, then crack it offline with hashcat:

impacket-GetNPUsers IGNITE.LOCAL/komal -no-pass -dc-ip <DC1_IP> -format hashcat -outputfile komal.hash

hashcat -m 18200 komal.hash /usr/share/wordlists/rockyou.txt -r /usr/share/hashcat/rules/best64.rule

 Checking for Password-Not-Required Accounts

Accounts with the passwordnotreqd flag can authenticate with a blank password. Claude returns one, [email protected], but qualifies it: GUEST is disabled, so the flag poses no active risk and is standard across Windows domains.

find accounts with password not required

Mapping ForceChangePassword Edges

ForceChangePassword lets one principal reset another’s password without the current one. Claude finds a single edge — [email protected] can reset [email protected] — but both are dead ends (Domain Users only): a real but low-impact misconfiguration.

show all Reset Password Edges

To learn more about forced password change, click here.

Abusing AllExtendedRights and LAPS

AllExtendedRights over a computer include reading LAPS-managed local administrator passwords. Claude finds one edge: [email protected], a non-admin user, holds AllExtendedRights over MSEDGEWIN10.IGNITE.LOCAL. AARTI is otherwise unremarkable, so the right itself is the problem.

show all allExtendedright Edges

With LAPS deployed on MSEDGEWIN10, AllExtendedRights grants AARTI the ReadLAPSPassword right, letting it read the local Administrator password with no privileges and pivot onto that host — a High-severity edge.

To learn more about extended rights, click here.

Shadow Credentials via AddKeyCredentialLink

Shadow Credentials abuse the msDS-KeyCredentialLink attribute. [email protected] holds AddKeyCredentialLink over all domain users through its Key Admins and Enterprise Key Admins membership.

shadow Credentials Attack

Claude details the chain as SITA: write a rogue key credential to the target’s msDS-KeyCredentialLink with pywhisker or Whisker, authenticate via PKINIT with gettgtpkinit.py, extract the NT hash with UnPAC-the-Hash, and reuse it for Pass-the-Hash or DCSync. Pointed at Domain Admin KRISHNA, the chain reads:

SITA -> AddKeyCredentialLink on KRISHNA -> PKINIT TGT -> UnPAC-the-Hash -> KRISHNA NT hash -> Pass-the-Hash as DA

GenericAll over Domain Admins

GenericAll grants full control over an object, over a group, and the right to add members. One of the most serious findings: [email protected], a plain non-admin user, holds GenericAll over the Tier Zero DOMAIN ADMINS group, its only source of power.

show all GenericAll Edges

Because GenericAll over a group includes AddMember, AARU can add itself straight into Domain Admins — instant Domain Admin with zero exploitation, a single hop:

AARU -> GenericAll -> DOMAIN ADMINS -> Domain Admin

ADDSelf Write

Next, who can add themselves to a group? One AddSelf edge targets a Tier Zero group: [email protected] can add itself to BACKUP [email protected], gaining SeBackupPrivilege to extract NTDS.dit from DC1 — the technique RAM used. Rated Critical.

which users can add themselves to a group?

Auditing GPO Abuse

Write access to a domain-linked GPO is effectively domain-wide code execution. [email protected], a regular user (adminCount false), holds WriteOwner, GenericWrite, and WriteDacl over VULN GPO, linked to the IGNITE.LOCAL domain root — any one lets her take ownership, rewrite the DACL, or modify the policy.

Want me to check GPoAbuse

To learn more about GPO abuse, click here.

Enumerating Domain Computers

The picture needs hosts as well as accounts. IGNITE.LOCAL has three computers: DC1 on Windows Server 2019, MSEDGEWIN10 on Windows 10 Enterprise, and DEMO, with no OS data collected.

Show all computers in IGNITE.LOCAL

Sweeping Outbound Object-Control ACLs

Rather than checking one edge type at a time, Claude sweeps every outbound object-control ACL in one pass, asking for all users with control rights over other objects.

Find all users with outbound Object Control ACL

The image below shows a BloodHound-style attack-path table from the IGNITE.LOCAL enumeration; each row maps a principal (User) to a privilege (Edge) over a Target, with a severity rating:

• Columns: User (the principal holding the right), Edge (the abusable permission/relationship), Target (the object the right applies to), Target Type (object class), and Severity (risk ranking — Critical/High/Medium).
• AARU → GenericAll → Domain Admins (Group, CRITICAL): full control; AARU can add itself or anyone, granting domain dominance.
• GEET → GenericAll → Domain Controllers OU (OU, CRITICAL): full control over the OU holding the DCs, enabling a malicious GPO link or OU changes that compromise the controllers.
• SHIVAM → GetChanges + GetChangesAll → IGNITE.LOCAL (Domain, CRITICAL): These two replication rights together permit a DCSync attack — impersonating a DC to pull all password hashes, including krbtgt and Domain Admins.
• SHIKHA → WriteOwner + GenericWrite + WriteDacl → VULN GPO (GPO, CRITICAL): three rights over a GPO; any lets SHIKHA modify it (e.g., a startup script or scheduled task) to run code on every object it applies to — a classic GPO abuse path.
• AARAV → AddSelf → Backup Operators (Group, HIGH): adds itself to Backup Operators, whose backup rights over SAM/NTDS.dit lead to credential theft.
• AARTI → AllExtendedRights → MSEDGEWIN10 (Computer, HIGH): all extended rights over a workstation, including reading the LAPS local-admin password.
• RAAZ → WriteDacl → SANJEET (User, MEDIUM) and SHREYA → WriteDacl → ANKUR (User, MEDIUM): rewrite the target’s DACL to grant further rights — password reset, Shadow Credentials, or targeted Kerberoasting.
• TOM → ForceChangePassword → JERRY (User, MEDIUM): resets JERRY’s password without the current one, enabling account takeover.

Overall takeaway: the Critical rows — DCSync via SHIVAM, Domain Admins via AARU, DC OU via GEET, GPO abuse via SHIKHA — each lead to full domain compromise. The High/Medium rows are lateral-movement and escalation steps that chain into them.

Uncovering the AdminSDHolder Backdoor

AdminSDHolder is a template whose DACL the SDProp process copies onto every protected account hourly — making write access a stealthy, self-healing backdoor. [email protected], a regular user (adminCount false), holds GenericAll over it, alongside the expected Domain Admins and Enterprise Admins entries.

find adminsdholder

Because the AdminSDHolder DACL propagates to all protected accounts — Domain Admins, Enterprise Admins, KRBTGT, ADMINISTRATOR, KRISHNA, RAM, and SITA — KINJAL effectively gains GenericAll over every one, leading straight to total compromise:

KINJAL -> GenericAll -> ADMINSDHOLDER

        -> (SDProp runs every 60 min)

        -> GenericAll propagated to ADMINISTRATOR, KRISHNA, RAM, SITA, KRBTGT

        -> Reset DA password / Shadow Credentials / Kerberoast any admin

        -> Full Domain Compromise

Finding the Shortest Paths to Domain Admin

Claude then ranks how fast each non-admin reaches Domain Admin: AARU in one hop via GenericAll, SHIVAM in three via DCSync, SHIKHA in four via VULN GPO, and GEET in five via the Domain Controllers OU plus coercion against DC1. The one-hop AARU path is the priority.

find shortest path to DA

Checking RDP Access

Remote Desktop rights turn graph control into hands-on access. Only JERRY belongs to Remote Desktop Users, and no CanRDP edges exist because session collection was not run. JERRY likely has direct RDP, TOM gains it by resetting JERRY’s password, and Domain Admins keep RDP by default.

domain users can rdp

Hunting Constrained Delegation

Constrained delegation lets a principal impersonate users to a specific service — dangerous when that principal is crackable. [email protected] holds AllowedToDelegate to WIN-SQL.IGNITE.LOCAL and is also Kerberoastable, so the weaknesses chain: crack it offline, then impersonate any user — including ADMINISTRATOR — on WIN-SQL.

find constrained delegation

The resulting chain is:

Kerberoast KAVISH -> crack password -> impersonate ADMINISTRATOR on WIN-SQL

Hunting Unconstrained Delegation

Unconstrained delegation caches the TGT of every user authenticating to the host, so a non-DC with it is a prime target. Claude finds two: DC.IGNITE.LOCAL, expected since DCs use it by default, and WIN-SQL.IGNITE.LOCAL, a non-DC where it is dangerous.

find unconstrained delegation

Detecting Resource-Based Constrained Delegation

Resource-based constrained delegation stores the allowed delegators on the target itself, so a pre-staged entry is a ready-made backdoor. FAKEPC.IGNITE.LOCAL already appears in DC.IGNITE.LOCAL’s msDS-AllowedToActOnBehalfOfOtherIdentity — whoever controls FAKEPC can impersonate any user, including Administrator, against the DC: an RBCD backdoor into Tier Zero.

find resource based constrained delegation

Rolling Up Dangerous Privileges

Claude consolidates the dangerous privileges into grouped tables: DCSync rights (SHIVAM’s GetChanges and GetChangesAll), dangerous group memberships for non-admins (JERRY in Remote Desktop Users), and sensitive memberships such as SITA in Key Admins and Enterprise Key Admins, granting domain-wide Shadow Credentials.

dangerous privileges

A Full Dangerous Privilege Map pairs each principal with its technique — SHIVAM with impacket-secretsdump, SITA with pywhisker, AARU adding itself to Domain Admins, GEET abusing the DC OU, SHIKHA modifying the GPO, AARAV using SeBackupPrivilege, JERRY pivoting over RDP, AARTI reading LAPS, and TOM resetting JERRY.

Prioritising the Attack Surface

Claude then ranks findings by severity. The Critical tier holds the immediate domain-compromise paths: AARU self-adding to Domain Admins, SHIVAM’s full DCSync, GEET linking a GPO to the DC OU for SYSTEM on DC1, and SHIKHA modifying the domain-wide GPO.

updated attack surface summary

The High tier collects escalation routes — AARAV’s self-add to Backup Operators, SITA’s Shadow Credentials path, AARTI’s LAPS read, and the roastable accounts KAVISH, RAJ, and KOMAL, each cracking to a plaintext password.

The Medium tier captures lateral movement and lower-impact abuse: RAAZ and SHREYA with WriteDacl over users, TOM’s reset of JERRY into RDP, JERRY’s RDP membership, RAM’s WinRM path to NTDS.dit, the pre-Windows 2000 Compatible Access exposure, and the stale ADMINISTRATOR password.

Mitigation Strategies

The findings are almost entirely configuration and ACL problems, not software bugs, and small weaknesses compound into a full compromise. The fixes centre on removing unauthorised control, tightening delegation, and watching the graph:

• Remove the critical object-control edges — SHIVAM’s GetChanges and GetChangesAll, KINJAL’s GenericAll over AdminSDHolder, AARU’s over Domain Admins, GEET’s over the Domain Controllers OU, and SHIKHA’s three rights over VULN GPO — so no standard user holds privileged control.
• Reset the AdminSDHolder DACL to default and investigate how the unauthorised ACE was added, since SDProp will otherwise keep re-propagating it.
• Audit GPO permissions and links so no standard user can modify any GPO linked to the domain root or the Domain Controllers OU.
• Restrict Tier Zero membership and the rights that reach it — keep Domain Admins, Backup Operators, Key Admins, and Enterprise Key Admins to accounts that need them, and remove AARAV’s AddSelf edge.
• Eliminate dangerous delegation: remove KAVISH’s constrained delegation to WIN-SQL, disable unconstrained delegation on WIN-SQL, and clear the pre-staged RBCD entry for FAKEPC from the Domain Controller’s msDS-AllowedToActOnBehalfOfOtherIdentity attribute.
• Assign long, random passwords or Group Managed Service Accounts to roastable accounts such as KOMAL, RAJ, and KAVISH, and disable Kerberos pre-authentication only where unavoidable.
• Protect LAPS read access by limiting which principals hold AllExtendedRights or ReadLAPSPassword on computer objects, and constrain RDP and remote-access membership.
• Monitor msDS-KeyCredentialLink for unexpected writes to catch Shadow Credentials, alert on enabled-status changes to accounts like GUEST, and remove password-never-expires from privileged accounts such as ADMINISTRATOR.
• Close the visibility gaps by re-collecting with local-group, session, and ADCS data so RDP, session, and certificate-template paths become measurable.
• Run BloodHound on a schedule as a defensive baseline, re-collecting after changes so these paths are severed before an adversary walks them.

Conclusion

Connecting BloodHound to Claude Desktop via the Model Context Protocol turned a fresh collection into a complete, prioritised attack surface map of IGNITE.LOCAL. Plain-English prompts carried the assessment from installation through enumeration and every primitive — Kerberoasting, DCSync, Shadow Credentials, GPO abuse, AdminSDHolder, and all three delegation types — into a ranked breakdown of Critical, High, and Medium. The integration does not replace analyst judgment; it shortens the distance between raw graph data and an actionable report, used responsibly in an authorised lab.