Ataque Golden Ticket — Deteccion & Remediacion

Que es un Ataque Golden Ticket?

Un ataque Golden Ticket es un Ticket Granting Ticket (TGT) de Kerberos falsificado que otorga a un atacante acceso ilimitado y persistente a todos los recursos de un dominio Active Directory, sin necesitar la contrasena de ningun usuario.

El ataque abusa de la cuenta KRBTGT, cuyo hash se utiliza para firmar cada TGT emitido en el dominio. Si un atacante obtiene este hash, puede fabricar TGTs validos para cualquier usuario, incluidos los Administradores de Dominio, con cualquier pertenencia a grupos y cualquier fecha de expiracion que elija.

Esto convierte al Golden Ticket en una de las tecnicas de post-explotacion mas graves en Active Directory: un unico hash robado se traduce en control indefinido de todo el dominio.

Como Funciona un Ataque Golden Ticket

La autenticacion Kerberos se basa en un tercero de confianza: el Key Distribution Center (KDC), que se ejecuta en cada Controlador de Dominio.

El flujo normal:

1. Un usuario se autentica ante el KDC y recibe un TGT, firmado con el hash de KRBTGT.
2. El usuario presenta el TGT para solicitar Service Tickets (TGS) para recursos especificos.
3. Los servicios validan el TGS y conceden acceso.

La cuenta KRBTGT es la raiz de confianza para todos los TGT del dominio. Ningun servicio valida los TGTs directamente con el KDC en el momento de uso: confian en la firma. Esto significa que un TGT falsificado, firmado con el hash real de KRBTGT, es indistinguible de uno legitimo.

La Cadena de Ataque

Paso 1 - Obtener Domain Admin (o equivalente)

El atacante necesita privilegios suficientes para extraer el hash de KRBTGT. Esto normalmente implica comprometer un Controlador de Dominio o cualquier cuenta con derechos DS-Replication-Get-Changes-All (DCSync).

Rutas de escalada habituales que llevan hasta aqui: Kerberoasting de una cuenta de servicio privilegiada, abuso de ADCS ESC1/ESC8 o explotacion de delegacion no restringida.

Paso 2 - Extraer el Hash de KRBTGT via DCSync

El atacante ejecuta un ataque DCSync con Mimikatz o Impacket para obtener el hash NTLM de KRBTGT sin tocar el disco del DC ni generar un evento de inicio de sesion:

# Mimikatz
lsadump::dcsync /domain:corp.local /user:krbtgt

# Impacket (remoto, desde Linux)
impacket-secretsdump -just-dc-user krbtgt corp.local/admin:[email protected]

La salida incluye el hash NTLM y el SID del dominio, ambos necesarios para falsificar el ticket.

Paso 3 - Falsificar el Golden Ticket

Con el hash de KRBTGT y el SID del dominio, el atacante fabrica un TGT para el usuario que elija:

# Mimikatz — falsificar e inyectar directamente en la sesion actual
kerberos::golden /user:Administrator /domain:corp.local /sid:S-1-5-21-XXXXXXXXXX /krbtgt:HASH /ptt

Parametros clave:

Paso 4 - Acceso Total al Dominio y Persistencia

El TGT falsificado es aceptado por todos los servicios del dominio. El atacante ahora puede:

• Acceder a cualquier recurso compartido, sesion RDP, endpoint WMI o servicio DCOM
• Crear nuevas cuentas backdoor y anadirlas a grupos privilegiados
• Distribuir GPOs maliciosas a todas las maquinas
• Mantener persistencia indefinida — restablecer la contrasena de cualquier cuenta de usuario no tiene ningun efecto

Deteccion

Los Golden Tickets son dificiles de detectar porque los TGTs falsificados parecen trafico Kerberos legitimo. El KDC no se consulta en el momento de usar el ticket, por lo que no se genera ningun evento de autenticacion en el DC cuando el ticket se presenta a un servicio.

