BloodHound Community Edition (CE) is a powerful open-source tool used by penetration testers and red team operators to analyze Active Directory (AD) environments. It maps relationships between users, groups, computers, and permissions to reveal attack paths that could allow an attacker to escalate privileges and ultimately compromise the domain.

This guide walks through every step: installation on Kali Linux, backend setup, data collection using multiple methods, and analysis inside the BloodHound UI.

Table of Content

• Introduction to BloodHound
• Components of BloodHound
• Common Use Cases
• Installation
• Initial Setup (bloodhound-setup)
• Change Neo4j Password
• Configure bhapi.json
• Start BloodHound Server
• Login to BloodHound UI
• Upload Data
• Data Collection Methods
  • bloodhound
  • NetExec
  • Metasploit
• Understanding Graph Layout
• User & Group Enumeration
• Privilege Escalation Paths
• ACL Abuse Techniques
• High-Value Target Identification
• Attack Path Analysis
• Important BloodHound Queries
• Domain Admin Discovery
• DCSync Privilege Analysis
• AS-REP Roasting Detection
• LAPS & GMSA Abuse
• Database Management
• Risk Analysis & Prioritization
• Conclusion

It has two main components:

1. Data Collector (SharpHound / AzureHound) Collects data from the target environment via LDAP, SMB, and other protocols. Outputs JSON files (zip) that are imported into the BloodHound UI.

2. BloodHound GUI (Neo4j-backed) A web or desktop application that ingests the collected data and lets you run graph queries (Cypher) to find paths.

Common use cases

• Find shortest path to Domain Admin from any user
• Identify Kerberoastable accounts with paths to high-value targets
• AS-REP Roasting candidates
• DCSync privilege holders
• Unconstrained/Constrained Delegation abuse paths
• ACL abuse paths (WriteDACL, GenericAll, GenericWrite, etc.)

Install BloodHound

BloodHound CE is available directly from the Kali Linux package repositories. Install it using apt with the -y flag to auto-confirm prompts:

apt install -y bloodhound

This installs BloodHound CE along with all required dependencies including Neo4j, PostgreSQL libraries, and supporting packages.

Run bloodhound-setup

After installation, run the setup command to initialize all backend services including PostgreSQL and Neo4j:

bloodhound-setup

The setup process performs the following actions automatically:

• Starts the PostgreSQL service and creates the BloodHound database and user
• Starts Neo4j graph database at http://localhost:7474
• Displays default Neo4j credentials (user: neo4j / password: neo4j)
• Reminds you to update /etc/bhapi/bhapi.json after changing the password
• Opens the Neo4j browser at http://localhost:7474

Change Neo4j Default Password

BloodHound requires you to change the default Neo4j password before it can function. Open your browser and navigate to:

http://localhost:7474/browser/

Connect using the default credentials:

• Username: neo4j
• Password: neo4j

After connecting, you will be immediately prompted to set a new password. Enter and confirm your new password, then click Change password:

Update bhapi.json

After changing your Neo4j password, you must update the BloodHound API configuration file to reflect the new credentials:

cat /etc/bhapi/bhapi.json

Edit the neo4j section to update the “secret” field with your new password:

The file contains three main sections:

• “database” — PostgreSQL connection settings (addr, username, secret, database)
• “neo4j” — Neo4j connection settings (addr: localhost:7687, username: neo4j, secret: YOUR_NEW_PASSWORD)
• “default_admin” — Default BloodHound admin credentials (principal_name, password)

Start BloodHound

With Neo4j running and bhapi.json configured, start the BloodHound CE server:

bloodhound

The command will:

• Confirm Neo4j is already running (or start it)
• Start the BloodHound API server
• Open the BloodHound UI at http://127.0.0.1:8080

Login to BloodHound UI

Open your browser and navigate to the BloodHound UI:

http://127.0.0.1:8080/ui/login

Login with the default admin credentials defined in bhapi.json:

• Email Address: admin
• Password: admin (or your configured password)

Upload Data to BloodHound

After logging in, BloodHound CE will present an upload dialog. You need to upload JSON or ZIP files collected from the target Active Directory environment. You can:

• Drag and drop files anywhere on the interface
• Use the upload button in the main navigation
• Use the sample dataset link to explore the UI without real data

Data Collection Methods

BloodHound can collect data from Active Directory using three primary methods. Each is suited for different scenarios during a penetration test.

Method A — BloodHound.py (Remote, from Kali)

BloodHound.py is a Python-based collector that runs remotely from your Kali machine. It connects via LDAP to the Domain Controller and does not require placing any files on the target Windows system.

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

