Collect focused BloodHound data and validate an attack path

Needs: Compatible collector/deployment, explicit scope, directory rights and separate permission/connectivity for host/session collection

Low-noise directory baseline that avoids contacting every workstation

# Low-noise directory baseline that avoids contacting every workstation
.\SharpHound.exe --CollectionMethods DCOnly --OutputDirectory .\bh --ZipFileName domain-dconly.zip

Add host facts only when they can answer the next question

# Add host facts only when they can answer the next question
.\SharpHound.exe --CollectionMethods LocalGroup --ComputerFile .\candidate-hosts.txt --OutputDirectory .\bh --ZipFileName candidate-localgroups.zip
.\SharpHound.exe --CollectionMethods Session --ComputerFile .\candidate-hosts.txt --Loop --LoopDuration 00:10:00 --OutputDirectory .\bh --ZipFileName candidate-sessions.zip

# Collector variants and compatibility
# Inspect the actual collector before using copied syntax.
.\SharpHound.exe --help

Collector variants and compatibility

# Collector variants and compatibility
# Community Linux collector; flags and output compatibility vary by release.
bloodhound-python --help
bloodhound-python -u USER -p 'PASSWORD' -d DOMAIN -ns DC_IP -dc DC_HOST -c All --zip

Collector variants and compatibility

# Collector variants and compatibility
# Legacy/course PowerShell collector; use only with a compatible legacy deployment.
Import-Module .\SharpHound.ps1
Invoke-BloodHound -CollectionMethod All -OutputDirectory .\bh -ZipFileName legacy.zip

Analyze in this order

Mark only identities/hosts actually controlled. A low-privilege session on a host does not make the host itself fully owned.

Inspect the controlled principal's direct and nested group memberships and outbound object-control edges.

Inspect reachable computers where it has local admin, RDP, WinRM/DCOM or other applicable rights.

Inspect high-value goals and shortest paths only as hypothesis generation.

Classify each selected edge:

directory/static-ish: group, ACL, GPO, OU, trust;

host-derived: local group or user right;

volatile: session;

route-dependent: the required host/service must be reachable now.

Reproduce the minimum important relationship manually before handing it to Block 11 or 12.

# Analyze in this order
ID | CONTROLLED PRINCIPAL | RELATIONSHIP | TARGET | SOURCE EVIDENCE
   | EFFECTIVE? | ROUTE/SERVICE | VOLATILITY | EXPECTED TRANSITION
   | MINIMUM VALIDATION | STATUS | NEXT BLOCK

confidence that the relationship is effective;

deterministic value of the resulting identity/access;

route and service availability;

stability versus volatile session timing;

reversibility and impact;

number of unsupported assumptions.

Verify → Validate every useful edge against current directory/host evidence and identify the transition each one enables.

If it fails → Collector/version incompatibility and partial data are tool/visibility failures. They do not prove the environment lacks a path. More detail ↓

If → then

An ACL/graph edge names GenericAll, GenericWrite, WriteDacl, WriteOwner or an extended/property right → Validate effective directory-object control
Needs: Effective trustee membership, target object/type, inheritance/deny behavior and the exact permitted operation
Group-to-host access edges or a privileged user's possible session → Validate host access and volatile session candidates
Needs: Reachable destination service and its actual authorization; session evidence must be current and collection rights sufficient
Several hosts, identities, routes or competing hypotheses need coordination → Maintain state and select the next evidence-producing test
Needs: Explicit scope/objective and a record of observations, unknowns and available capabilities

No useful finding → another task in this topic. Failed check → resolve the failure before ruling out the path.

Explanation & examples

Collect focused BloodHound data and validate an attack path

USE WHEN: Directory relationships are too broad for manual comparison or a candidate chain needs ranking
STARTING ACCESS: A known domain identity or a directory endpoint that permits the selected anonymous query
RESULT: A ranked chain of independently testable relationships

Recognize the clue

Inspect focused collected relationships and the collector's scope/freshness before following a displayed path.

In BloodHound: locate the controlled principal; inspect the exact edge, source object, destination and collection age.
Resolve its underlying group/ACL/service evidence with the corresponding manual method.

SYNTHETIC EXAMPLE OUTPUT

Graph path: CONTROLLED_GROUP -> WriteDacl -> TARGET_USER
Collection scope: directory only
Host/session data: not collected

Means: The directory edge supplies a candidate intermediate right; missing host/session evidence cannot be invented from the graph.

Confirm: Collect with a version-compatible SharpHound/BloodHound collector, then validate the selected edge. Resolve group nesting and effective ACEs for object control; test destination rights and session freshness for host/session edges.

After validation: Every relevant edge is current and enabled: rank the connected path against alternatives.
Ruled out in this context: One edge is stale or ineffective: reject that chain in its current form.
Still inconclusive: A missing edge in partial collection leaves capability unknown, not absent.

Troubleshooting: Collector/version incompatibility and partial data are tool/visibility failures. They do not prove the environment lacks a path.

Additional prerequisite checks

SharpHound.exe --help

Current SharpHound CE

Low-noise directory baseline that avoids contacting every workstation:

Add host facts only when they can answer the next question:

SharpHound with no collection flag uses its broader default, including directory data plus local-group/session attempts. All performs every supported method; it is not the first response to an unanswered narrow question. Import the output ZIP into a compatible BloodHound CE deployment and verify node/edge counts and ingestion errors.

Collector variants and compatibility

Use the collector version intended for the BloodHound deployment. bloodhound-python, legacy SharpHound PowerShell and current SharpHound CE are alternatives with different schemas/features, not interchangeable command spellings.

Analyze in this order

Mark only identities/hosts actually controlled. A low-privilege session on a host does not make the host itself fully owned.
Inspect the controlled principal's direct and nested group memberships and outbound object-control edges.
Inspect reachable computers where it has local admin, RDP, WinRM/DCOM or other applicable rights.
Inspect high-value goals and shortest paths only as hypothesis generation.
Classify each selected edge:
- directory/static-ish: group, ACL, GPO, OU, trust;
- host-derived: local group or user right;
- volatile: session;
- route-dependent: the required host/service must be reachable now.
Reproduce the minimum important relationship manually before handing it to Block 11 or 12.

Rank candidates by:

confidence that the relationship is effective;
deterministic value of the resulting identity/access;
route and service availability;
stability versus volatile session timing;
reversibility and impact;
number of unsupported assumptions.

Prefer a validated readable share/credential clue or direct object right over a multi-edge path built from stale sessions and unreachable hosts.

Why it works

BloodHound models collected relationships, which may be stale or incomplete. Directory-only collection and host/session collection answer different questions and have different contact/rights requirements.

Worked example · hypothetical

Observation: collection finds a short path from a controlled group to a privileged account. Test: validate each effective ACL and destination service edge manually. Illustrative output: one edge is stale. Interpretation: reject that chain and rank another with current evidence.

New identity, privilege, host or route? Re-enumerate → All topic tasks →

Study guide ↗Full procedure ↗Cheatsheet ↗