La deteccion depende del analisis de anomalias en lugar de la correlacion directa de eventos.

Event IDs de Windows

Anomalias de Comportamiento

• Duracion del ticket superior a 10 horas - el maximo predeterminado de Microsoft es 10 horas; los tickets falsificados suelen tener duraciones de anos
• Nombres de usuario inexistentes en eventos Kerberos - los Golden Tickets pueden falsificarse para cuentas que no existen en AD
• Cifrado RC4 cuando el dominio impone solo AES - las herramientas antiguas usan RC4 (0x17) por defecto
• Solicitud TGS sin AS-REQ previo - una solicitud de service ticket en un DC sin la correspondiente solicitud de TGT es un fuerte indicador
• Discrepancia de SID - el SID incrustado en el ticket no coincide con ninguna cuenta real de AD

Consulta SIEM (Elastic KQL)

event.code: "4769" AND
winlog.event_data.TicketEncryptionType: "0x17" AND
NOT winlog.event_data.ServiceName: ("krbtgt" OR "*$")

event.code: "4768" AND
winlog.event_data.TicketEncryptionType: "0x17" AND
winlog.event_data.PreAuthType: "0"

Remediacion

Respuesta Inmediata

Rote la contrasena de KRBTGT dos veces, con un retraso entre rotaciones igual a la duracion maxima del ticket Kerberos (predeterminado: 10 horas).

• La primera rotacion invalida todos los tickets falsificados actualmente activos.
• La segunda rotacion elimina el hash anterior de la memoria del DC, evitando el uso de tickets falsificados con el hash antiguo.

Utilice el script de reinicio de krbtgt mantenido activamente, que gestiona automaticamente las comprobaciones de replicacion multi-DC:

# Descargar y ejecutar Reset-KrbTgt-Password-For-RWDCs-And-RODCs.ps1
# https://github.com/zjorz/Public-AD-Scripts/blob/master/Reset-KrbTgt-Password-For-RWDCs-And-RODCs.md

.\Reset-KrbTgt-Password-For-RWDCs-And-RODCs.ps1 -modeOfOperation resetModeKrbTgtProdAccountsResetOnce -targetedADforestFQDN corp.local -targetedADdomainFQDN corp.local -targetKrbTgtAccountScope allRWDCs
# Esperar al menos 10 horas (duracion maxima del ticket)
.\Reset-KrbTgt-Password-For-RWDCs-And-RODCs.ps1 -modeOfOperation resetModeKrbTgtProdAccountsResetOnce -targetedADforestFQDN corp.local -targetedADdomainFQDN corp.local -targetKrbTgtAccountScope allRWDCs

Endurecimiento para Prevenir el Compromiso Inicial

Verificar la Exposicion a DCSync

# Encontrar cuentas con derechos DCSync (cuentas no-DC con permisos de replicacion)
Get-ADObject -Filter * -Properties nTSecurityDescriptor | Where-Object {
    $_.nTSecurityDescriptor.Access | Where-Object {
        $_.ObjectType -eq "1131f6ad-9c07-11d1-f79f-00c04fc2dcd2" -and
        $_.IdentityReference -notmatch "Domain Controllers"
    }
}

Como EtcSec Detecta Esto

EtcSec verifica las condiciones que hacen posibles y persistentes los ataques Golden Ticket en su entorno.

La deteccion GOLDEN_TICKET_RISK senala entornos donde la contrasena de la cuenta KRBTGT no ha sido rotada recientemente — un indicador directo de que cualquier Golden Ticket falsificado previamente podria seguir siendo valido.

Controles relacionados adicionales:

• WEAK_KERBEROS_POLICY - configuraciones de duracion y renovacion de tickets Kerberos que amplian la ventana de exposicion para tickets falsificados
• KERBEROS_RC4_FALLBACK - cifrado RC4 aun permitido en el dominio, necesario para falsificar tickets con herramientas antiguas y que dificulta la deteccion
• UNCONSTRAINED_DELEGATION - cuentas con delegacion no restringida que pueden usarse para capturar TGTs, un precursor habitual de los ataques Golden Ticket

