ADTRUST-011: Trust Hierarchy Visualization
- Plataforma
- Active Directory
- Categoría
- AD Trust Relationships
- Severidad
- Info
- Pilar de Zero Trust
- Identity (peso 1)
- Fixtures de referencia
- 2
- Cobertura de ramas
- Observada: los fixtures prueban los veredictos que ejercitan
- Procedencia
- baseline
Qué comprueba
This check is a documentation and process control: it confirms that a trust topology artifact exists and is current. The technical inputs are the same trustedDomain objects enumerated by ADTRUST-001: - For every domain in (Get-ADForest).Domains, read every object with (objectClass=trustedDomain) under CN=System,<domain DN>. - For each trust, capture: trustPartner, trustDirection (1 Inbound, 2 Outbound, 3 Bidirectional), trustType (1 Downlevel, 2 Uplevel, 3 MIT realm, 4 DCE), trustAttributes bitmask (NON_TRANSITIVE 0x1, FOREST_TRANSITIVE 0x8, WITHIN_FOREST 0x20, TREAT_AS_EXTERNAL 0x40, USES_AES_KEYS 0x100, CROSS_ORGANIZATION_NO_TGT_DELEGATION 0x200, CROSS_ORGANIZATION_ENABLE_TGT_DELEGATION 0x800), and the securityIdentifier of the trusted domain. - For forest trusts, read msDS-TrustForestTrustInfo to capture the namespaces, top-level names, and excluded names that scope the trust. - Build a directed multigraph where each domain is a node and each trustedDomain object is one or two edges (one for each direction encoded by trustDirection). - Compute transitive closure under the FOREST_TRANSITIVE and WITHIN_FOREST attributes, so the graph distinguishes hops that traverse transitive vs non-transitive trusts. The check then validates the documentation side: the path supplied in -TopologyDiagramPath (or a project-standard location) is checked for a file modified within the review window (default 90 days). Missing or stale files trigger the finding.
Por qué importa
A trust inventory answers the question "what trusts exist". A trust hierarchy visualization answers the question "what can a compromised account in domain X reach". Those are not the same question. Three failure modes a flat inventory hides: - Transitive chaining across a forest trust. A forest trust between corp.contoso.com and corp.fabrikam.com is one row. The fact that a user in dev.eng.fabrikam.com (two parent-child hops below the trust root) can authenticate to fileserver.corp.contoso.com requires reasoning across multiple rows. Defenders routinely miss this; attackers using BloodHounds Trusts edge do not. - Trust islands. Acquisitions and mergers leave forests connected through partner forests via chains of external trusts that nobody owns end-to-end. A row-per-trust view never reveals the chain; a graph does. - Stale or orphaned namespaces inside forest trust info. msDS-TrustForestTrustInfo can include namespaces that the partner no longer hosts. A visualization that renders the namespace tree side-by-side with the edge surfaces these as dead branches, which are a known phishing and DNS-takeover vector (Schroeder and Christensen, Not A Security Boundary). During an incident, the trust topology diagram is the single artifact that determines containment scope. If the responder cannot tell within minutes which domains share a Kerberos authentication path with the compromised domain, the response either over-isolates (business disruption) or under-isolates (the attacker pivots before the boundary is enforced). The same diagram is required for tabletop exercises, M&A due diligence, and Tier-0 segmentation reviews. NIST SP 800-53 AC-20 and PL-2 require an accurate authorization boundary; a forest with a flat trust list does not have one.
Ruta de ataque
1. Recon from any authenticated user: nltest /domain_trusts /all_trusts or Get-ADTrust -Filter * lists local trusts. PowerView Get-DomainTrustMapping recurses across reachable trusts to build the same graph the defender should already have. 2. BloodHound collection: SharpHound -CollectionMethod Trusts emits Trusts edges with TrustType (ParentChild, CrossLink, External, Forest), TrustDirection, IsTransitive, and SidFilteringEnabled. The BloodHound UI renders the trust graph natively, including the Shortest Paths from Owned to High Value query across trusts. 3. Path selection: the attacker picks the shortest authentication path from their foothold to a target high-value object (Domain Admin, Tier-0 asset). The graph shows that a single forest trust without SID filtering, plus a parent-child trust, plus a service account with SPNs in the target domain, is a three-hop path the defender never drew. 4. Hop execution: at each edge the attacker requests a Kerberos referral (Rubeus asktgs /service:host/<target>.<other-domain> /enctype:aes256) and is granted a service ticket by the trusting DC because the trust path is honored. 5. SID history injection across the forest trust (if SID filtering is off): mimikatz kerberos::golden /sids:<EA-SID-of-target-forest> or impacket ticketer.py -extra-sid forges a TGT that the trusting DC accepts. 6. Persistence and lateral movement continue along the graph the defender did not draw. The attacker has full visibility of the topology via BloodHound; the defender, without a current diagram, is reasoning from a partial mental model. The asymmetry is the point: the trust graph exists whether or not the defender has rendered it. The only question is who has looked at it first.
Cómo lo evalúa Guerrilla
Guerrilla generates the topology graph as part of invoke-adaudit. The collector calls Get-ADTrust -Filter * -Properties * against every domain returned by (Get-ADForest).Domains, then merges results into a single edge list keyed by (SourceDomain, TrustPartner, Direction). For each edge it records TrustType, ForestTransitive, IntraForest, SIDFilteringQuarantined, SIDFilteringForestAware, UplevelOnly, UsesAESKeys, and the raw trustAttributes value. The edge list is rendered to (a) a DOT file for Graphviz, (b) a Mermaid graph block embedded in the HTML report, and (c) a JSON adjacency list consumable by BloodHound Community Edition via the Trusts ingest endpoint. The check passes when the topology artifact exists at the expected path and the file mtime is within the review window. It fails when no artifact is present, when the artifact is older than the review window, or when the live trust list differs from the trusts represented in the artifact (drift detection via SHA-256 of the sorted edge list).
Valor recomendado
Up-to-date trust topology diagram maintained and reviewed quarterly
Remediación
Generate a trust topology map using automated tools or manually document all trust relationships including direction, type, transitivity, SID filtering status, and selective authentication status. Update the diagram whenever trusts are added, modified, or removed. Include the map in security documentation and review quarterly
Veredictos probados con fixtures
Cada veredicto de esta tabla está probado por un fixture de referencia en la suite de pruebas que valida el módulo. La tabla se deriva de la última ejecución en verde; no puede editarse a mano.
| Escenario | Veredicto esperado |
|---|---|
| clean | PASS |
| throttled | Not Assessed |
Mapeos a marcos de referencia
- NIST SP 800-53
- AC-20, PL-2
- CIS AD Benchmark
- 3.1.5
- MITRE ATT&CK
- T1482