Using BloodHound to map privilege escalation

Privilege escalation in Active Directory (AD) rarely happens as a single “big misconfiguration.” It’s usually a chain: a little too much delegated access here, a leftover admin right there, an ACL that nobody remembers, and suddenly an attacker (or a red team) has a clean path to Domain Admin. BloodHound exists to make those chains visible.

This article shows how to use BloodHound as a defensive mapping tool: to discover escalation paths, prioritize what to fix, and validate remediation. Use it only in environments where you are explicitly authorized to assess.

Why BloodHound works: AD as a graph, not a checklist

Most AD reviews start from the outside in: “Who is Domain Admin?” “Are passwords strong?” “Do we have MFA?” Those matter, but they miss the real problem: relationships. AD security is not just identities; it’s the edges between them—group membership, local admin rights, delegation, ACLs, and trust relationships.

BloodHound models AD as a graph:

• Nodes: users, groups, computers, OUs, GPOs, domains, sessions, etc.
• Edges: “AdminTo”, “MemberOf”, “GenericAll”, “WriteDacl”, “HasSession”, delegation rights, and more.

If you want the foundational “why this happens” story before you start fixing, read Excess Permissions: Lessons from Legacy Setups and come back—because BloodHound will often show you that privilege escalation is really permission sprawl with a map.

What BloodHound is (and what it is not)

• BloodHound is an analyzer: it helps you find attack paths and risky relationships.
• BloodHound is not a “scanner that fixes things”: remediation happens in AD (ACLs, groups, GPOs, delegation changes).
• BloodHound is not magic: results depend on what you collect (sessions, ACLs, local admins, trusts, etc.).

Core mental model: break the path, not the headline

When BloodHound says “Shortest path to Domain Admin,” don’t think: “Oh no, we’re doomed.” Think: “Which edges can we remove or constrain so the path doesn’t exist?”

Your job is to:

1. Identify repeatable escalation patterns (the same edge types show up across many paths).
2. Prioritize fixes that remove many paths at once (high leverage).
3. Validate by re-collecting and ensuring the paths disappear.

Before you collect data: scope, safety, and evidence

BloodHound typically uses a collector (commonly SharpHound) to gather directory and environment data. Even when used defensively, collection can create noise, load domain controllers, and raise alerts.

Scoping checklist

• Authorization: written approval, assessment window, and explicit scope boundaries.
• Targets: which domains, OUs, or forests are in scope (and which are not).
• Collection depth: directory-only vs. sessions/local admins/ACLs (deeper collection = more insight + more noise).
• Data handling: where the output will be stored, who can access it, how long it is retained.

If your organization uses Microsoft Defender for Identity (MDI), align with audit and log collection expectations first: Event collection with Microsoft Defender for Identity. That way, when signals appear during an authorized assessment, the SOC has context.

Collecting the right data: what to gather and why it matters

BloodHound findings are only as good as the dataset. In practice, you’ll choose between:

1) Directory relationships (low noise, high value)

• Users, groups, computers, OUs, GPO links
• Group membership chains (nested groups)
• ACL-based control paths (who can modify whom)
• Delegation relationships (where identities can act on behalf of others)

This is typically your “start here” dataset. It’s often enough to expose dangerous delegation and ACL misconfigurations.

2) Sessions and local admin rights (higher noise, reveals lateral movement)

• Where privileged users are logged in (sessions)
• Which users/groups are local admins on which computers

This is where the graph becomes a real-world attack path: “If I compromise this workstation, I can steal creds for that admin, which lets me admin-to this server, where a Domain Admin session exists…”

3) Trusts and cross-boundary paths

• Domain trusts, forest trusts, and how they extend reach
• Cross-domain group nesting and delegated permissions

These paths are often forgotten during mergers, migrations, and “temporary” access expansions.

Analysis workflow: how defenders should use BloodHound

A practical, repeatable workflow looks like this:

1. Mark “crown jewels” as High Value (Tier 0 groups, domain controllers, critical servers, identity systems).
2. Mark “assumed compromised” starting points (typical endpoints, standard users, service accounts, vendor accounts).
3. Run pathing queries (shortest paths, all paths, or paths constrained by edge types).
4. Cluster by edge type to find the real root causes (the same misconfig repeated broadly).
5. Turn results into fixable tickets (edge removal or constraint + ownership + validation plan).

What “good” looks like

• High value targets have few inbound control edges.
• Privileged users do not maintain active sessions on low-trust endpoints.
• Delegation is constrained and intentional; broad rights are rare and documented.
• Service accounts are tightly scoped, monitored, and not interactive.

