BloodHound Tutorial: Mapping Active Directory Attack Paths

Active Directory is still the backbone of identity management in most enterprise networks I’ve assessed, and it’s also one of the most misunderstood attack surfaces out there. You can harden individual accounts, patch every server, and still leave a wide-open path to Domain Admin sitting in plain sight — because the real risk in AD rarely comes from a single misconfiguration. It comes from the relationships between users, groups, computers, and permissions. That’s exactly the problem BloodHound was built to solve, and in this guide I’ll walk you through how I use it to map out Active Directory attack paths from the ground up.

If you’re new to offensive security or just getting comfortable with AD enumeration, this tutorial will take you from installing BloodHound to reading your first attack path graph, all inside a legal, authorized lab environment.

What Is BloodHound and Why It Matters

BloodHound is an open-source Active Directory (and now Azure AD/Entra ID) reconnaissance tool that uses graph theory to reveal hidden and often unintended relationships within an AD environment. Instead of manually cataloging who’s in which group and who has what permission on which object, BloodHound collects that data automatically and renders it as a graph you can query and visualize.

The core insight behind BloodHound is simple: attackers think in graphs, but defenders think in lists. A defender might check “is this user a Domain Admin?” and move on satisfied when the answer is no. BloodHound asks a different question: “what is the shortest path from any user I control to Domain Admin?” That path might run through nested group memberships, GPO permissions, ACL misconfigurations, or sessions on shared machines — connections that are nearly impossible to spot by hand across a domain with thousands of objects.

This matters for a few concrete reasons:

• Real attackers use tools like this. BloodHound has become a staple in red team and adversary toolkits precisely because it mirrors how privilege escalation actually happens in the real world.
• It exposes what audits miss. Traditional AD audits look at explicit permissions. BloodHound reveals derivative and transitive privilege — the “who can eventually become who” question.
• It speeds up both offense and defense. On the blue team side, the same graphs help identify and remediate excessive privilege paths before an attacker finds them.

Lab Setup: Building an Authorized Environment

Before you touch BloodHound against anything, you need a legal, isolated lab. I never recommend running this against infrastructure you don’t own or don’t have explicit written authorization to test — that applies just as much to home labs connected to shared networks as it does to client engagements.

A minimal BloodHound-ready lab looks like this:

1. A Windows Server domain controller (Server 2019 or 2022 works well) running Active Directory Domain Services.
2. Two or three domain-joined Windows 10/11 workstations to simulate user sessions and lateral movement paths.
3. A Kali Linux attack box on the same isolated virtual network, with no route to production systems.
4. A handful of test users and groups with intentionally messy permissions — nested groups, GPO delegation, and a few ACL misconfigurations to make the graph interesting.

I build these labs in VMware Workstation or a hypervisor with internal-only virtual networking, so there’s zero chance of touching anything outside the lab. If you’re using cloud VMs instead, lock the network security group down to your lab subnet only.

Installing BloodHound

BloodHound has two main components: the collector (SharpHound) that gathers data from the domain, and the BloodHound GUI that ingests and visualizes that data. As of BloodHound Community Edition (CE), the architecture shifted to a containerized web app backed by a Neo4j graph database, which I actually prefer because it removes a lot of the dependency headaches from the legacy Electron app.

Installing BloodHound CE with Docker

On my Kali attack box, I install it like this:

sudo apt update
sudo apt install docker.io docker-compose -y
curl -L https://ghst.ly/getbhce -o docker-compose.yml
sudo docker compose up -d

What this does: the first two lines install Docker and Docker Compose, which BloodHound CE relies on for orchestration. The curl command pulls the official docker-compose file maintained by SpecterOps (the team behind BloodHound). docker compose up -d then pulls and starts all required containers — the API, the web UI, and the Neo4j database — in detached mode.

Once the containers are up, BloodHound CE is reachable at https://localhost:8080 by default, and the initial admin password is printed in the Docker logs on first run:

sudo docker compose logs bloodhound | grep -i password

Purpose: this filters the container logs for the auto-generated admin credentials you’ll need for your first login.

Collecting Data with SharpHound

SharpHound is the ingestor — the piece that actually talks to Active Directory and pulls the relationship data BloodHound needs. It comes in two flavors: a PowerShell version and a compiled C# executable. I generally use the compiled version in labs because it’s faster and has fewer dependency issues.

From a domain-joined machine (with valid domain credentials, which is standard practice in an authorized assessment), I run:

.\SharpHound.exe -c All -d lab.local --outputdirectory C:\Temp\BHData

