Panorama#

Kerberos es el protocolo de autenticación por defecto de Active Directory desde Windows 2000, y es también el eje sobre el que gira buena parte del abuso ofensivo del directorio. Su diseño reemplaza el modelo “usuario + contraseña en cada solicitud” por un modelo de posesión: quien tiene el ticket correcto, tiene el acceso, sin necesidad de volver a probar quién es. Esa propiedad —la credencial es un objeto transferible, no un secreto que se vuelve a demostrar— es exactamente lo que un atacante explota en cada técnica de este capítulo: se puede robar un ticket, se puede pedir uno legítimamente y craquearlo, o se puede directamente forjar uno desde cero si se posee la clave criptográfica correcta.

El Key Distribution Center (KDC, un rol que corre en cada controlador de dominio) resuelve dos preguntas distintas con dos sub-protocolos: el AS-Exchange ("¿quién es?") entrega un Ticket-Granting Ticket (TGT), válido por defecto 10 horas y renovable hasta 7 días, que prueba la identidad del usuario ante el propio KDC sin que este tenga que volver a verificar la contraseña. El TGS-Exchange ("¿puede acceder a este servicio?") usa ese TGT para pedir un Service Ticket (ST, también llamado TGS) específico para un recurso — un share SMB, una base SQL, una sesión WinRM. Los tickets viven en dos formatos según la herramienta que los maneja: .kirbi (Mimikatz, Rubeus, el ecosistema Windows) y .ccache (Impacket, el ecosistema Linux); son convertibles entre sí con ticketConverter.py o el misc::convert de kekeo, así que el formato en disco delata qué kit usó quien lo generó.

Todo lo que sigue —Kerberoasting, AS-REP Roasting, Pass-the-Hash, Pass-the-Ticket y la familia de tickets forjados— es una variación sobre ese mismo tema: conseguir un ticket válido sin conocer la contraseña real de la cuenta que representa. El punto de entrada suele ser el reconocimiento de SPNs y cuentas del dominio cubierto en 4.1 · Reconocimiento de AD; el punto de llegada, con frecuencia, es el compromiso de la cuenta krbtgt y el movimiento lateral que se detalla en 4.5 · Credential dumping y 4.8 · Movimiento lateral.

flowchart LR
  A["Usuario de dominio\nsin privilegios"] -->|"4769: ST de un SPN"| B["Kerberoasting"]
  A -->|"4768: AS-REQ sin pre-auth"| C["AS-REP Roasting"]
  B --> D["Crack offline\nhashcat -m 13100/19600/19700"]
  C --> D2["Crack offline\nhashcat -m 18200"]
  D --> E["Contraseña de cuenta\nde servicio"]
  D2 --> E
  E -->|"NT hash"| F["Pass-the-Hash /\nOverPass-the-Hash"]
  F --> G["Acceso lateral con\nidentidad legítima"]
  G --> H["Dump de LSASS / DCSync\n(ver 4.5)"]
  H --> I["Hash de krbtgt"]
  I --> J["Golden Ticket"]
  I --> K["Diamond / Sapphire Ticket"]
  J --> L["Persistencia de dominio\n(ver 4.9)"]
  K --> L

Reutilización de tickets: Pass-the-Ticket#

La forma más directa de abusar de Kerberos ni siquiera requiere craquear nada: si un ticket —propio o robado— ya existe en disco o en memoria, inyectarlo en la sesión actual alcanza. Esto es Pass-the-Ticket (PTT para .kirbi, PTC para .ccache), y su mecánica es la contracara exacta del modelo de posesión descrito arriba. Un ejemplo mínimo sobre un dominio ya comprometido: con Mimikatz, kerberos::list enumera los tickets presentes en la máquina y kerberos::list /export los guarda como .kirbi; con uno de esos archivos, kerberos::ptt ticket.kirbi seguido de una nueva consola (misc::cmd) deja a esa consola operando con la identidad completa del ticket inyectado — sin conocer la contraseña de esa cuenta en ningún momento. El equivalente en el ecosistema Impacket usa .ccache: export KRB5CCNAME=administrator.ccache antes de invocar cualquier herramienta que hable Kerberos (psexec.py -k -no-pass, crackmapexec --use-kcache) logra el mismo efecto.

# Mimikatz — exportar y reinyectar un ticket robado de la sesión actual
kerberos::list /export
kerberos::ptt ticket.kirbi
misc::cmd

# Impacket — variante .ccache
export KRB5CCNAME=/tmp/administrator.ccache
psexec.py -k -no-pass -dc-ip <IP-DC> AD/administrator@<host>