Common escalation edges BloodHound highlights (and what to fix)

Below are high-signal patterns BloodHound frequently surfaces, plus remediation principles that remove paths at scale.

1) Overpowered ACLs (GenericAll, GenericWrite, WriteDacl, WriteOwner)

These often mean “this principal can effectively take control of that object,” which can become: group membership control, password reset control, or delegated privilege control.

• Fix: remove broad delegated rights; replace with role-based delegation to narrowly scoped groups.
• Fix: avoid assigning rights to individual users; use managed groups with lifecycle controls.
• Fix: document and periodically re-certify delegations.

2) Local admin sprawl (AdminTo paths everywhere)

If too many principals are local admins, lateral movement becomes trivial. This is one of the most common “it seemed convenient at the time” mistakes.

• Fix: implement tiering (Tier 0/1/2), reduce local admin memberships, and apply least privilege.
• Fix: use LAPS/credential isolation for local admin management (and treat access to passwords as privileged).
• Fix: align admin workstation strategy (PAWs / privileged endpoints).

3) Privileged sessions on endpoints (HasSession + AdminTo chaining)

BloodHound makes it painfully clear when a Domain Admin logs into a workstation. That single behavior can create dozens of paths.

• Fix: enforce privileged access workstations and restrict logon rights for Tier 0 accounts.
• Fix: monitor and investigate abnormal logons and lockouts as leading indicators.

If you need better operational visibility while tuning this, bookmark Account Lockout Event ID: How to Find Account Lockouts for quick investigation patterns (lockouts often spike during both attacks and remediation changes).

4) Delegation misconfigurations (constrained/unconstrained and “unexpected” delegation)

Delegation is powerful and easy to misapply. BloodHound helps you see how delegation creates acting-as-other-user pathways across systems.

• Fix: eliminate unconstrained delegation where possible; prefer modern, constrained patterns.
• Fix: ensure service accounts used for delegation cannot be used interactively.
• Fix: limit where delegation can be exercised (specific services and hosts).

5) Authentication design weaknesses that amplify paths

BloodHound shows the relationships; authentication protocols determine how easily those relationships can be abused. Understanding Kerberos vs. NTLM isn’t academic—it changes risk and detection strategy.

If your team needs a refresher, link this into your learning path: NTLM authentication and Kerberos Authentication Protocols Explained.

Turning findings into remediation tickets

BloodHound results become actionable when you translate them into:

• Edge to remove: which permission, membership, or admin right creates the relationship?
• Owner: who can approve and implement the change?
• Blast radius: what breaks if you remove it (apps, scripts, legacy workflows)?
• Safer alternative: what least-privilege delegation replaces it?
• Validation: re-collect and confirm the path disappears; monitor for regressions.

A simple prioritization rule

Fix items that remove many paths and affect high-value targets first. Examples:

• Removing a single dangerous ACL that grants control over a Tier 0 group
• Eliminating widespread local admin membership from general-purpose groups
• Preventing Tier 0 accounts from logging into endpoints

Validate and monitor: “make it stay fixed”

BloodHound shines as a continuous validation tool:

1. Run an initial collection and save it as your baseline.
2. Apply remediation in controlled phases.
3. Re-collect and compare: did the risky edges disappear?
4. Schedule periodic re-assessments so permission sprawl doesn’t reintroduce paths.

For ongoing visibility into scripting and administrative activity that frequently correlates with privilege movement, pair your identity graph work with PowerShell monitoring practices: PowerShell auditing: An IT admin’s security guide.

Practical “first run” checklist

Step	Goal	Output
Define scope & authorization	Stay legal, safe, and focused	Signed scope + assessment window
Collect directory + ACL data	Find control relationships	Graph showing misdelegation & risky permissions
Mark High Value targets	Focus on Tier 0 and critical assets	Prioritized pathing results
Run path analysis	Identify repeatable escalation patterns	List of paths + edge types
Convert to tickets	Make it fixable	Edge removal plan + owner + validation
Re-collect & validate	Prove risk reduction	Paths removed, regression monitoring plan

Closing: use BloodHound to build a “no-path” identity posture

BloodHound is most valuable when you stop treating it like a one-off assessment tool and start treating it like a map of how your environment really works. The goal isn’t to eliminate every edge (that’s impossible). The goal is to ensure:

• High-value identities and systems have minimal inbound control relationships.
• Privilege is tiered, time-bound where possible, and operationally separated from endpoints.
• Delegation is intentional, documented, and periodically re-certified.
• When paths appear, you detect them early and remove them systematically.