ADTRUST-002: Análisis de la dirección de la confianza
- Plataforma
- Active Directory
- Categoría
- AD Trust Relationships
- Severidad
- Medium
- Pilar de Zero Trust
- Identity (peso 1)
- Fixtures de referencia
- 3
- Cobertura de ramas
- Observada: los fixtures prueban los veredictos que ejercitan
- Procedencia
- baseline
Qué comprueba
Las relaciones de confianza entrantes permiten que usuarios de dominios externos se autentiquen en su dominio. Cada relación de confianza entrante o bidireccional debe revisarse para asegurar que el dominio de confianza mantiene controles de seguridad adecuados. Un dominio de confianza comprometido puede utilizarse para atacar su entorno
Por qué importa
Trust direction defines who can authenticate into the local domain. An outbound-only trust (trustDirection 2) lets local users reach resources in the partner, but the partner cannot authenticate principals into the local domain; the attack surface added to the local domain is essentially zero. An inbound trust (direction 1) or bidirectional trust (direction 3) reverses this: every principal in the partner is a candidate identity for KDC referrals, NTLM pass-through, and resource access against the local domain. The blast radius of a compromised partner therefore extends into the local domain whenever the trust is inbound or bidirectional. The risk is not theoretical: bidirectional trusts have been the lateral-movement vector in multiple publicly documented intrusions, because attackers who gain Domain Admin in any trusted domain (often a smaller subsidiary, a lab forest, or a partner organization) can use that foothold to forge cross-realm tickets, replay NTLM, or inject SID history against the trusting domain. Where SID filtering (TRUST_ATTRIBUTE_QUARANTINED_DOMAIN on external, TRUST_ATTRIBUTE_TREAT_AS_EXTERNAL on forest) is not enabled, an attacker with KRBTGT or trust-key material on the trusted side can craft tickets containing arbitrary SIDs from the trusting domain, escalating to Enterprise Admin equivalence with no further compromise. Sean Metcalf has documented that the AD forest, not the domain, is the security boundary precisely because of these trust-traversal primitives. Reducing bidirectional trusts to one-way and pruning unjustified inbound trusts directly shrinks this surface.
Ruta de ataque
Step 1: Trust discovery. The attacker, holding any authenticated foothold, enumerates trusts (MITRE T1482) using nltest /domain_trusts /all_trusts, Get-ADTrust -Filter *, or BloodHound's GetDomainTrusts collection. The output reveals which partners have inbound or bidirectional trusts into the target domain, the trustAttributes bitmask, and whether SID filtering is in place. Step 2: Pivot target selection. The attacker identifies the weakest trusted partner. Common picks are subsidiary domains, acquired companies, lab or test forests joined to production, and partner-organization trusts left over from past projects. A trust is exploitable from the trusted side, so any partner where the attacker can reach Domain Admin or KRBTGT becomes a path back into the trusting domain. Step 3: Trusted-domain compromise. Standard attacks on the partner (Kerberoasting, AS-REP roasting, ADCS abuse, GPO abuse, ACL abuse) are used to escalate to KRBTGT or to the inter-realm trust key (stored on each side as TDO secret material). Step 4: Cross-realm ticket forge. With the inter-realm trust key, the attacker uses Mimikatz (kerberos::golden /sids:) or Rubeus to forge a referral TGT for the trusting domain. On bidirectional or non-SID-filtered trusts, the attacker injects extra SIDs into the ExtraSids field of the PAC (MITRE T1134.005, SID-History Injection), including the Enterprise Admins SID (S-1-5-21-<root>-519) of the trusting forest. Step 5: Authentication into trusting domain. The forged ticket is presented to a domain controller in the trusting domain. Because the trust is inbound or bidirectional, the local KDC accepts the cross-realm referral. Because SID filtering is absent, the injected SIDs are honored, granting the attacker Enterprise Admin equivalence in the trusting forest. Step 6: Persistence. The attacker may also use Trust Modification (MITRE T1484.002) to add new trusts, weaken trustAttributes, or convert an outbound trust to bidirectional to preserve access. Trust modifications appear as edits to the trustedDomain object and are visible in Event ID 4716 (Trusted domain information was modified).
Cómo lo evalúa Guerrilla
Guerrilla retrieves the list of domains in the forest via Get-ADForest, then for each domain binds to CN=System,<domain DN> over LDAP and runs (objectClass=trustedDomain). For each returned object the check pulls trustDirection, trustType, trustAttributes, trustPartner, securityIdentifier, flatName, whenCreated, and whenChanged. trustDirection is decoded as 1 inbound, 2 outbound, 3 bidirectional, 0 disabled. trustAttributes is decoded bitwise to surface non-transitive trusts, forest-transitive trusts, SID-filter state (QUARANTINED_DOMAIN for external trusts, TREAT_AS_EXTERNAL for forest trusts where appropriate), selective authentication (CROSS_ORGANIZATION), RC4-only trust keys (USES_RC4_ENCRYPTION, which is a separate hardening miss), and PIM trusts. The check also reads msDS-TrustForestTrustInfo where present to enumerate name-suffix routing on forest trusts. Every trust with direction 1 or 3 is reported as an inbound authentication path. The finding payload includes the partner DNS name, trust type, age in days, last-modified timestamp, SID-filter state, selective-authentication state, and a derived classification of whether the trust is intra-forest (no security boundary), external one-way outbound (low risk), external inbound (medium), bidirectional external (high) and so on. Operators reviewing the finding can match each trust against documented business justification and either remove, convert to one-way, or harden with SID filtering and selective authentication.
Valor recomendado
Todas las direcciones de confianza justificadas y documentadas. Las relaciones de confianza bidireccionales convertidas en unidireccionales siempre que sea posible para reducir la superficie de ataque
Remediación
Revise la dirección de cada relación de confianza con Get-ADTrust -Filter *. En las relaciones de confianza bidireccionales, evalúe si ambas direcciones son necesarias. Conviértalas en relaciones de confianza unidireccionales cuando la necesidad de negocio solo requiera una dirección. Documente la justificación de todas las rutas de confianza entrantes
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.2
- MITRE ATT&CK
- T1482, T1078.002