Enumerating Active Directory attack paths with BloodHound and SharpHound

Active Directory remains one of the most important identity systems in many UK SME environments, which also makes it a high-value target for attackers. When identity is over-permissioned, poorly segmented, or lightly monitored, the issue is rarely a single vulnerable server. More often, it is a chain of relationships that allows an ordinary user, service account, or local administrator to move towards higher privilege.

That is where BloodHound and SharpHound are useful. BloodHound is a graph analysis tool that maps relationships in Active Directory and helps you identify attack paths. SharpHound is the data collector that gathers the directory and session information BloodHound needs to build that graph. Used properly, they help defenders answer a practical question: if one account is compromised, how far could an attacker realistically move?

This is not about exploiting Active Directory. It is about understanding exposure, validating assumptions, and turning identity relationships into remediation work. For many organisations, that makes BloodHound a strong fit for internal security testing, purple-team validation, and hardening reviews. It also complements broader testing approaches such as commissioning security testing at the right time and identity-focused exercises such as credential attack simulation using BloodHound.

What BloodHound and SharpHound are used for

BloodHound models Active Directory as a graph. Users, groups, computers, domains, organisational units, access control entries, and sessions become nodes and edges. Once the data is loaded, the tool can calculate shortest paths between a starting point and a target such as Domain Admins, a privileged service account, or a tier-0 server.

That graph view is valuable because Active Directory risk is often relational rather than purely technical. A workstation may be fully patched and a domain controller may be hardened, yet a chain of delegated rights, nested groups, local admin rights, and active sessions can still create a path to privilege. BloodHound makes those chains visible.

SharpHound is the collection component. It queries the domain and, depending on the collection methods used, gathers information about group membership, local administrator relationships, sessions, ACLs, trusts, and other objects. The output is then ingested into BloodHound for analysis.

For technical teams, the value is not just in finding one risky permission. It is in seeing how multiple low-risk issues combine into a meaningful path. That is especially useful when you are trying to prioritise work against a limited engineering backlog.

When to use this approach in a security assessment

BloodHound is most useful when you want to understand identity attack paths from the perspective of an internal adversary or a compromised endpoint. Typical use cases include:

• Validating whether a standard user can reach privileged assets through group nesting or delegated rights.
• Checking whether local administrator access is too broad across user endpoints or servers.
• Reviewing whether stale sessions on privileged systems create lateral movement opportunities.
• Supporting purple-team exercises that need realistic identity paths rather than generic attack simulation.
• Prioritising Active Directory hardening work after a merger, reorganisation, or rapid growth phase.

It is also useful when your environment has accumulated years of exceptions. Small organisations often inherit legacy group structures, service accounts, and administrative shortcuts that were reasonable at the time but are now difficult to reason about. BloodHound helps convert that complexity into something you can inspect.

As with any security testing, scope matters. If you are combining this with a broader red-team or threat-led exercise, align the identity scope with the agreed objectives and the operational constraints of the business. If you want a wider view of how that fits into a controlled exercise, see threat-led penetration testing explained for SMEs.

Preparing the environment and defining collection boundaries

Before running SharpHound, define what you are trying to learn. A clear scope makes the exercise safer and the results easier to interpret. At minimum, decide which domain or domains are in scope, whether you are including workstations, servers, and domain controllers, and whether privileged accounts should be excluded from certain collection methods.

For UK SME environments, a sensible starting point is usually one domain at a time, with a focus on the production estate and the administrative groups that matter most. If you have multiple forests or trusts, include them only if they are relevant to the assessment objective. Otherwise, the graph can become noisy and the analysis effort grows quickly.

Operational impact is usually low, but it is not zero. Collection generates directory queries, authentication lookups, and host enumeration. In a small environment this is often acceptable, but you should still coordinate with IT operations, especially if the estate includes older domain controllers, fragile line-of-business servers, or remote sites with limited bandwidth.

Good practice is to run the collector from a controlled workstation, use an account with the minimum permissions needed for the chosen collection methods, and schedule collection during a period that avoids peak user activity. If you are testing detection as well as exposure, keep the timing and source host consistent so that your logs are easier to correlate.

SharpHound collection methods and what they capture

SharpHound supports multiple collection methods, and the right choice depends on whether you want completeness, speed, or lower visibility. The most common methods include group membership enumeration, local administrator collection, session collection, ACL collection, trust enumeration, and object property gathering.

In practical terms:

