BloodHound and AD Attack Path Mapping: A Blue Team Defense Guide

BloodHound is one of the most influential tools in the Active Directory (AD) security world, and understanding it is now a core skill for every blue team. It does not exploit anything by itself; it is a graph engine that ingests relationships between users, groups, computers, and permissions, then reveals the shortest attack paths an intruder could walk from a low-privilege foothold to Domain Admin. Defenders study BloodHound for the same reason a locksmith studies lockpicks: to see the building the way an adversary sees it and to close the routes before anyone else finds them. This article takes a strictly defensive, understand-to-defend posture. We explain what attack path mapping is, how the graph is built, which telemetry and Event IDs expose collection and abuse, and how to harden your directory so that the dangerous edges simply disappear. There are no operational attack instructions here — only the detection engineering and hardening a defender needs.

What BloodHound Is and Why Defenders Study It

At its heart, BloodHound is a data-visualization and analytics platform built on a graph database. Nodes represent AD objects — users, groups, computers, organizational units, group policy objects, domains — and edges represent relationships such as MemberOf, AdminTo, HasSession, GenericAll, WriteDacl, and CanRDP. A collector (historically SharpHound, and in modern deployments the community and enterprise editions) reads this information from the directory using ordinary, authenticated LDAP and RPC queries, then feeds it into the graph. Once the data is loaded, an analyst can ask a single question that would take days by hand: what is the shortest path from this ordinary account to a highly privileged one?

For defenders the value is enormous. Modern AD environments accumulate permissions like sediment: a helpdesk group is granted rights on a server for a one-off task, a service account is over-provisioned to make an installer work, an old admin is nested three groups deep. Individually each grant looks harmless. Collectively they form a web that no human can hold in their head. BloodHound turns that invisible web into a picture, and that picture is exactly what a Purple or Blue team uses to prioritize remediation. Studying the tool is not about learning to attack — it is about learning to see the same graph the attacker sees and to break it first.

How Attack Path Mapping Works at a High Level

Attack path mapping treats the directory as a directed graph and applies pathfinding. The core insight is that privilege escalation in AD is rarely a single vulnerability; it is a chain of legitimate permissions, each individually authorized. A user might belong to a group, that group might have local admin on a workstation, an administrator might have an active session on that workstation, and that administrator might in turn have rights over a more sensitive object. None of those steps is a bug — they are all working as configured. The danger is the transitive composition of the chain.

BloodHound encodes each of those relationships as a typed edge and then runs shortest-path queries (classically Dijkstra-style traversals) between a starting node and high-value targets such as the Domain Admins group or the domain object itself. The output is a ranked set of routes. From a defensive standpoint, every edge on a returned path is a control point: remove or downgrade any single edge and the whole path is severed. This is why the tool is so powerful for hardening — it does not just tell you that a risk exists, it tells you the exact permission whose removal eliminates the largest number of paths at once.

The Collection Surface: What Gets Read

To build the graph, a collector queries the directory much like any authenticated domain user could. It enumerates group memberships, access control lists (ACLs/DACLs) on objects, trust relationships, group policy links, and — importantly — session information: which users are currently or recently logged on to which machines. Session data typically comes from remote enumeration of logged-on users and network session APIs. Understanding this surface matters because it tells defenders exactly where the noise will appear in their telemetry: a burst of LDAP queries against the directory, followed by RPC/SMB connections fanning out to many hosts to gather session and local-group data.

The key defensive takeaway is that collection looks like reconnaissance at scale. A single machine suddenly querying LDAP for the entire directory structure and then touching hundreds of other machines' session APIs in a short window is the signature to watch for. Legitimate administrative tools do similar things, so context — the source account, the host, the time of day, and the breadth of the fan-out — is what separates a scan from routine operation.

Common Attack Paths the Graph Reveals

Several categories of dangerous edge appear repeatedly across real environments. ACL abuse edges (GenericAll, GenericWrite, WriteDacl, WriteOwner, AddMember) mean one object can rewrite the security of another — for example, a low-tier group that can add itself to a privileged group. Credential exposure edges (HasSession) mean a privileged account left credentials in memory on a machine that lower-tier users can reach. Delegation edges (unconstrained and constrained Kerberos delegation) let a host impersonate other users. Kerberoastable and AS-REP roastable markers flag service accounts whose tickets can be requested and cracked offline if the password is weak.

Recognizing these classes is the whole point for a defender: each maps to a concrete remediation. ACL edges are fixed by tightening delegated permissions; session edges are fixed by tiered administration so that Tier-0 credentials never land on Tier-1 or Tier-2 hosts; delegation edges are fixed by removing unconstrained delegation and marking sensitive accounts as not delegatable; roastable accounts are fixed with long, random, managed passwords (gMSA) and by not putting service principal names on ordinary user accounts.

Detection: Logs, Event IDs, and EDR Telemetry

Collection generates observable signals. On the directory side, enabling and monitoring Directory Service Access auditing lets you see abnormal LDAP read volume; look for a single source enumerating a very large fraction of objects. Windows Security Event ID 4662 (an operation was performed on an object) is central for spotting bulk directory reads and, notably, DCSync-style replication requests when you filter for the replication control access rights. Event ID 4661 (a handle to an object was requested) and 5136 (a directory object was modified) help catch ACL changes that create new privileged edges.

