| name | conducting-internal-reconnaissance-with-bloodhound-ce |
| description | Conduct internal Active Directory reconnaissance using BloodHound Community Edition to map attack paths, identify privilege escalation chains, and discover misconfigurations in domain environments. |
| domain | cybersecurity |
| subdomain | red-teaming |
| tags | ["red-team","reconnaissance","bloodhound","active-directory","attack-paths","privilege-escalation","graph-analysis"] |
| version | 1.0 |
| author | mahipal |
| license | Apache-2.0 |
| d3fend_techniques | ["Restore Access","Password Authentication","Biometric Authentication","Strong Password Policy","Restore User Account Access"] |
| nist_csf | ["ID.RA-01","GV.OV-02","DE.AE-07"] |
Conducting Internal Reconnaissance with BloodHound CE
Legal Notice: This skill is for authorized security testing and educational purposes only. Unauthorized use against systems you do not own or have written permission to test is illegal and may violate computer fraud laws.
Overview
BloodHound Community Edition (CE) is a modern, web-based Active Directory reconnaissance platform developed by SpecterOps that uses graph theory to reveal hidden relationships and attack paths within AD environments. Unlike the legacy BloodHound application, BloodHound CE uses a PostgreSQL backend with a dedicated graph database, providing improved performance, a modern web UI, and enhanced API capabilities. Red teams use BloodHound CE to collect AD objects, ACLs, sessions, group memberships, and trust relationships, then visualize attack paths from compromised low-privileged accounts to high-value targets like Domain Admins. The SharpHound collector (v2 for CE) gathers data from Active Directory, while AzureHound collects from Azure AD / Entra ID environments.
When to Use
- When conducting security assessments that involve conducting internal reconnaissance with bloodhound ce
- When following incident response procedures for related security events
- When performing scheduled security testing or auditing activities
- When validating security controls through hands-on testing
Most Often Missed & How to Confirm
- Collecting with
-c All when stealth matters. Full collection touches every host (SMB/session enumeration) and is noisy. Start with -c DCOnly (LDAP-only) for a quiet first pass.
- Skipping Session/loop collection. Without
-c Session --loop, HasSession edges are stale and the best token-theft paths to DA stay invisible.
- Forgetting to mark owned principals. Shortest-path-to-DA queries are meaningless until compromised accounts are flagged Owned in the UI.
- Stopping at built-in queries. ACL chains (GenericAll/WriteDACL/ForceChangePassword), ReadLAPSPassword, and DCSync edges need custom Cypher to surface.
- Not re-collecting per child domain / forest. A single-domain collection misses cross-domain and trust-based paths.
- How to confirm: ingest succeeds (node/edge counts jump in the DB view) and a
shortestPath Cypher from an Owned node to DOMAIN ADMINS@... returns at least one path p. A path is only actionable once you've confirmed you hold the entry node and the first edge's primitive is exploitable. Don't conclude "no path to DA exists" until you've run Session-loop collection and custom ACL/DCSync Cypher — built-in queries alone routinely miss the edge.