• Group collection helps you understand nested group membership and privilege inheritance.
• Local admin collection shows where users or groups have administrative rights on endpoints and servers.
• Session collection identifies where privileged users are currently logged on.
• ACL collection surfaces delegated rights such as write permissions, reset password rights, or control over group membership.
• Trust collection maps relationships between domains and forests.

There is a trade-off between completeness and detectability. A full collection run gives the richest graph, but it also creates more noise and may take longer. A narrower collection can be enough if you are validating a specific question, such as whether privileged sessions exist on non-administrative systems or whether a particular group has excessive rights.

For most technical practitioners, the best starting point is a staged approach. Begin with the minimum collection needed to answer the immediate question, then expand if the graph suggests additional paths worth investigating. That keeps the exercise focused and reduces unnecessary load on the environment.

Running SharpHound and handling the output

SharpHound is typically run from a Windows host joined to the domain, using a collection mode that matches the assessment objective. The output is usually a set of compressed files that BloodHound can ingest directly. In many environments, the collector is run as a one-off executable, although some teams prefer the PowerShell-based approach for controlled lab work or repeatable internal testing.

From an operational perspective, the important point is not the exact launch method but the consistency of the data. If you are comparing results over time, keep the collection method, account, and scope as stable as possible. Otherwise, changes in the graph may reflect collection differences rather than real changes in risk.

Once the output is generated, import it into BloodHound and verify that the expected domains, users, groups, computers, and sessions are present. If the graph looks sparse, check whether the collector account had sufficient visibility, whether the correct collection methods were enabled, and whether any network restrictions blocked queries to remote hosts.

Repeatability matters. A one-off run can be useful, but a repeatable collection pattern is better for tracking remediation. Many teams find it helpful to keep a simple runbook that records the date, scope, collection methods, source host, and any known limitations. That makes it easier to compare before-and-after results after hardening changes.

Interpreting attack paths in BloodHound

BloodHound is most useful when you move beyond the default shortest path view and ask what the path actually means. A shortest path is not always the most realistic path, and it is not always the most important one. You need to understand the relationship types involved.

For example, a path may involve nested group membership that eventually grants local admin rights on a server. Another path may rely on an ACL that allows a user to add themselves to a privileged group or reset a password. A third may depend on a privileged session being present on a workstation that is otherwise accessible to a lower-privileged account.

When reviewing the graph, pay particular attention to:

• Domain Admins and other tier-0 groups.
• Privileged service accounts.
• Servers hosting identity, backup, virtualisation, or management tooling.
• Accounts with delegation or ACL-based control over privileged groups.
• Paths that cross from user workstations into administrative systems.

The key question is whether the path is operationally plausible. A graph can show a theoretical route that depends on rare conditions, but remediation should focus first on paths that are both high impact and likely to be reachable from a realistic starting point.

If you are already using MITRE ATT&CK in your detection engineering work, BloodHound findings can be mapped to identity-centric techniques and used to prioritise coverage. That is particularly useful when you want to connect architecture findings to monitoring outcomes, rather than treating them as separate exercises.

Common misconfigurations BloodHound helps surface

BloodHound often reveals the same classes of issue across different organisations, even when the environments look very different on the surface.

One common pattern is excessive group membership. Users are placed into broad administrative groups for convenience, and those groups are then nested into other groups. Over time, nobody can easily explain why the access exists, but the graph still shows that it does.

Another frequent issue is delegated rights that are broader than intended. Examples include rights to modify group membership, reset passwords, or write to sensitive attributes. These are often introduced during service onboarding or support arrangements and then left in place.

Local administrator exposure is also common. If the same support group is local admin on many endpoints, compromise of one workstation can become a stepping stone to others. Session data can make this worse if privileged users log on to lower-trust systems.

Access control list issues are particularly important because they are easy to overlook in manual reviews. A single write permission on a group object, computer object, or organisational unit can create an indirect path that is not obvious from group membership alone.

These findings are not just technical curiosities. They often indicate weak privilege hygiene, poor separation of duties, or a lack of lifecycle management for access. That is why they should be treated as architecture and governance issues as well as security issues.

How to prioritise findings for remediation

Not every path deserves the same level of attention. A useful way to prioritise is to score each finding by blast radius, exploitability, and remediation effort.

Blast radius asks how much damage a successful path could cause. A route to Domain Admins or a tier-0 system is usually more important than a path to a single departmental server. Exploitability asks how realistic the path is from a common starting point, such as a standard user or a compromised endpoint. Remediation effort asks how much change is needed to remove the path without creating operational disruption.

In practice, the best remediation candidates are often the ones that are both high impact and relatively easy to fix. Examples include removing unnecessary local admin rights, breaking overly broad group nesting, and tightening ACLs on sensitive groups. More complex changes, such as redesigning delegated administration or reworking legacy service accounts, may need a phased plan.