Prioridades de Revision

Golden Ticket: Las Llaves de Tu Dominio debe tratarse como una exposicion real dentro de su entorno Active Directory, no como una configuracion aislada. Empiece por definir el perimetro de revision: que grupos privilegiados, cuentas de servicio, ACLs, enlaces GPO, trusts, delegaciones, plantillas de certificados y estaciones admin estan afectados, que flujos de negocio dependen de ellos, que privilegios exponen y que excepciones de emergencia se fueron anadiendo con el tiempo. Ese paso de definicion de alcance evita una remediacion superficial, porque el sintoma tecnico suele ser mas pequeno que el radio de impacto operativo. Al documentar el camino completo desde la configuracion hasta el privilegio, el equipo puede priorizar cambios que reduzcan el riesgo rapidamente sin romper el acceso en produccion. Esto tambien crea una base defendible para la validacion posterior y le da a la direccion una explicacion clara de por que el problema importa ahora.

Controles Adyacentes a Revisar

Cuando los atacantes llegan a su entorno Active Directory, rara vez se detienen en el primer punto debil. Alrededor de Golden Ticket: Las Llaves de Tu Dominio, normalmente prueban si la ruta expuesta puede encadenarse con cuentas privilegiadas obsoletas, anidamiento de grupos inseguro, delegacion excesiva, configuraciones de contrasena debiles, rutas de GPO con permisos de escritura y abuso de ACL heredadas. Eso significa que los defensores deben revisar no solo la debilidad principal, sino tambien cada dependencia cercana que convierta el acceso en persistencia o escalada de privilegios. Confirme que identidades, roles, permisos y supuestos de confianza pueden ser reutilizados por un operador motivado. Si una correccion cierra solo un objeto mientras deja intactas las rutas de privilegio adyacentes, el riesgo efectivo apenas cambia. Una revision disciplinada de las oportunidades de encadenamiento es lo que convierte este tema en un ejercicio de hardening practico en lugar de una simple casilla marcada.

Lecturas Relacionadas

Revise este tema junto con Delegacion Kerberos: no restringida, restringida y RBCD, Deteccion prevencion kerberoasting: cómo identificar y proteger cuentas de servicio crackeables, Abuso ACL y DCSync: Las Rutas Silenciosas hacia Domain Admin, Ataques de confianza AD: del dominio hijo a la raiz del bosque y AS-REP Roasting: Recopilando Hashes Sin Credenciales. Esos articulos relacionados muestran como las mismas debilidades de identidad suelen encadenarse en una evaluacion real, en lugar de aparecer como hallazgos aislados.

• Delegacion Kerberos: no restringida, restringida y RBCD
• Deteccion prevencion kerberoasting: cómo identificar y proteger cuentas de servicio crackeables
• Abuso ACL y DCSync: Las Rutas Silenciosas hacia Domain Admin
• Ataques de confianza AD: del dominio hijo a la raiz del bosque
• AS-REP Roasting: Recopilando Hashes Sin Credenciales

Usar esas referencias mantiene la discusion de remediacion centrada en la ruta de ataque completa, en lugar de en una unica brecha de control.

Lista de Verificacion de Validacion

Antes de cerrar la revision, vuelva a ejecutar las mismas comprobaciones que revelaron el problema y confirme que la ruta de riesgo ya no existe desde la perspectiva del atacante. Verifique las identidades, privilegios, rutas de herencia y controles compensatorios relevantes en produccion, no solo en staging o en la documentacion. Registre al responsable tecnico, la dependencia de negocio esperada y la evidencia que demuestra que la nueva configuracion es a la vez mas segura y operativamente sostenible. Ese paso final de validacion es lo que mantiene el articulo anclado en como los equipos realmente reducen el riesgo de identidad.