• -u raaz — Domain username
• -p Password@1 — Password
• -ns 192.168.1.11 — Name server (Domain Controller IP)
• -d ignite.local — Target domain
• -c All — Collect all available data (Users, Groups, Computers, GPOs, etc.)

Method B — NetExec

NetExec (nxc, successor to CrackMapExec) includes a built-in BloodHound collection module. This method is useful when you already have valid credentials and want an all-in-one enumeration approach.

nxc ldap 192.168.1.11 -u raaz -p Password@1 --bloodhound --collection All --dns-server 192.168.1.11

The output is saved as a compressed ZIP file at:

/root/.nxc/logs/DC_192.168.1.11_<DATE>_<TIME>_bloodhound.zip

Upload this ZIP file directly to BloodHound CE — it accepts both raw JSON and compressed ZIP files.

Method C — Metasploit BloodHound Ingestor

 This module will execute the BloodHound C# Ingestor (aka SharpHound) to gather sessions, local admin, domain trusts and more. With this information BloodHound will easily identify highly complex attack paths that would otherwise be impossible to quickly

use post/windows/gather/bloodhound
set session 1
set srvport 8081
run

Metasploit runs SharpHound on the target, collects AD data, and gives you a ZIP file ready for BloodHound analysis.

Analyzing Results in BloodHound

Searching for Domain Objects

Use the SEARCH tab in the left panel to find specific users, groups, computers, or domains. Type the object name to locate it and click to expand its relationships in the graph view.

When you first run BloodHound against a domain, one of the most revealing views is the Users graph — a visual map of every account and how it connects to groups.

Understanding the Graph Layout

BloodHound uses a node-and-edge model to represent AD relationships. In this graph:

• Green nodes= Individual user accounts
• Yellow nodes= Active Directory groups
• Arrows labeled MemberOf= Group membership relationships

Every user on the left flows rightward through group memberships, eventually connecting to the parent group USERS@IGNITE.LOCAL on the far right.

Users Discovered in IGNITE.LOCAL

BloodHound enumerated 18 accounts in this domain:

Built-in accounts: administrator, krbtgt

Regular users: raj, sanjeet, aarti, komal, raaz, aaru, shivam, rudra, shreya, aarav, jerry, tom

⚠️ RAM, SITA, and KRISHNA carry a special badge icon on their avatars, indicating they possess elevated privileges, active sessions, or interesting ACL rights — making them high-value targets during a pentest.

 

User Ram Enumeration

RAM@IGNITE.LOCAL is not just a regular user — membership in Backup Operators and Remote Management Users makes this account a critical pivot point for domain compromise.

Penetration Testing Significance

 The two highlighted groups make RAM extremely dangerous:

Remote Management Users — Members can connect remotely via WinRM (port 5985) or PowerShell Remoting, meaning an attacker with RAM’s credentials can get a remote shell on the machine without needing RDP

Backup Operators — This is a built-in privileged group that can read any file on the system (bypassing NTFS permissions), backup the SAM and SYSTEM registry hives, and potentially dump credential hashes for further attacks like Pass-the-Hash.

For more details visit: Windows Privilege Escalation: SeBackupPrivilege

User Tom Enumeration (ForceChangePassword Over Jerry)

 Ever looked at a user account and thought “nothing interesting here” only to find it’s a pivotal steppingstone to owning the entire domain? That’s exactly what TOM@IGNITE.LOCAL is.

Tom has the ForceChangePassword right over Jerry. That means Tom can reset Jerry’s Active Directory password — at any time, without knowing Jerry’s current password.

No prompts. No verification. No alerts by default.

For more details visit: Abusing AD-DACL: ForceChangePassword

User Aaru Enumeration (DCSync Rights)

GenericAll on the domain grants AARU both DS-Replication-Get-Changes and DS-Replication-Get-Changes-All — This enables a DCSync attack — impersonating a Domain Controller to pull every password hash in the domain:

For more details visit: Credential Dumping: DCSync Attack

User Sanjeet Enumeration (Sanjeet Can Read a Service Account’s Password In Plaintext)

We’ve covered GenericAll over the domain. We’ve covered ForceChangePassword between users. But this one is different — and honestly, a lot of people miss it entirely.

Sanjeet is a member of GMSA_GROUP, and that group has ReadGMSAPassword rights over the gMSA account MYGMSA$.

For more details visit: Credential Dumping: GMSA

User Shivam Enumeration (DCSync Rights)

We’ve been building quite a collection of misconfigurations in IGNITE.LOCAL. But this one? This is the big one. The one every red teamer dream of finding and every blue teamer has nightmares about.

This screenshot reveals another domain-level critical finding — SHIVAM@IGNITE.LOCAL has both GetChanges and GetChangesAll permissions directly on the IGNITE.LOCAL domain, which together enable a full DCSync attack.

