Abuso de trusts y bosques

Un trust (relación de confianza) permite que usuarios de un dominio se autentiquen en otro. Las organizaciones los crean para compartir recursos entre dominios de un mismo bosque o entre bosques distintos (fusiones, filiales). Para un atacante que ya controla un dominio, los trusts son puentes para expandirse: dependiendo del tipo y la dirección de la confianza, comprometer un dominio puede llevar directamente a comprometer otro —y, dentro de un bosque, el límite de seguridad real es el bosque, no el dominio.

Modelo de amenaza

El concepto clave de Microsoft: el dominio no es un límite de seguridad; el bosque sí. Dentro de un mismo bosque, todos los dominios confían en el Enterprise Admins y comparten el esquema y la configuración; comprometer un dominio hijo permite escalar a la raíz del bosque. Entre bosques, la confianza puede estar mitigada (SID filtering) o no, y ahí el atacante busca los huecos: SID history, trust keys, y trusts mal configurados.

Conceptos

Dirección: unidireccional o bidireccional; “A confía en B” significa que B puede autenticar en A.
Transitividad: transitivo (se encadena: si A↔B y B↔C, A alcanza C) o no.
Intra-forest (entre dominios del mismo bosque, confianza bidireccional y transitiva por defecto) vs inter-forest (entre bosques, con SID filtering por defecto).

Red Team

Enumeración

# enumerar trusts del dominio y del bosque
Get-DomainTrust            # PowerView
Get-DomainTrust -API
nltest /domain_trusts /all_trusts
# desde Linux
nxc ldap <DC> -u user -p pass -M enum_trusts

BloodHound mapea los trusts y, crucialmente, qué principales de un dominio tienen privilegios en otro.

Escalada dominio hijo → raíz del bosque

Dentro de un bosque, dos técnicas clásicas usan la trust key o el SID history para forjar un ticket que la raíz acepta:

SID History injection / Golden Ticket entre dominios: desde el dominio hijo (siendo DA del hijo), forjas un TGT que incluye en su SID history el SID del grupo Enterprise Admins de la raíz. La raíz, al no filtrar SIDs dentro del bosque, lo acepta → DA en la raíz.

# con el krbtgt del dominio hijo + el SID de Enterprise Admins de la raíz
mimikatz # kerberos::golden /user:Administrator /domain:hijo.corp.local \
  /sid:<SID-hijo> /krbtgt:<hash> /sids:<SID-raiz>-519 /ptt
# impacket:
ticketer.py -nthash <krbtgt_hijo> -domain-sid <SID-hijo> -domain hijo.corp.local \
  -extra-sid <SID-raiz>-519 Administrator

Trust ticket (inter-realm TGT): usas la clave del trust (volcada del DC) para forjar un ticket inter-dominio directamente.

Entre bosques (inter-forest)

Si SID filtering está deshabilitado (común en trusts antiguos “internos” o mal configurados), el SID history funciona también entre bosques → escalada cross-forest.
Trusts con SID history permitido, foreign group membership (un usuario de bosque A en un grupo privilegiado de bosque B), y abuso de ACLs cross-forest descubiertas con BloodHound.
Kerberoasting/roasting a través del trust (pedir TGS de servicios del otro dominio).

Herramientas

mimikatz (kerberos::golden con /sids), impacket (ticketer.py, raiseChild.py — automatiza hijo→raíz).
PowerView / BloodHound — enumeración de trusts y relaciones foráneas.
Rubeus — forja y uso de tickets inter-realm.

Impacto

Expansión de un dominio comprometido a toda la estructura: de un dominio hijo a Enterprise Admin de la raíz del bosque, y —donde el SID filtering falla— de un bosque a otro. Es cómo un compromiso “local” se convierte en control de toda la organización.

Blue Team

Detección

Tickets con SID history inusual (SIDs de otro dominio, especialmente -519 Enterprise Admins); eventos 4769 con PAC anómalo.
Autenticaciones inter-dominio fuera de lo normal; uso de cuentas foráneas en grupos privilegiados.
Creación/uso de Golden/Trust tickets (ver Persistencia en Active Directory: TGT sin AS-REQ previo, lifetimes anómalos).

Telemetría

Monitoriza autenticaciones cross-domain/cross-forest, PAC validation, y cambios en trusts. Audita membresías de grupos privilegiados con SIDs foráneos.

Hardening

Habilita SID filtering (quarantine) en los trusts, especialmente inter-forest; revisa trusts legacy que lo tengan desactivado.
Selective authentication en trusts inter-forest (solo cuentas explícitamente autorizadas).
Minimiza y audita los trusts: elimina los que ya no se usan; documenta dirección/transitividad.
Protege la raíz del bosque como Tier 0 máximo; separa la administración por dominio.
Vigila membresías foráneas en grupos privilegiados y ACLs cross-domain (BloodHound).

Respuesta

Si un trust fue abusado, asume compromiso del/los dominio(s) alcanzados: rota krbtgt (×2) de los dominios afectados y las trust keys, revisa membresías con SID foráneo, y reconsidera la arquitectura de trusts.

CVEs y casos reales

La escalada hijo→raíz vía SID history es técnica estándar (MITRE T1134.005 SID-History Injection, T1482 Domain Trust Discovery); raiseChild.py la automatiza.
Microsoft insiste: “el dominio no es un límite de seguridad” — base de estos ataques.
Trusts inter-forest sin SID filtering han permitido saltos entre bosques en evaluaciones y compromisos reales documentados por SpecterOps/Semperis.
Golden/Trust tickets aparecen en intrusiones APT para persistencia y expansión entre dominios.

Checklist de prueba

Enumerar trusts (dirección, transitividad, intra/inter-forest)
¿Eres DA de un dominio hijo? → SID history a Enterprise Admins (raíz)
raiseChild.py / golden ticket con /sids de la raíz
Trust key volcada → inter-realm trust ticket
Inter-forest: ¿SID filtering deshabilitado?
Membresías foráneas / ACLs cross-forest (BloodHound)
Blue: ¿SID filtering y selective auth en los trusts?