It is also worth looking for fixes that remove multiple paths at once. For example, reducing local admin sprawl can break several lateral movement chains, while cleaning up a privileged group can eliminate multiple ACL-based routes. That gives you better return on effort than treating each path as an isolated issue.

Where possible, tie the remediation plan to existing control work. If you are already improving endpoint hardening or identity governance, use the BloodHound results to justify the order of work and to show which changes will reduce the most risk. That approach aligns well with broader hardening work such as reducing attack surface using system hardening techniques.

Detection and monitoring considerations

BloodHound and SharpHound are also useful from a defensive monitoring perspective. If you know what collection activity looks like, you can decide whether to alert on it, log it, or simply use it as a validation exercise during a controlled test.

Useful telemetry includes directory query activity, unusual authentication patterns from the collector host, remote enumeration against many endpoints in a short period, and process execution on the collection machine. In Windows environments, this may involve domain controller logs, endpoint telemetry, and network visibility from your SIEM or XDR platform.

From a detection engineering standpoint, the goal is not to block every enumeration query. That would be unrealistic and may interfere with legitimate administration. Instead, look for patterns that are unusual for your environment, such as a non-admin workstation querying many hosts for sessions or local group membership, or an account that rarely performs directory enumeration suddenly touching a large number of systems.

Mapping these behaviours to MITRE ATT&CK helps structure the work. Session enumeration, remote service discovery, and directory discovery are all useful anchors for detection content. If you are building or tuning detections, it can help to compare the results with your existing logging baseline and with the kinds of telemetry described in building SIEM detections using Sigma rules.

Operational pitfalls and limitations

BloodHound is powerful, but it is not a complete picture of identity risk. The graph is only as good as the data you collect, and the data is only as good as the assumptions behind the collection.

One limitation is stale or incomplete session data. A privileged session may have ended before collection, or a host may not have been reachable. That can make a path disappear even though the underlying risk still exists. Similarly, if the collector account lacks visibility into a domain or subnet, the graph may understate exposure.

Another pitfall is false confidence. A clean-looking graph does not mean the environment is safe. It may simply mean the collection was narrow, the environment is segmented, or the most obvious paths were removed while less obvious ones remain.

There is also a tendency to focus on the shortest path and ignore context. A path that looks alarming may depend on a rare condition, while a slightly longer path may be much more realistic. Human judgement still matters.

For that reason, BloodHound should complement, not replace, other assessment methods. Pair it with configuration review, endpoint hardening checks, log analysis, and targeted validation of the most important systems. That gives you a more reliable view of identity exposure than graph analysis alone.

A practical workflow for UK SMEs

For a UK SME, a sensible workflow is to treat BloodHound as part of an identity risk review cycle rather than a one-off exercise. Start by defining the domain scope and the business-critical assets that matter most. Then run a controlled SharpHound collection, review the graph, and identify the paths that reach privileged groups, administrative systems, or sensitive service accounts.

Next, convert the findings into remediation tickets. Group them by theme, such as local admin reduction, group nesting cleanup, ACL tightening, or privileged session hygiene. That makes it easier for infrastructure and identity teams to work through the issues without losing sight of the bigger picture.

After remediation, repeat the collection and compare the graph. The aim is to show that specific paths have been removed, not just that a report was produced. This is where BloodHound becomes especially valuable, because it gives you a before-and-after view of identity exposure.

Finally, feed the results into your wider governance and monitoring work. If a path existed because of a long-standing exception, decide whether that exception is still justified. If a path depended on poor admin hygiene, update your standards and review process so the issue does not return. If a path was visible but not detected, adjust your logging and alerting accordingly.

That cycle of collect, analyse, remediate, and re-test is practical for smaller teams and supports a more sustainable security posture. It also fits well with a risk-based approach to identity control, where the focus is on reducing the most meaningful paths first rather than trying to perfect every setting at once.

If you want help turning BloodHound findings into a remediation plan, or you need support aligning identity hardening with a broader ISMS and risk treatment approach, speak to a consultant.

Frequently asked questions

What is the difference between BloodHound and SharpHound?

BloodHound is the analysis platform that visualises Active Directory relationships as a graph, while SharpHound is the data collector that gathers the directory, session, and permission data needed to build that graph.

Which SharpHound collection methods should I use first?

Start with the collection methods that answer your immediate question, usually group membership, local admin, session, and ACL collection. Expand only if the initial graph suggests additional paths worth investigating.