ADTRUST-003: Trust Transitivity Analysis
- Plataforma
- Active Directory
- Categoría
- AD Trust Relationships
- Severidad
- Medium
- Pilar de Zero Trust
- Identity (peso 3)
- Fixtures de referencia
- 3
- Cobertura de ramas
- Observada: los fixtures prueban los veredictos que ejercitan
- Procedencia
- baseline
Qué comprueba
The check binds to the System container of every domain in the forest (CN=System,DC=<domain>) and enumerates objects with objectClass=trustedDomain. For each TDO it reads trustPartner (the DNS name of the partner), trustDirection (1 inbound, 2 outbound, 3 bidirectional), trustType (1 downlevel NT, 2 uplevel AD, 3 MIT Kerberos, 4 DCE), and trustAttributes (the bit field that encodes transitivity, SID filtering state, forest-trust flag, and selective-authentication flag). The transitivity decision is derived from the trustAttributes bits and the trust type per MS-ADTS section 6.1.6.7.9: a trust is transitive when TRUST_ATTRIBUTE_NON_TRANSITIVE (0x1) is not set and the type is uplevel AD, or when TRUST_ATTRIBUTE_FOREST_TRANSITIVE (0x8) is set. The check then walks the transitive closure: for every transitive partner it queries that partner (when reachable) for its own trustedDomain objects and continues until no new domains are discovered. The output is a list of every domain that can authenticate into the audited forest through any path, annotated with the trust chain (A -> B -> C), the bottleneck hop (which trust would have to be removed to sever the reachability), the SID filtering state of each hop (TRUST_ATTRIBUTE_QUARANTINED_DOMAIN 0x4 and TRUST_ATTRIBUTE_TREAT_AS_EXTERNAL 0x40), and whether selective authentication is enabled on the inbound side.
Por qué importa
Transitive trust is the mechanism that lets a Domain Admin in a grandchild domain authenticate to a resource in the forest root without an explicit trust between the two. Every additional transitive hop expands the set of identities that the trusting domain implicitly accepts. A forest trust to a partner organization does not stop at the partner forest root: every child domain of every tree in the partner forest is reachable. If the partner forest has 12 child domains, the audited forest now trusts authentication material from 13 separate KDCs, each with its own krbtgt key, each operated by potentially different administrators. A compromise of any one of those KDCs (a Golden Ticket in any partner child domain) becomes a path into the audited forest unless SID filtering is enforced on the trust. The blast radius problem is compounded by SID History: a privileged SID from a remote partner domain that is not filtered out at the trust boundary will be honored in the access token presented to a resource in the audited forest, granting cross-forest privilege escalation. Sean Metcalf documented in 2015 that Mimikatz Golden Tickets carrying parent-domain Enterprise Admin SIDs in the SID History field will compromise the entire forest when SID filtering is not enforced. The same principle extends to interforest transitive trusts. External trusts (non-transitive by default) cap this exposure at the single partner domain. Forest trusts (transitive by default) do not.
Ruta de ataque
Step 1: Trust enumeration. From any authenticated foothold the attacker runs nltest /trusted_domains or Get-ADTrust -Filter * or BloodHound collection (SharpHound -c Trusts). Output lists every direct trust. Tools like PowerView (Get-DomainTrustMapping) and BloodHound recursively follow trusts to build the transitive reachability graph. Step 2: Identify the weakest partner. The attacker scores each reachable domain by exposure: domain functional level, patching cadence (KB5008380, KB5014754, KB5037754), presence of unconstrained delegation, ADCS misconfigurations, and the SID filtering state observed on the inbound trust from the audited forest. A partner child domain at 2012 R2 functional level with no SID filtering is the preferred pivot. Step 3: Compromise the weakest domain. The attacker pivots to the weakest partner using whatever primitive is available (Kerberoasting, ADCS ESC1/ESC8, unconstrained delegation, password spray). They obtain DA or krbtgt of that partner domain. Step 4: Forge a cross-trust Golden Ticket. Using Mimikatz (kerberos::golden /sid:<partner-domain-SID> /sids:<audited-forest-Enterprise-Admins-SID> /krbtgt:<partner-krbtgt-hash> /domain:<partner-domain> /user:Administrator) or Rubeus (asktgs /service:krbtgt/<audited-domain> /ticket:<inter-realm-ticket>), the attacker forges an inter-realm TGT that asserts membership in the audited forest Enterprise Admins via SID History. Step 5: Cross the transitive boundary. The forged ticket is presented to a DC in the audited forest. If SID filtering (TRUST_ATTRIBUTE_QUARANTINED_DOMAIN or TRUST_ATTRIBUTE_TREAT_AS_EXTERNAL) is not enforced on the inbound trust, the foreign SIDs survive and the access token in the audited forest carries Enterprise Admin rights. Step 6: Persistence. The attacker creates accounts in the audited forest, dumps the audited forest krbtgt, and the cross-forest compromise is complete. The transitive nature of the original trust means the audited forest never directly trusted the compromised partner; it trusted a chain that ended at that partner. ADTRUST-003 surfaces this chain before it is exploited.
Cómo lo evalúa Guerrilla
Guerrilla queries each domain naming context in the forest with the LDAP filter (objectClass=trustedDomain) under CN=System and pulls trustPartner, trustDirection, trustType, trustAttributes, securityIdentifier, msDS-TrustForestTrustInfo, and whenCreated. The trustAttributes bit field is decoded against the constants defined in MS-ADTS 6.1.6.7.9: bit 0x1 (non-transitive), bit 0x4 (quarantined / SID filtering enforced for external trust), bit 0x8 (forest trust, transitive), bit 0x10 (cross-organization, selective authentication enabled), bit 0x20 (within forest), bit 0x40 (treat as external, SID filtering applied on a forest trust), bit 0x200 (PIM trust), bit 0x400 (TGT delegation enabled). Each TDO is classified as transitive or non-transitive using the combined rule. For transitive partners the check then attempts an LDAP bind to that partner (using current credentials or a supplied delegated read-only account) and recursively enumerates its trustedDomain objects, building the transitive closure as a directed graph rooted at the audited forest. The output records every reachable domain, the chain of trusts that reaches it, and a per-hop summary of SID filtering and selective authentication state. The check correlates with msDS-TrustForestTrustInfo on forest trusts to enumerate the included Top-Level Names (TLN) and any TLN exclusions or claimed domain SIDs, since a permissive TLN list can re-introduce reachability that a name-suffix exclusion was intended to remove.
Valor recomendado
All transitive trusts documented with full transitivity path analysis. External trusts preferred over forest trusts when transitivity is not required
Remediación
Map all transitive trust paths to identify indirect authentication routes. For forest trusts, understand that all child domains are transitively trusted. Consider using external (non-transitive) trusts when only specific domain access is needed
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 |
| known-bad | FAIL |
| throttled | Not Assessed |
Mapeos a marcos de referencia
- NIST SP 800-53
- AC-20, AC-4
- CIS AD Benchmark
- 3.1.3
- MITRE ATT&CK
- T1482, T1078.002