What each flag does:

• -c All tells SharpHound to run every collection method: sessions, group memberships, ACLs, trusts, GPOs, and more.
• -d lab.local specifies the target domain.
• --outputdirectory sets where the resulting .json files (zipped together) get saved.

For a more surgical collection — useful when you want to avoid generating excessive noise on a monitored network — you can scope it down:

.\SharpHound.exe -c Group,LocalAdmin,Session -d lab.local

Purpose: this limits collection to group memberships, local admin rights, and active sessions, which is often enough to start building meaningful attack paths without touching every collection method.

SharpHound also supports a Python-based ingestor called bloodhound-python, which is handy when you’re operating from a Linux box without a foothold on a Windows host yet:

pip install bloodhound
bloodhound-python -u 'labuser' -p 'LabPass123!' -d lab.local -c All -ns 10.10.10.5

What this does: authenticates as labuser against the domain lab.local, using 10.10.10.5 as the domain’s DNS server (-ns), and collects all available data types remotely over LDAP and SMB.

Ingesting Data into BloodHound

Once you have your .zip of JSON files, log in to the BloodHound CE web interface, go to Administration → File Ingest, and upload the file. The ingestion process parses the JSON and builds the graph inside Neo4j behind the scenes. For large environments, this can take a few minutes — I’ve seen ingestion of a 5,000-object domain take under two minutes on modest lab hardware.

Reading the Graph: Core Concepts

This is where BloodHound earns its reputation. Once your data is loaded, you’re working with nodes and edges:

Nodes

Represent AD objects: Users, Groups, Computers, GPOs, OUs, Domains, and (in CE) Azure/Entra objects if you’ve collected that data too.

Edges

Represent relationships and capabilities, such as:

• MemberOf — group membership
• AdminTo — local administrator rights on a computer
• HasSession — an active logon session
• GenericAll / GenericWrite / WriteDacl — dangerous ACL permissions
• ForceChangePassword — the ability to reset another account’s password without knowing the current one

Pre-Built Queries

BloodHound ships with pre-built Cypher queries under the Analysis tab, and these are usually where I start:

• Find all Domain Admins — establishes your high-value targets.
• Shortest Paths to Domain Admins — the single most useful query in the tool; it shows every route from any node to full domain compromise.
• Find Kerberoastable Users — flags service accounts vulnerable to Kerberoasting.
• Find Computers where Domain Users can RDP — highlights lateral movement opportunities.

Writing Custom Cypher Queries

Once you’re comfortable, the raw power of BloodHound comes from writing your own Cypher queries. For example, to find every path from a specific low-privilege user to Domain Admin:

MATCH p=shortestPath((u:User {name:"JDOE@LAB.LOCAL"})-[*1..]->(g:Group {name:"DOMAIN ADMINS@LAB.LOCAL"}))
RETURN p

What this does: shortestPath tells Neo4j to find the minimum number of hops between the specified user node and the Domain Admins group node, traversing any relationship type ([*1..]). The result is rendered as a visual path graph showing exactly which memberships, sessions, or ACL abuses connect the two.

A Practical Walkthrough: From Foothold to Domain Admin

Here’s a simplified version of a path I regularly reproduce in lab environments to teach the concept:

1. Initial foothold — I compromise a low-privilege user, jdoe, through a phishing simulation or a weak password.
2. Session discovery — SharpHound data shows jdoe has an active session on WKSTN03.
3. Local admin chain — WKSTN03 has a local admin group that includes helpdesk_svc, a service account.
4. ACL abuse — helpdesk_svc has GenericAll rights over the IT_ADMINS group due to a stale delegation from a previous migration project.
5. Group membership escalation — Adding helpdesk_svc to IT_ADMINS grants it rights that ultimately chain into Domain Admins via a GPO-linked OU.

BloodHound visualizes this entire chain as a single connected path, something that would take hours to piece together manually from net group output and ACL dumps.

Common Mistakes and Troubleshooting Tips

• Running SharpHound with insufficient permissions. Many collection methods (like session enumeration) require local admin rights on target machines to get complete results. If your graph looks sparse, check whether your test account has the access it needs for the assessment scope.
• Forgetting to allow time for ingestion. Large JSON files can take a while to parse. Don’t assume a failed-looking ingest is broken — check the ingestion logs before re-uploading.
• Not scoping collection on live engagements. Running -c All against a large production domain can generate a lot of LDAP and SMB traffic, which may trigger detection. In real assessments (with client sign-off) I scope collection methods and throttle timing.
• Confusing “shortest path” with “only path.” BloodHound’s shortest path query shows one route; there are often several. Use the “Find All Paths” analysis for a fuller picture during a thorough review.
• Stale data. AD changes constantly. A graph collected a week ago may no longer reflect current group memberships — always re-collect before drawing final conclusions in an engagement.

