EtcSecBeta
🏢Active DirectoryKerberosAttack PathsPrivileged Access

Ataque Golden Ticket — Deteccion & Remediacion

Un Golden Ticket es un TGT Kerberos falsificado que otorga acceso ilimitado y persistente a todos los recursos de un dominio Active Directory. Aprenda como funciona, como detectarlo y como detenerlo.

Younes AZABARBy Younes AZABAR10 min read
Ataque Golden Ticket — Deteccion & Remediacion

Que es un Golden Ticket?

Un 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.

⚠️ Critico: Un Golden Ticket sigue siendo valido hasta que la contrasena de KRBTGT se rote dos veces. Restablecer todas las demas cuentas del dominio no tiene ningun efecto.


Como Funciona

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

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 obtener Service Tickets (TGS) para recursos especificos.
  3. Los servicios validan el TGS y conceden acceso.

Ningun servicio valida los TGTs directamente con el KDC en el momento de su uso: confian en la firma. Un TGT falsificado, firmado con el hash real de KRBTGT, es indistinguible de uno legitimo.


La Cadena de Ataque

Paso 1 - Obtener Privilegios de Domain Admin

El atacante necesita privilegios suficientes para extraer el hash de KRBTGT, tipicamente comprometiendo un Controlador de Dominio o abusando de derechos de DCSync.

Paso 2 - Extraer el Hash de KRBTGT via DCSync

# Mimikatz
lsadump::dcsync /domain:corp.local /user:krbtgt
# Impacket (desde Linux)
impacket-secretsdump -just-dc-user krbtgt corp.local/admin:[email protected]

Paso 3 - Falsificar el Golden Ticket

kerberos::golden /user:Administrator /domain:corp.local /sid:S-1-5-21-XXXXXXXXXX /krbtgt:HASH /ptt
ParametroDescripcion
/userCualquier nombre de usuario, real o ficticio
/sidSID del dominio (de la salida de DCSync)
/krbtgtHash NTLM de la cuenta KRBTGT
/endinDuracion del ticket en minutos — los atacantes suelen poner 87600 (10 anos)
/pttPass-the-ticket: inyectar directamente en la sesion actual

Paso 4 - Acceso Total y Persistencia

El TGT falsificado es aceptado por todos los servicios del dominio. El atacante puede acceder a cualquier recurso compartido, sesion RDP, crear cuentas backdoor y distribuir GPOs maliciosas.


Deteccion

Event IDs de Windows

Event IDFuenteQue buscar
4768DC - SecuritySolicitudes de TGT desde IPs inusuales o fuera de horario
4769DC - SecurityCifrado RC4 (0x17) cuando AES es el estandar
4672DC - SecurityPrivilegios especiales asignados a cuentas inesperadas
4624Estacion/ServidorInicio de sesion de red (Tipo 3) desde cuentas sin actividad previa

Anomalias de Comportamiento

  • Duracion del ticket superior a 10 horas - el maximo predeterminado de Microsoft es 10h
  • Nombres de usuario inexistentes en eventos Kerberos
  • Cifrado RC4 cuando el dominio impone AES
  • Solicitud TGS sin AS-REQ previo en el DC

Consulta SIEM (Elastic KQL)

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

💡 Consejo: Aplique cifrado AES exclusivo en su dominio. Cualquier trafico RC4 se convierte en una alerta de alta confianza.


Remediacion

⚠️ Requisito previo: Identifique y contenga el vector de compromiso antes de rotar KRBTGT.

Acciones Inmediatas

Rotar la contrasena de KRBTGT dos veces, con un retraso entre rotaciones igual a la duracion maxima de los tickets (predeterminado: 10 horas):

# https://github.com/microsoft/New-KrbtgtKeys.ps1
.\New-KrbtgtKeys.ps1 -Mode ModeSingle
# Esperar al menos 10 horas
.\New-KrbtgtKeys.ps1 -Mode ModeSingle

Endurecimiento

ControlDescripcion
Privileged Access Workstations (PAW)Restringir los inicios de sesion de Domain Admin a estaciones dedicadas
Modelo de Administracion en NivelesEvitar la exposicion de credenciales Tier 0 en sistemas Tier 1/2
Grupo Protected UsersDeshabilita RC4, NTLM y almacenamiento en cache de credenciales
Aplicar AESEstablecer msDS-SupportedEncryptionTypes = 24 en KRBTGT
Auditar derechos DCSyncAlertar sobre cuentas no-DC con DS-Replication-Get-Changes-All

Como EtcSec Detecta Esto

EtcSec verifica las condiciones que hacen posibles 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.

Controles relacionados:

  • WEAK_KERBEROS_POLICY - configuraciones permisivas amplian la ventana de exposicion
  • KERBEROS_RC4_FALLBACK - RC4 aun permitido facilita la falsificacion y dificulta la deteccion
  • UNCONSTRAINED_DELEGATION - precursor comun de los ataques Golden Ticket

ℹ️ Nota: EtcSec verifica automaticamente estas vulnerabilidades en cada auditoria AD. Ejecute una auditoria gratuita para verificar si su entorno esta expuesto.

Lecturas Relacionadas

Este tema se entiende mejor cuando se compara con Abuso ACL y DCSync: Las Rutas Silenciosas hacia Domain Admin, Ataques de Delegacion Kerberos: De la Delegacion No Restringida al Abuso RBCD y Kerberoasting: Como los Atacantes Crackean Contrasenas de Cuentas de Servicio. Esos articulos cubren las rutas adyacentes, las hipotesis de privilegio y los fallos de control que suelen aparecer juntos en una evaluacion real.