Kerberoasting: craquear lo que cualquiera puede pedir#

Kerberoasting explota una decisión de diseño de Kerberos que, vista con ojos ofensivos, es casi un regalo: cualquier usuario autenticado del dominio puede pedir un Service Ticket para cualquier SPN (Service Principal Name, el identificador de un servicio en el directorio, por ejemplo MSSQLSvc/sql01.corp.local), sin que eso requiera privilegio alguno. Ese ST viaja cifrado con el hash de la contraseña de la cuenta que corre el servicio — no con la del usuario que lo pidió. Un atacante con una sola cuenta de dominio válida, sin ningún privilegio adicional, puede entonces solicitar los ST de todas las cuentas con SPN registrado y craquear esos hashes offline, sin generar ningún intento de login fallido contra la cuenta objetivo.

# Enumerar y pedir tickets de servicio (Impacket)
GetUserSPNs.py corp.local/usuario:contraseña -dc-ip <IP-DC> -request

# Rubeus: /rc4opsec solo pide RC4 a las cuentas sin AES (evita la anomalía)
Rubeus.exe kerberoast /rc4opsec
# por defecto pide el etype que cada cuenta soporta (AES si está habilitado)
Rubeus.exe kerberoast

# Crack offline según el tipo de cifrado del ticket
hashcat -m 13100 hashes.txt wordlist.txt   # RC4 ($krb5tgs$23$)
hashcat -m 19600 hashes.txt wordlist.txt   # AES128
hashcat -m 19700 hashes.txt wordlist.txt   # AES256

El cifrado del ticket importa para la viabilidad del crackeo: un hash $krb5tgs$23$... es etype 23, RC4, derivado directamente de la contraseña de la cuenta de servicio y por lo tanto mucho más rápido de craquear que un equivalente AES. Herramientas como Rubeus explotan esto pidiendo deliberadamente RC4 cuando la cuenta lo permite (/rc4opsec comprueba primero qué etypes soporta cada cuenta para no llamar la atención pidiendo RC4 a una cuenta que normalmente usaría AES). La mitigación estructural es simple de enunciar y difícil de operar en la práctica: contraseñas de más de 32 caracteres en toda cuenta con SPN, o mejor, migrar esas cuentas a group Managed Service Accounts (gMSA), cuya contraseña la rota el propio dominio y nunca la conoce ningún humano.

AS-REP Roasting y variantes: el ataque que ni siquiera necesita una cuenta#

Si Kerberoasting requiere una cuenta de dominio válida, AS-REP Roasting baja la barrera todavía más: apunta a cuentas configuradas con el flag DONT_REQ_PREAUTH (pre-autenticación Kerberos deshabilitada), una opción legada por compatibilidad con implementaciones antiguas del protocolo. Contra esas cuentas, cualquiera puede pedir un AS-REP —la respuesta del AS-Exchange— sin demostrar conocer la contraseña primero, y una porción de esa respuesta viene cifrada con el hash de la cuenta objetivo, craqueable offline exactamente igual que un ticket de servicio.

# Enumerar cuentas sin pre-autenticación e intentar el roast (Impacket)
GetNPUsers.py corp.local/ -no-pass -usersfile usuarios.txt

# Rubeus
Rubeus.exe asreproast /format:hashcat /outfile:hashes.txt

# Crack offline
hashcat -m 18200 hashes.txt wordlist.txt   # $krb5asrep$23$

Dos primos de este ataque valen mención breve porque comparten la misma lógica de “romper la pre-autenticación”: CVE-2022-33679 fuerza un downgrade de cifrado a RC4-MD4 contra cuentas sin pre-auth, y es explotable sin ninguna autenticación previa — la vulnerabilidad más severa de la familia porque no exige ni siquiera un usuario válido conocido. Timeroasting es más una curiosidad de nicho: abusa del servicio NTP de un controlador de dominio para obtener, a partir del RID de una cuenta de máquina, un hash craqueable sin autenticarse — útil en escenarios donde el resto de la superficie Kerberos está bien cerrada pero NTP quedó expuesto.

Kerberoasting y AS-REP Roasting no dejan ningún intento de login fallido: la respuesta craqueable se obtiene en una interacción legítima con el KDC. La detección no puede depender de contadores de fallos — tiene que mirar la telemetría de emisión de tickets en sí misma (ver la sección de defensa más abajo).

De un hash a un ticket: Pass-the-Hash y OverPass-the-Hash#

