AD attack-graph

What it is

A per-agent Active Directory attack-graph view, populated automatically by the ad_recon technique inside an assessment. Renders the principals enumerated from LDAP (users, groups, computers, OUs, GPOs, the domain itself) plus the relationships between them: group memberships, admin sessions, and ACL edges that enable escalation.

Same vocabulary as BloodHound (MemberOf, AdminTo, GenericAll, WriteDACL, GenericWrite, AllExtendedRights, ForceChangePassword, AddMember, HasSession, CanRDP) so the graph reads identically to what an internal pentester already expects from open-source tooling.

What it produces

Per agent:

• A list of principals with kind (user / group / computer / OU / domain / GPO), SAM name, distinguished name, raw LDAP attributes, and a last_seen timestamp.
• A list of edges between principals, each carrying the BloodHound edge-kind, the source technique that observed it, and last_seen.
• A per-kind rollup in the sidebar: N users, N groups, N computers, N OUs, N edges by kind.

Storage is durable: principals and edges persist, scoped to your workspace and the agent that found them. Re-running ad_recon updates last_seen without duplicating rows; principals that disappear from AD stop refreshing and age out of the live view.

How the graph fills in

The ad_recon technique fires when the operator launches an assessment at Active or above and the agent has at least one LDAP / LDAPS service (389 / 636) in scope. It runs as a normal AI exploit run with the cloud-broker tcp_session primitive. The agent stays tiny and the AI handles the LDAP wire-protocol edge cases.

Each principal it discovers is emitted as a structured finding with kind='ad_principal'. Each relationship is emitted as kind='ad_edge'. A cloud-side extractor turns those findings into graph entries automatically: no batch job, no nightly sync, no manual import.

What to use it for

• Path-to-Domain-Admin: start from a low-privilege principal and trace ACL + group + admin-session edges to a DA-equivalent. The graph is the planning surface; the assessments page is where you fire the actual techniques.
• ADCS escalation paths: combine ad_recon (who can enroll) with adcs_esc_probe (which templates are vulnerable) to surface the ESC1-ESC8 paths the customer’s own administrators have inadvertently configured.
• Stale account hygiene: every principal carries lastLogonTimestamp; the graph makes it cheap to spot accounts that haven’t logged on in two years but still hold dangerous group membership.
• Tier-0 sprawl: count how many principals end up with AdminTo edges into the Domain Controllers OU. If the answer is greater than two, the customer has a finding before any exploit fires.

Why it matters

A flat list of “internal services” misses the structural problem in most Active Directory environments: the vulnerability isn’t a CVE, it’s an over-permissioned ACL or a stale AdminTo edge nobody remembers granting. Tools that scan AD services without modelling the graph between principals can find every host and still miss why one user becomes Domain Admin in three hops.

Building the graph as findings (not as a separate vendor product) means the same audit trail, the same cost meter, and the same agent-routed reachability that the rest of Umbra uses. The graph grows when assessments fire; it doesn’t need its own collector.

Why it’s valuable

• One source, no separate import. No “export from BloodHound, import to Umbra” loop. The technique runs inside an assessment; the rows are in the database when the run finishes.
• Org + agent scoped. Multi-tenant isolation is the same as the rest of the data model. The graph is per-org, per-agent, never cross-customer.
• Edge kinds match the literature. Anyone who has done internal pentesting recognises the edge vocabulary. We didn’t invent a new ontology; we reused the one your hires already know.
• Cap-protected. Each ad_recon run is capped at 2,000 principals; the API returns at most 5,000 principals and 20,000 edges per request. The graph stays useful instead of OOM-ing on a 200k-object forest.

How to use it

1. Install an agent on a network with line-of-sight to the domain controller(s), same install as any other agent. See one-line install.
2. Wait for the first discovery. The agent’s LDAP / LDAPS service must be visible in inventory.
3. Launch an Active or Aggressive assessment on that agent. ad_recon will fire automatically; you can also run it on its own from the per-service click-to-try chips in the LDAP service drawer.
4. Open the AD graph view from the sidebar (or from the agent’s detail page). The view lists principals grouped by kind and surfaces the edge rollup; click a principal to see its outbound and inbound edges.