Esa revision cruzada ayuda a validar si estas corrigiendo un fallo aislado o toda la cadena de exposicion alrededor de identidades, delegacion y privilegios.

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. El primer paso es 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 dependencias de negocio existen, que privilegios exponen y que excepciones de emergencia se fueron acumulando con el tiempo. Ese trabajo evita una remediacion superficial, porque el sintoma tecnico suele ser menor que el radio de impacto operativo. Cuando el equipo documenta el camino completo entre configuracion, privilegio y uso real, puede priorizar cambios que reducen riesgo sin romper accesos legitimos ni bloquear operaciones esenciales.

Controles Adyacentes a Revisar

Cuando un atacante entra en su entorno Active Directory, rara vez se queda en el primer hallazgo. Alrededor de Golden Ticket: Las Llaves de Tu Dominio, normalmente intenta encadenar el acceso con cuentas privilegiadas obsoletas, anidamiento peligroso, delegacion excesiva, politicas de contrasenas debiles y abuso de ACL heredadas. Por eso la defensa debe revisar no solo la debilidad principal, sino tambien cada dependencia cercana que convierta un acceso inicial en persistencia o escalada. Hay que confirmar que identidades, roles, permisos y supuestos de confianza se pueden reutilizar. Si el cambio solo cierra un objeto, pero deja abiertas rutas vecinas, el riesgo real apenas mejora. Una revision seria de las cadenas de abuso es lo que convierte este tema en una accion de hardening y no en un parche aislado.

Evidencia y telemetria que conviene revisar

Una respuesta madura a Golden Ticket: Las Llaves de Tu Dominio necesita evidencia que pueda ser revisada por ingenieria y deteccion. Recopile Event IDs 4624, 4662, 4670, 4688, 4728, 4732, 4768, 4769, 5136, cambios en SYSVOL y actividad de certificados, compare cambios recientes con ventanas de mantenimiento esperadas y separe cuentas u objetos cuyo comportamiento no tenga una justificacion de negocio clara. Esa evidencia debe responder tres preguntas: cuando aparecio la exposicion, quien puede seguir aprovechandola y si existen variantes similares en otra parte de su entorno Active Directory. Revisar telemetria tambien permite diferenciar deuda tecnica antigua de abuso activo o de controles relajados recientemente. Esa diferencia cambia por completo la prioridad, la comunicacion y el orden correcto de remediacion.

Debilidades vecinas que deben entrar en la revision

Muy pocos entornos contienen Golden Ticket: Las Llaves de Tu Dominio de forma aislada. En la practica, la misma zona del tenant o del directorio suele contener tambien cuentas privilegiadas obsoletas, anidamiento peligroso, delegacion excesiva, politicas de contrasenas debiles y abuso de ACL heredadas, y esas debilidades vecinas determinan si la exposicion se queda en un problema molesto o se convierte en un camino critico. Revise owners compartidos, permisos heredados, excepciones duplicadas y atajos administrativos que ya nadie cuestiona. Si el mismo patron de riesgo se repite en varios objetos, lo mas probable es que exista una falla de proceso y no solo un error tecnico individual. Esa vista ampliada mejora la probabilidad de eliminar la ruta completa y no solo una pieza visible.

Orden de remediacion que reduce riesgo rapido

En Golden Ticket: Las Llaves de Tu Dominio, la remediacion debe seguir un orden que baje el riesgo antes de perseguir la perfeccion. Primero elimine las rutas con mayor valor de escalada, despues proteja las identidades u objetos mas sensibles y, por ultimo, corrija los problemas de higiene secundarios. Use tiering, limpieza de delegaciones, revision de ACLs, higiene de cuentas de servicio, revision de permisos GPO y hardening ADCS como conjunto de controles objetivo. Cada cambio debe tener owner, nota de rollback y una validacion clara. Esa disciplina evita que el trabajo se detenga despues de la primera mejora tecnica. Si una reforma completa no es posible hoy, documente controles intermedios y programe el trabajo estructural para el siguiente revision semanal de privilegios y validacion mensual de controles.

Como validar despues de cada cambio

Tras modificar cualquier configuracion relacionada con Golden Ticket: Las Llaves de Tu Dominio, valide el resultado desde la vista del administrador legitimo y desde la vista de la ruta de ataque. Confirme que usuarios y sistemas autorizados siguen funcionando y demuestre a la vez que el camino peligroso ya no entrega el mismo apalancamiento. Recoja de nuevo Event IDs 4624, 4662, 4670, 4688, 4728, 4732, 4768, 4769, 5136, cambios en SYSVOL y actividad de certificados, revise aprobaciones y verifique que ningun objeto vecino conserva una via de escape. La validacion tambien debe incluir criterios de exito escritos. En equipos maduros, un cambio se cierra solo cuando el camino de riesgo desaparece, el servicio sigue operativo y el estado final coincide con el objetivo de hardening.

Lecturas Relacionadas

Conviene revisar este tema junto con Delegacion Kerberos: De No Restringida a RBCD, Kerberoasting: Riesgo en Cuentas de Servicio, Abuso ACL y DCSync: Las Rutas Silenciosas hacia Domain Admin, Ataques Confianza AD: De Dominio Hijo a Raiz y AS-REP Roasting: Recopilando Hashes Sin Credenciales. Estos articulos muestran como las mismas debilidades de identidad y permisos suelen encadenarse en una evaluacion real.

Estas referencias internas ayudan a evaluar el camino de riesgo completo y no solo un hallazgo aislado.