For session and local-group enumeration, watch Event ID 4624 (logon) and 4672 (special privileges assigned) on member hosts, along with SMB/RPC named-pipe access to srvsvc and wkssvc. A machine that connects to hundreds of hosts' session interfaces in minutes is anomalous. EDR platforms add process lineage — flagging an unusual binary making broad LDAP and SMB calls — and network sensors add the fan-out shape. Deploying honeytoken objects (a decoy privileged-looking account or a fake ACL) is one of the highest-signal, lowest-noise detections available: no legitimate process should ever touch them, so any query against a honeytoken is an immediate high-fidelity alert. Microsoft Defender for Identity and similar identity-threat sensors specialize in exactly this reconnaissance and lateral-movement telemetry.

Correlation is what makes these signals actionable. A single 4662 is meaningless; a single source producing thousands of 4662s across the directory, followed by 4624s spreading to many hosts, followed by a Kerberos service-ticket request spike (Event ID 4769 with weak encryption types), is a coherent story. Building that correlation into your SIEM as a multi-stage rule turns scattered noise into one clear alert.

Mitigation and Hardening

The strategic fix for attack paths is tiered administration. Divide identities and assets into tiers — Tier 0 (domain controllers, the identity plane, and anything that controls it), Tier 1 (servers and applications), and Tier 2 (workstations) — and enforce that credentials of a higher tier never authenticate to a lower tier. This single principle collapses the vast majority of HasSession paths, because a Domain Admin credential never lands on a workstation where a low-privilege user could harvest it. Pair this with Privileged Access Workstations (PAWs) for administrators and separate admin accounts that are used only for their tier.

On the permission side, audit and prune the ACL edges the graph reveals. Remove GenericAll/WriteDacl grants that were added ad hoc; replace broad delegation with narrowly scoped, documented delegations. Eliminate unconstrained delegation entirely where possible and use resource-based constrained delegation instead. Mark high-value accounts as sensitive and cannot be delegated, and add them to the Protected Users group so their credentials are handled more defensively by the OS. Replace standalone service accounts with group Managed Service Accounts (gMSA) so passwords are long, random, and rotated automatically, which removes Kerberoasting risk. Enforce the LAPS solution so local administrator passwords are unique per machine, breaking the pass-the-hash lateral chains that turn one compromised workstation into many.

Finally, use BloodHound-style analysis as a defender: run the graph on your own environment on a schedule, track the number of principals with a path to Tier 0 as a metric, and drive it down release by release. Treat any reduction in paths-to-Domain-Admin as a measurable security win. This flips the tool from an attacker's map into a defender's KPI.

Pitfalls and Common Mistakes

The most common mistake is chasing individual findings instead of high-impact choke points. Because paths overlap, one over-permissioned group often sits on thousands of routes; fixing it is worth more than fixing a hundred leaf issues. A second pitfall is ignoring session-based edges because they feel transient — but a single admin habit of logging into workstations to troubleshoot recreates the same dangerous edge every day. A third is treating service accounts as harmless; an over-privileged service account with a weak, never-rotated password is one of the most reliable escalation routes in any environment.

On the detection side, a frequent error is auditing everything and alerting on nothing, drowning analysts in raw 4662 events. Tune for volume and breadth, not single events, and lean on honeytokens for high-fidelity signal. Another mistake is assuming that because collection uses legitimate protocols it cannot be detected — the shape of the activity (one source, enormous fan-out, short window) is highly detectable even when each individual query is normal.

Defensive Checklist

1. Implement tiered administration and forbid Tier-0 credentials on lower-tier hosts. 2. Deploy PAWs and separate per-tier admin accounts. 3. Enroll high-value accounts in Protected Users and mark them non-delegatable. 4. Remove unconstrained delegation; use RBCD. 5. Replace service accounts with gMSA; remove unnecessary SPNs. 6. Deploy LAPS for unique local admin passwords. 7. Audit and prune ACL edges (GenericAll/WriteDacl/WriteOwner). 8. Enable Directory Service Access auditing; build SIEM correlation for 4662/4661/5136/4769 volume and fan-out. 9. Plant honeytoken accounts and monitor any access. 10. Run graph analysis on your own directory regularly and track paths-to-Tier-0 as a KPI.

Frequently Asked Questions

Is running BloodHound against my own directory safe? Collection is read-heavy and generally low-risk when performed by authorized defenders during a scheduled assessment, but treat the resulting data as sensitive — it is a literal map of how to compromise your domain. Store it encrypted, restrict access, and delete stale datasets. Coordinate with your SOC so the collection itself does not trigger a false incident, and always operate under written authorization within your own environment only.

Can attack paths ever reach zero? Practically, no — some administration is always required and administrators always create sessions. The realistic goal is to minimize the number of principals with any path to Tier 0, to make the remaining paths short and heavily monitored, and to ensure every step on them is instrumented with high-fidelity detection so that walking the path is loud rather than silent.

Conclusion

BloodHound and attack path mapping reframe Active Directory security from a list of isolated misconfigurations into a connected graph of consequences. For defenders that shift is empowering: the same analysis an adversary would use to find the shortest route to Domain Admin is the analysis you can run first to sever those routes. Combine graph-driven hardening — tiered administration, delegation cleanup, gMSA, LAPS, Protected Users, and ACL pruning — with layered detection built on directory auditing, session telemetry, EDR lineage, and honeytokens, and the attack surface that once felt unknowable becomes a measurable, shrinking metric. Understand the graph, and you can defend it.