Una vez craqueada una contraseña —o, más a menudo, volcado un NT hash directamente de LSASS o del SAM local (técnica cubierta en 4.5 · Credential dumping)— quedan dos caminos para convertirlo en acceso. Pass-the-Hash (PtH) autentica directamente contra NTLM usando el NT hash en lugar de la contraseña en texto claro; por las UAC remote restrictions (reforzadas por KB2871997 en Windows 7/2008 R2 y posteriores) y la política LocalAccountTokenFilterPolicy, esta técnica queda restringida a la cuenta built-in RID 500 cuando el objetivo es una cuenta local de otra máquina, lo que la volvió menos universal de lo que fue en su día contra hosts unidos a dominio.

OverPass-the-Hash (también llamado pass-the-key) resuelve esa limitación convirtiendo el problema: en lugar de autenticar por NTLM, usa el NT hash —o, más sigilosamente, la clave AES derivada de la contraseña— para pedirle al KDC un TGT completamente legítimo. El resultado es indistinguible, para el controlador de dominio, de una autenticación Kerberos normal.

# OverPass-the-Hash con Impacket: NT hash -> TGT legítimo
getTGT.py -hashes :1a59bd44... corp.local/usuario
export KRB5CCNAME=usuario.ccache

# Rubeus: variante RC4 (menos sigilosa) y variante AES + /opsec (recomendada)
Rubeus.exe asktgt /user:administrator /rc4:<NTLM-hash> /ptt
Rubeus.exe asktgt /user:administrator /aes256:<AES256-hash> /opsec /ptt

La variante /aes256 /opsec es preferible siempre que se disponga de la clave AES: un TGT pedido con AES es indistinguible de tráfico Kerberos normal, mientras que uno pedido con RC4 sobre una cuenta que habitualmente usa AES es, en sí mismo, un indicador de compromiso.

La familia de tickets forjados: Golden, Silver, Diamond, Sapphire#

Hasta acá, todos los tickets usados fueron legítimos —pedidos al KDC o robados de una sesión real—. La familia de tickets forjados cambia de estrategia: en lugar de pedir o robar, se fabrica un ticket offline, sin que el KDC participe en su creación. Los cuatro miembros de la familia forman una progresión donde cada paso cambia sigilo por alcance:

  • Golden Ticket. Se forja un TGT completo usando el hash NT (o la clave AES) de la cuenta krbtgt, la cuenta de servicio del propio KDC que firma y cifra todos los TGT del dominio. Con el nombre de dominio, el SID y ese hash, un atacante fabrica un TGT para cualquier identidad — incluido /id:500, el RID del administrador del dominio. Es el máximo alcance posible: control total y persistente, mientras la cuenta krbtgt no rote su contraseña. También es el menos sigiloso: cada uso pasa igualmente por el KDC para pedir los STs subsiguientes, y Mimikatz le pone por defecto una validez de diez años, un valor que en cualquier entorno real es una anomalía flagrante.
  • Silver Ticket. En lugar de la clave de krbtgt, se forja directamente un ST usando la clave de la cuenta de servicio objetivo. El alcance se reduce a ese único servicio, pero a cambio el ticket nunca contacta al controlador de dominio — es, en la práctica, indetectable desde la telemetría del DC. Qué se puede hacer con él depende del SPN forjado: HOST+RPCSS habilita WMI, CIFS+HTTP habilita PowerShell Remoting, HTTP+wsman habilita WinRM, CIFS solo alcanza para listar shares, y LDAP —el caso más peligroso— permite ejecutar un DCSync contra ese controlador.
  • Diamond Ticket. Parte de un TGT legítimo obtenido normalmente y solo recalcula el PAC (el bloque de autorización dentro del ticket, que declara membresías de grupo y privilegios) usando la clave de krbtgt. El resultado se parece mucho más a tráfico real que un Golden Ticket, porque el TGT de base sí pasó por el KDC.
  • Sapphire Ticket. Va un paso más allá: en vez de recalcular el PAC a mano, lo obtiene del PAC real del usuario objetivo mediante un intercambio S4U2self+U2U, clonándolo casi a la perfección.
# Golden Ticket (Mimikatz) — requiere el NT hash de krbtgt
lsadump::dcsync /user:krbtgt
kerberos::golden /user:evilcorp /domain:corp.local /sid:S-1-5-21-... /krbtgt:<hash> /id:500 /ptt

# Silver Ticket — requiere la clave de la cuenta de SERVICIO, no la de krbtgt
kerberos::golden /user:ANY /domain:corp.local /sid:<SID> /target:sql01.corp.local /service:MSSQLSvc /rc4:<hash-servicio> /ptt

