You defend against BloodHound by running the same analysis yourself first. The tool turns ordinary directory data into a graph of attack paths to high-value accounts. Remove the paths it finds: trim excess group rights, keep privileged logons off lower-tier machines, tier your admin accounts, and alert on bulk directory enumeration.
What is BloodHound and why does it work?
BloodHound is a graph-based tool, maintained by SpecterOps, for finding attack paths in identity systems. Its documentation describes collectors that gather directory data, ingestion, and analysis of attack paths so teams can identify and remediate risks. Defenders and attackers use the same idea.
It works because Active Directory is full of small permissions that are individually reasonable. A help desk group can reset passwords for a set of users. One of those users is a local administrator on a server. A domain admin signed in to that server last Tuesday and left a session behind. Each link looks fine alone. Chained together, they give a junior account a route to the top.
MITRE ATT&CK records this behavior under Account Discovery: Domain Account (T1087.002), noting that adversaries list domain accounts and groups to plan later steps, and lists BloodHound among software that collects domain user information, including domain admin accounts.
What do the paths usually look like?
Here is a constructed example. A contractor account is a member of a group that can write to a service account's attributes. The service account is a local administrator on a file server. A domain admin has an open session on that file server from a maintenance task. Three edges, one path, and nothing in a normal permission review flagged it because nobody reviewed the graph.
The pattern is typically some mix of nested group membership, delegated rights on objects, local admin rights, and stale privileged sessions. Fixing one edge often kills many paths at once.
Which controls cut the most paths?
Microsoft's guidance on securing Active Directory centers on limiting where and how privileged accounts are used. The common design is tiering: domain-level administrators sign in only to domain controllers and dedicated admin workstations, never to ordinary servers or desktops. That alone removes the stale-session link from the example.
Next, shrink membership of privileged groups and review delegated rights on organizational units. Delegation granted years ago for a project is a frequent source of surprising edges.
Third, treat service accounts as privileged. Give each a narrow purpose, a long random secret, and no interactive logon. Where your environment supports it, use managed service accounts.
How do you detect the collection itself?
Collection generates unusual directory queries: many LDAP lookups across users, groups and computers, and many session and local-group queries to hosts, from one machine in a short time. Baseline your normal volume. An account that suddenly asks every host who is logged in deserves a look, even if the credentials are valid.
Detection is imperfect, because the data is legitimately readable by authenticated users. Prevention by removing the paths is the stronger control.
How to check or apply this
- Run BloodHound against your own directory, with approval, using the vendor's collectors and documentation. Treat the output as sensitive.
- List shortest paths from ordinary users to the domain admins group and other high-value targets.
- Remove the edge that appears in the most paths first.
- Enforce tiering: privileged accounts log on only to their tier, enforced by policy and not by habit.
- Audit service accounts and delegation on a schedule.
- Alert on bulk LDAP and session enumeration from non-admin hosts.
- Re-run the analysis monthly and after large changes. Paths come back.
Where does Safeguard fit?
BloodHound is an identity tool, and Safeguard is not one. Where Safeguard helps is on the application side of the same story: scanning code and repositories for hard-coded service account credentials, which are a common way these paths begin.
Quick check
Is BloodHound illegal to run?
Running it against a directory you are authorized to assess is a normal defensive and testing practice. Running it against systems without permission is not. Get written approval first.
Can you hide the data from BloodHound?
Not fully. Authenticated users can read much of the directory by design, so the practical defense is removing dangerous relationships rather than hiding them.
Sources
- BloodHound documentation, SpecterOps
- MITRE ATT&CK T1087.002, Account Discovery: Domain Account
- Microsoft, Best practices for securing Active Directory
Last reviewed: 18 October 2026.