For more details visit: Credential Dumping: DCSync Attack

User Aarav Enumeration (Aarav Can Add Himself to Domain Admins)

We’ve seen GenericAll over the domain. We’ve seen DCSync rights. We’ve seen ForceChangePassword and ReadGMSAPassword. Each one was devastating in its own way. But this one is almost embarrassingly straightforward.

 AARAV@IGNITE.LOCAL can add himself directly to Domain Admins. Right now. In one command.

For more details visit: Abusing AD-DACL: AddSelf

User Krishna Enumeration (Domian Admin)

We’ve spent posts uncovering users who could become Domain Admins through clever ACL abuse. ForceChangePassword, AddSelf, GenericAll, DCSync rights — all elaborate paths to the top.

And then there’s KRISHNA@IGNITE.LOCAL.

Krishna didn’t need any of that. Krishna is already there.

User Aarti Enumeration (AllExtendedRights on a Computer — LAPS Abuse)

So far, every attack path we’ve covered has been about domain-level devastation — DCSync, GenericAll on the domain, adding yourself to Domain Admins. Big, loud, nuclear options.

This one is different. This one is surgical.

AARTI@IGNITE.LOCAL has AllExtendedRights over MSEDGEWIN10.IGNITE.LOCAL — a workstation in the domain. And that means Aarti can read the machine’s LAPS password in plaintext.

For more details visit: Credential Dumping: LAPS

User Shreya Enumeration

We thought Aarav’s AddSelf edge to Domain Admins was bold. Then we found Krishna already sitting inside DA. Now BloodHound shows us SHREYA@IGNITE.LOCAL — and she doesn’t have one path to Domain Admins.

We covered AddSelf with Aarav. But Shreya also has GenericWrite — and that’s a broader, more powerful permission. Let’s compare:

GenericWrite on a group means Shreya can:

• Add any user to Domain Admins — not just herself
• Remove existing members from Domain Admins
• Modify group attributes and properties
• Essentially fully control the group’s composition

For more details visit: Abusing AD-DACL: GenericWrite

User Rudra Enumeration (Rudra Can Hijack Domain Admins Through Ownership)

 We’ve seen direct membership. We’ve seen AddSelf. We’ve seen GenericWrite. Each one was a progressively more powerful key to the Domain Admins group.

RUDRA@IGNITE.LOCAL takes a completely different approach. Rudra doesn’t add herself to Domain Admins directly. Rudra takes ownership of the group first — and then rewrites the rules from the inside.

This is the most indirect and stealthy DA path we’ve documented in this entire series.

For more details visit: Abusing AD-DACL: WriteOwner

Finding Domain Admins Using BloodHound (Cypher Query Guide)

 The “All Domain Admins” query is often the starting point in any AD attack path analysis. It quickly reveals the most powerful accounts in the environment, allowing attackers to focus their efforts where it matters most.

Identified Domain Admins

From the graph:

• KRISHNA@IGNITE.LOCAL
• ADMINISTRATOR@IGNITE.LOCAL

Both users have a MemberOf relationship with:

• DOMAIN ADMINS@IGNITE.LOCAL

Meaning:

These accounts are direct members of the Domain Admins group, giving them full control over the domain.

DCSync Privileges — The Query That Reveals Everything

 The BloodHound query “Principals with DCSync privileges” is one of the most important checks during an AD assessment. It highlights users who can silently take over the domain by abusing replication rights.

Understanding the BloodHound Output

From the screenshot:

• Query Used: Principals with DCSync privileges
• Highlighted User: AARU@IGNITE.LOCAL
• Target:LOCAL (Domain Object)

 Relationships Observed:

• GenericAll
• AllExtendedRights These permissions are assigned over the domain object, which is extremely sensitive.

AS-REP Roasting

 The BloodHound query “AS-REP Roastable Users” quickly highlights weak points in Kerberos authentication. Accounts like KOMAL@IGNITE.LOCAL should be immediately secured to prevent attackers from extracting credentials.

Understanding the BloodHound Query

From the screenshot:

• Query Used: AS-REP Roastable Users (DontReqPreAuth)
• Identified User: KOMAL@IGNITE.LOCAL

This means:

The user KOMAL has Kerberos pre-authentication disabled, making the account vulnerable.

For more details visit: AS-REP Roasting

The Database Management feature in BloodHound is essential for maintaining a clean and reliable analysis environment. Whether you’re practicing in a lab or performing a real assessment, knowing when and how to reset your data can save time and avoid mistakes.

Treat it like a “reset button” — powerful, but to be used carefully.

Per-user Detail Table

Edge Type Reference Table

Risk Priority Matrix