# Diamond Ticket (Impacket ticketer.py) — TGT real + PAC recalculado
ticketer.py -request -domain corp.local -user usuario -password <pass> -nthash <krbtgt-hash> -aesKey <krbtgt-AES> evilcorp
El Golden Ticket es persistencia de dominio de grado terminal: una vez forjado, sobrevive a cambios de contraseña de cualquier usuario, incluidos los administradores. La única forma de invalidarlo es rotar la contraseña de krbtgt dos veces (la primera rotación deja válido el hash anterior por compatibilidad durante la propagación; recién la segunda lo elimina). Cerrar un incidente que involucró compromiso de krbtgt sin esa doble rotación deja la puerta abierta.

Bajo el capó: el PAC y por qué un ticket se puede forjar#

Todo lo anterior es un catálogo de técnicas; conviene bajar una vez al nivel de la estructura, porque tres decisiones de diseño del protocolo explican por qué la familia entera funciona, y esas mismas tres son las que un analista tiene que entender para distinguir un ticket forjado de uno legítimo y para operar la mitigación que cierra el capítulo.

La clave RC4 es el NT hash. Cuando el KDC cifra un ticket con RC4-HMAC (etype 23), la clave que emplea es, matemáticamente, el NT hash de la cuenta: no una clave derivada, sino el hash MD4 de la contraseña tal cual. Dos consecuencias salen directo de ahí. Primero, craquear un ticket RC4 —Kerberoasting— equivale a craquear el NT hash, sin salt ni iteraciones que frenen el ataque, a diferencia de AES256, cuya clave se deriva con PBKDF2 (miles de iteraciones más un salt que combina dominio y usuario). Segundo, forjar con RC4 —Golden o Silver— requiere únicamente el NT hash de la cuenta: el de krbtgt para el Golden, el de la cuenta de servicio para el Silver, que es exactamente lo que un DCSync o un volcado de LSASS de 4.5 · Credential dumping entrega. RC4 en Kerberos no es «un cifrado viejo» en abstracto: es el NT hash puesto a hacer de clave, y por eso deshabilitarlo —forzar AES— sube el costo tanto del crackeo como de la forja.

El PAC es el bloque de autorización y viaja dentro del ticket cifrado. El Privilege Attribute Certificate (PAC) es la estructura que responde el «¿qué puede hacer?» del modelo: transporta los SID del usuario, sus membresías de grupo —incluido Domain Admins si corresponde— y los claims de autorización. Va incrustado en el TGT (firmado con la clave de krbtgt) y se copia dentro de cada Service Ticket. Cuando el servicio de destino recibe el AP-REQ, descifra el ticket con su propia clave, lee el PAC y construye a partir de él el token de acceso del usuario: así es como «quién es más a qué grupos pertenece» llega hasta la máquina objetivo sin que esta consulte el directorio.

El talón de Aquiles: la validación del PAC. El PAC lleva dos firmas HMAC —una del servidor (con la clave del servicio) y otra del KDC (con la clave de krbtgt)— pensadas para impedir su manipulación. El problema histórico es que el servicio de destino construía el token confiando en el PAC sin pedirle al KDC que validara localmente la firma: le bastaba con que el ticket descifrara correctamente con su propia clave. Ese es, al nivel de la estructura, el motivo por el que funciona toda la familia de tickets forjados: quien posee una clave —la de krbtgt para el Golden, la del servicio para el Silver— cifra un ticket con ella, le incrusta un PAC que declara la membresía que quiera, y el servicio lo acepta. La familia de tickets forjados es, vista desde adentro, una familia de PAC forjados. Por eso el Silver Ticket «nunca contacta al DC»: no lo necesita, porque el servicio nunca iba a preguntarle.

Ese mecanismo se puede abrir con las manos, y hacerlo es lo que convierte la ingeniería de detección en inspección en lugar de conjetura. Con el módulo NtObjectManager en PowerShell, un contexto de cliente (New-LsaClientContext -Package Kerberos para un SPN) dispara un AP-REQ; Get-KerberosKey calcula la clave RC4 a partir de una contraseña de prueba; y Unprotect-LsaAuthToken descifra la estructura y expone el bloque AD_WIN2K_PAC con sus SID, sus membresías de grupo y las firmas HMAC. Poder diseccionar un intercambio real es lo que permite reconocer, en un incidente, un PAC cuyas firmas no cierran.

Defensa y detección#