Security Risks and Defensive Recommendations

If you’re on the defensive side, BloodHound isn’t just an attacker’s tool — it’s one of the best ways to proactively find your own exposure. A few recommendations I give to blue teams:

• Run BloodHound against your own domain regularly and review the “Shortest Paths to Domain Admins” query as part of routine hygiene.
• Eliminate unnecessary nested group memberships. Many attack paths exist purely because of convenience-driven group nesting from years ago.
• Audit ACLs on sensitive objects (GenericAll, WriteDacl, WriteOwner) especially on Domain Admins, GPOs, and OUs.
• Reduce standing local admin rights across workstations; use just-in-time privilege elevation instead.
• Monitor for SharpHound-like LDAP and SMB enumeration patterns, which can indicate active reconnaissance by an attacker already inside your network.
• Deploy tiered administration models (Microsoft’s Enterprise Access Model) to structurally prevent workstation compromise from cascading into domain compromise.

Collecting Hybrid Azure AD Data

Since so many organizations now run hybrid identity environments, I also collect Azure/Entra ID data alongside on-prem AD whenever it’s in scope, using AzureHound (SharpHound’s Azure-focused counterpart):

azurehound list --tenant <tenant-id> --app <app-id> --secret <client-secret> -o azure_data.json

What this does: authenticates against the specified Azure tenant using an app registration’s credentials, then enumerates users, groups, role assignments, and service principal relationships, outputting them in a format BloodHound CE can ingest alongside on-prem data. This is particularly valuable because hybrid environments frequently have attack paths that cross between on-prem AD and Azure AD — for example, an on-prem account with Azure AD Connect sync privileges effectively controls cloud identity as well, a relationship that’s invisible unless you’re collecting and correlating both data sources together.

Frequently Asked Questions

Is BloodHound legal to use? Yes, when used against systems you own or have explicit written authorization to test. Using it against any domain without permission is illegal in most jurisdictions.

Do I need Domain Admin credentials to run BloodHound? No. Any valid domain user account can collect a meaningful amount of data, though the completeness of certain edges (like local admin and session data) improves with elevated access.

What’s the difference between BloodHound Legacy and BloodHound CE? BloodHound CE is the actively maintained, containerized version with a web-based UI and multi-user support. Legacy BloodHound was an Electron desktop app; SpecterOps has shifted development focus to CE.

Can BloodHound be detected by defenders? Yes. SharpHound’s LDAP and SMB queries can trigger EDR and SIEM alerts, especially with full collection (-c All) against a monitored domain. Many organizations now specifically hunt for SharpHound-style enumeration patterns.

Does BloodHound work with Azure AD / Entra ID? BloodHound CE supports collecting and visualizing Azure/Entra ID relationships alongside on-prem AD data, which is increasingly important as hybrid identity environments become the norm.

How often should I re-run collection during an engagement? For anything beyond a day or two, I re-collect data periodically since AD state changes frequently and stale graphs can lead to inaccurate conclusions.

What’s Kerberoasting and why does it show up in BloodHound? Kerberoasting targets service accounts with Kerberos SPNs set, requesting service tickets that can be cracked offline to recover the account’s password. BloodHound flags kerberoastable accounts because they’re a common and high-value attack path into privileged groups.

Conclusion

BloodHound turns Active Directory security from a guessing game into a data-driven discipline. Instead of manually tracing permissions across thousands of objects, you get a graph that shows exactly how an attacker could move from a single compromised account to full domain control — and just as importantly, exactly where to cut that path off. Whether you’re studying for a certification, building out your first home lab, or preparing for authorized engagements, learning to read and query BloodHound’s attack path graphs is one of the highest-leverage skills you can develop in offensive Active Directory security. Start small, build a messy lab on purpose, and get comfortable reading the graph — that’s where the real learning happens.

For more hands-on reconnaissance methodology that pairs well with BloodHound-driven AD assessments, see my write-up on top reconnaissance tools for security professionals and my extended penetration testing cheatsheet.

References

• SpecterOps, BloodHound Community Edition documentation
• Microsoft Learn, Active Directory security documentation
• MITRE ATT&CK, Discovery and Privilege Escalation tactics (AD-focused techniques)