La telemetría de Kerberos vive mayormente en el registro de eventos de seguridad del controlador de dominio, con dos IDs centrales y varios secundarios:

  • Event ID 4769 (solicitud de Service Ticket) es la señal de Kerberoasting: buscar Ticket Encryption Type = 0x17 (RC4) en solicitudes hacia SPNs de cuentas de usuario —no de máquina— es la base de la detección, y la señal se vuelve mucho más fuerte cuando un mismo principal pide STs para muchos SPNs distintos en poco tiempo. Forzar AES vía msDS-SupportedEncryptionTypes en las cuentas de servicio sube directamente el costo de craqueo y elimina el downgrade a RC4 como opción.
  • Event ID 4768 (solicitud de TGT, AS-REQ) es la señal de AS-REP Roasting: un 4768 sin el evento de pre-autenticación asociado, sobre una cuenta con DONT_REQ_PREAUTH, es el indicador; el mismo ID, con cifrado degradado a RC4-MD4 fuera de cualquier patrón habitual, apunta a CVE-2022-33679.
  • Event ID 4624 tipo 3 con paquete de autenticación NTLM donde el contexto (host unido a dominio, cuenta de dominio) haría esperar Kerberos es el indicador de Pass-the-Hash.
  • Sysmon Event ID 10 sobre lsass.exe es la señal temprana que precede a casi toda esta cadena: el volcado de credenciales que alimenta tanto OverPass-the-Hash como, más adelante, el propio hash de krbtgt — ver 4.5 · Credential dumping para el detalle de esa técnica.
  • El Golden Ticket es, por diseño, difícil de detectar en el momento de su creación (no pasa por el KDC), pero dos anomalías lo delatan con confiabilidad: TGTs con tiempos de vida absurdos (los diez años por defecto de Mimikatz) y el uso de un TGT sin un 4768 correlacionado que lo haya emitido.
  • El Silver Ticket es, de los cuatro, el más difícil de ver desde el DC porque nunca lo contacta. Su detección se traslada al servicio de destino: un 4624 de logon exitoso en ese servicio sin el par 4768/4769 correspondiente en el controlador de dominio es la anomalía a correlacionar.
  • La validación de firma del PAC es la contramedida estructural al talón de Aquiles descrito arriba, y con los años dejó de ser opcional. Tras CVE-2021-42278/CVE-2021-42287 —la cadena noPac, que abusaba del renombrado de una cuenta de máquina para que el KDC emitiera un PAC con la identidad de un DC— Microsoft endureció el manejo del PAC en dos rondas (KB5008380 en 2021 y la firma extendida del PAC de KB5020805 en 2022), forzando que las firmas del PAC se validen y rechazando los tickets cuyo PAC no cierra. Mantener esa aplicación activada y las cuentas de máquina al día es lo que degrada a los tickets forjados de «indetectables» a «rechazables»: es la defensa que ataca la causa en vez del síntoma.

La postura defensiva combina hardening estructural con higiene operativa: contraseñas largas o gMSA en toda cuenta con SPN, marcar las cuentas privilegiadas como “Account is Sensitive and Cannot Be Delegated”, deshabilitar RC4 donde el entorno lo permita, tratar todo controlador de dominio como Tier 0, y —ante cualquier sospecha de compromiso de krbtgt— ejecutar la doble rotación mencionada arriba. El mapeo defensivo consolidado de toda la superficie de Active Directory, con las reglas SIEM y los playbooks de respuesta, se desarrolla en 4.9 · Defensa de AD.

Referencias#

  • red-infra/ad-attacks/cap-05 — Tickets Kerberos: Golden/Silver/Diamond/Sapphire, roasting y Pass-the-Hash.
  • red-infra/ad-cluster/cap-01 — MimiKatz for Pentester: el módulo kerberos::.
  • red-infra/windows-security-internals/cap-14 — Forshaw, Kerberos: la estructura de los intercambios AS/TGS desde las APIs de Windows, la clave RC4 como NT hash, la anatomía del PAC (AD_WIN2K_PAC, SIDs, firmas HMAC) y su inspección con NtObjectManager (New-LsaClientContext, Get-KerberosKey, Unprotect-LsaAuthToken); la ausencia de validación local del PAC como raíz de los tickets forjados.
  • CVE-2021-42278 / CVE-2021-42287 (noPac) y el endurecimiento de firma del PAC (KB5008380, KB5020805).
  • MITRE ATT&CK — T1558 Steal or Forge Kerberos Tickets y sus sub-técnicas .001 (Golden Ticket), .002 (Kerberoasting), .003 (AS-REP Roasting), .004 (Silver Ticket).
  • CVE-2022-33679 — downgrade de cifrado Kerberos no autenticado contra cuentas sin pre-autenticación.