Ataques Kerberos en Active Directory: Kerberoasting, Golden Ticket y delegaciones

Los ataques Kerberos son la familia de técnicas que más críticos produce en cualquier pentesting interno contra Active Directory: explotan el propio diseño del protocolo, no fallos de software. En la mayoría de dominios con deuda de configuración habitual permiten pasar de un usuario sin privilegios a Domain Admin en cuestión de horas. Salen mapeados en MITRE ATT&CK bajo la técnica T1558 Steal or Forge Kerberos Tickets y sus sub-técnicas.

Esta guía explica cómo funciona Kerberos en Active Directory paso a paso, los siete ataques que aparecen una y otra vez en informes de Red Team y pentesting interno (Kerberoasting, AS-REP Roasting, Pass-the-Ticket, Silver Ticket, Golden Ticket, abuso de delegaciones y DCSync), cómo se detectan en SIEM o EDR y qué mitigaciones realmente cierran la puerta. Está orientada a equipos azules, equipos rojos y responsables de seguridad que tienen un AD heredado y quieren entender la huella de riesgo real.

Cómo funciona Kerberos en Active Directory

Kerberos es el protocolo de autenticación por defecto en Active Directory desde Windows 2000. Sustituyó a NTLM en escenarios modernos porque añade tres propiedades que NTLM no daba: autenticación mutua, no envía contraseñas por la red y permite delegación.

Los actores del protocolo:

• KDC (Key Distribution Center). Servicio que reside en cada controlador de dominio (DC). Internamente tiene dos servicios: AS (Authentication Server) y TGS (Ticket Granting Service).
• Cliente. Usuario o equipo que se autentica.
• Servicio. Recurso al que el cliente quiere acceder (file server, SQL, sitio IIS, share).
• Tickets. Estructuras cifradas que prueban quién es el cliente: TGT (Ticket Granting Ticket) y ST/TGS (Service Ticket).

El flujo simplificado de una autenticación normal cuando un usuario se conecta a una máquina del dominio y abre un share \\fileserver01\datos:

1. AS-REQ. El cliente envía una petición al AS pidiendo un TGT. Cifra un timestamp con el hash de su contraseña como prueba de identidad (preautenticación).
2. AS-REP. El AS valida y devuelve un TGT firmado y cifrado con la clave de la cuenta krbtgt del dominio. El cliente almacena el TGT en memoria.
3. TGS-REQ. Cuando el cliente quiere acceder al servicio, envía el TGT al TGS pidiendo un ticket para cifs/fileserver01.
4. TGS-REP. El TGS devuelve un ST cifrado con el hash NT de la cuenta del servicio (la cuenta de máquina o la cuenta de servicio asociada al SPN).
5. AP-REQ. El cliente presenta el ST al servicio.
6. El servicio descifra el ST con su propia clave y deja entrar al cliente sin volver al DC.

Tres ideas que importan para entender los ataques: el TGT lo firma krbtgt, los STs los cifran las cuentas de servicio con su hash NT, y todo el modelo asume que las claves de esas cuentas están bien protegidas. Cada uno de los ataques siguientes rompe alguna de esas asunciones.

Kerberoasting (T1558.003)

El ataque más rentable y más fácil de ejecutar. Lo descubrió Tim Medin en 2014 y desde entonces aparece en el 80% de los pentest internos.

Vector. Cualquier usuario autenticado del dominio puede pedir un TGS para cualquier cuenta de servicio que tenga un SPN (Service Principal Name) registrado. El ST devuelto va cifrado con el hash NT de la contraseña de esa cuenta de servicio. Si la contraseña es débil, el atacante la rompe offline sin generar tráfico anómalo.

Pasos típicos:

1. Enumerar cuentas con SPN: Get-ADUser -Filter "ServicePrincipalName -ne '$null'" -Properties ServicePrincipalName o GetUserSPNs.py de Impacket.
2. Pedir el TGS: Rubeus.exe kerberoast o GetUserSPNs.py -request.
3. Romper offline con hashcat -m 13100.

Por qué funciona. Las contraseñas de cuentas de servicio se ponen una vez y nunca rotan. En la mitad de los AD reales hay alguna cuenta con Service123 o el nombre de la empresa más un año.

Mitigación efectiva:

• Sustituir cuentas de servicio tradicionales por gMSA (Group Managed Service Accounts): passwords de 240 bytes generadas por el dominio, rotadas automáticamente cada 30 días.
• Para las que no se pueden migrar, contraseñas de 25+ caracteres aleatorios y rotación documentada.
• Auditoría de ServicePrincipalName para descubrir SPNs olvidados (cuentas que ya no se usan pero siguen activas).

Detección. Eventos 4769 (Kerberos service ticket requested) con encryption type 0x17 (RC4) hacia cuentas de usuario son un canario clásico. Los DCs modernos pueden forzar AES y descartar RC4, lo que rompe la versión simple del ataque. Reglas Sigma públicas mapean el patrón.

AS-REP Roasting (T1558.004)

Variante de Kerberoasting que no requiere estar autenticado en el dominio.

Vector. Cuentas con el flag DONT_REQ_PREAUTH activado (preautenticación Kerberos deshabilitada) responden a un AS-REQ con un AS-REP que contiene material cifrado con el hash NT de la cuenta. Cualquiera con conectividad al DC puede pedirlo y crackearlo offline.

Pasos:

1. Listar cuentas vulnerables: GetNPUsers.py dominio.local/ -no-pass -usersfile users.txt.
2. Pedir AS-REP de las que devuelvan material.
3. Romper con hashcat -m 18200.

Por qué aparece. El flag se suele activar cuando una aplicación legacy no soporta preautenticación. Pasa el tiempo, la aplicación se retira y la cuenta queda con el flag puesto pero ya no protegida por nadie.

Mitigación: revisar userAccountControl y eliminar el flag salvo justificación documentada y firmada. Si hay justificación, contraseña gMSA o de 25+ caracteres rotada.

Pass-the-Ticket

Una vez el atacante tiene un TGT o un ST robado de la memoria de un equipo comprometido, lo inyecta en su propia sesión y se autentica como el usuario original sin saber su contraseña.

Pasos típicos:

1. Ganar acceso a un endpoint y elevar privilegios locales.
2. Volcar tickets desde memoria con mimikatz sekurlsa::tickets /export o con Rubeus.
3. Inyectar en una sesión propia: Rubeus.exe ptt /ticket:archivo.kirbi.
4. Acceder al recurso como la víctima.

Por qué importa. La cuenta legítima sigue conectada y trabajando, no hay credencial expuesta y la trazabilidad del incidente se complica porque el log dice que ha entrado el usuario real.

Mitigación: limitar privilegios locales (un usuario estándar no debería poder volcar memoria), Credential Guard en Windows 10/11 y Server 2016+, segmentación de cuentas privilegiadas (Tier 0 / Tier 1 / Tier 2), reducir TGT lifetime.

Silver Ticket

El atacante forja un Service Ticket sin contactar con el DC, si conoce el hash NT de la cuenta de servicio o de la cuenta de máquina.

Vector. Como el ST se cifra con la clave de la cuenta de servicio, quien tenga ese hash puede emitir tickets arbitrarios. No pasa por el DC, así que no genera evento 4769.

Pasos:

1. Conseguir el hash NT (por Kerberoasting previo, dumping de SAM en una máquina o memoria de un host comprometido).
2. Forjar el ST: mimikatz kerberos::golden /sid:... /target:... /service:... /rc4:... /user:Administrator.
3. Acceder al servicio como cualquier usuario, incluso falsificado.

Por qué es peligroso. La detección que mira al DC no ve nada. Si el atacante apunta a cifs (file shares) o host (servicios sobre la máquina), tiene control total sobre ese activo.

Mitigación: rotar el hash NT de la cuenta de servicio invalida los Silver Tickets emitidos. gMSA rota solo. Logging del propio servicio (no solo del DC) detecta accesos extraños.

Golden Ticket (T1558.001)

El más impactante. El atacante forja un TGT firmado con el hash de la cuenta krbtgt del dominio. Como el TGT lo emite y lo verifica el propio dominio, cualquier TGT firmado con krbtgt se acepta. Equivale a tener un pase de Domain Admin permanente.

Vector. Conseguir el hash NT (o las claves AES) de krbtgt.

Pasos:

1. Comprometer el DC o ejecutar DCSync con permisos suficientes (más abajo).
2. Volcar krbtgt: mimikatz lsadump::dcsync /user:krbtgt.
3. Forjar TGT con TTL arbitrario (años) y SID de Domain Admins: mimikatz kerberos::golden /user:cualquiera /domain:dom.local /sid:... /krbtgt:hash /id:500 /groups:512 /ptt.
4. Acceder a cualquier recurso del bosque como administrador.

Por qué cuesta erradicarlo. El hash de krbtgt rara vez se rota. Una vez exfiltrado, queda válido para siempre salvo doble rotación. Y la doble rotación rompe sesiones activas si se hace mal, así que se pospone.

Mitigación:

• Rotación periódica de krbtgt (script oficial de Microsoft Reset-KrbtgtKeys.ps1). Doble rotación con 24h de margen para invalidar TGTs forjados sin tirar el dominio.
• Reducir el camino a DCSync. Auditar replicación, eliminar permisos Replicating Directory Changes y Replicating Directory Changes All de cuentas no DC.
• Tier model Microsoft: las cuentas Tier 0 (administradores del dominio) no inician sesión nunca en Tier 1 ni Tier 2.
• Protected Users group para administradores: no pueden usar RC4, no se cachean credenciales y los TGTs son de corta vida.

Diamond Ticket y Sapphire Ticket

Variantes modernas (Charlie Bromberg / SpecterOps, 2021-2022) que ofuscan mejor que el Golden Ticket clásico. En lugar de forjar el TGT desde cero, el atacante pide un TGT legítimo, lo descifra con el hash de krbtgt y modifica solo los campos críticos (SID, groups). El resultado es un TGT que parece más auténtico y puede pasar detección que busca patrones de forja Mimikatz.

Sapphire añade que el TGT modificado contiene un PAC pedido al propio DC, en lugar de uno construido por el atacante, lo que reduce aún más el ruido. La mitigación es la misma que para Golden Ticket: si krbtgt está rotado, el ataque no compone.

Unconstrained Delegation

Configuración que permite que un servicio actúe en nombre del cliente que se conecta. Cuando un usuario accede a un servicio con unconstrained delegation, su TGT completo se almacena en la memoria del servidor servicio. Si el atacante controla ese servidor, puede esperar a que un Domain Admin se conecte y robar su TGT.

Pasos:

1. Identificar máquinas con flag TRUSTED_FOR_DELEGATION: PowerView Get-NetComputer -Unconstrained o BloodHound.
2. Comprometer una de esas máquinas.
3. Esperar (o forzar con PetitPotam, SpoolSample) a que un usuario privilegiado se conecte.
4. Volcar TGTs y reusar.

Mitigación. Eliminar unconstrained delegation salvo casos justificados. Marcar Domain Admins como Account is sensitive and cannot be delegated (flag NOT_DELEGATED). Añadir admins críticos al grupo Protected Users.

Constrained Delegation y RBCD

Constrained delegation limita la delegación a servicios específicos (campo msDS-AllowedToDelegateTo). Más segura que unconstrained, pero si el atacante consigue controlar la cuenta con la delegación, puede pivotar a esos servicios suplantando a cualquier usuario, incluyendo Domain Admins, mediante el truco S4U2Self + S4U2Proxy con getST.py de Impacket.

Resource-Based Constrained Delegation (RBCD) le da el control de la delegación al recurso destino en lugar de al origen. Es más manejable, pero abusable: si el atacante consigue privilegio WriteProperty sobre msDS-AllowedToActOnBehalfOfOtherIdentity de una máquina, puede escribir su propia cuenta como autorizada y suplantar a quien quiera contra esa máquina.

Mitigación. Auditar todas las delegaciones existentes. Reducir a las estrictamente necesarias. Proteger administradores con NOT_DELEGATED y Protected Users.

DCSync

No es estrictamente un ataque "Kerberos" pero es la entrada habitual a Golden Ticket. Permite a un atacante con permisos Replicating Directory Changes y Replicating Directory Changes All pedir al DC que replique credenciales (incluido krbtgt) usando el protocolo MS-DRSR, sin necesidad de comprometer físicamente un DC.

Pasos:

1. Verificar permisos: Get-ObjectAcl -DistinguishedName "DC=dom,DC=local" | Where-Object {$_.ActiveDirectoryRights -match "GenericAll|Replicating"}.
2. Ejecutar: mimikatz lsadump::dcsync /domain:dom.local /user:krbtgt.
3. Resultado: hash NT y claves AES de krbtgt. A partir de ahí, Golden Ticket.

Mitigación. Auditar y restringir esos permisos. Solo cuentas de máquina de DCs y herramientas legítimas de auditoría deberían tenerlos. Cualquier otra concesión es potencialmente explotable.

Detección con SIEM y EDR

Los eventos clave en Windows Security log:

• 4768: TGT solicitado (AS-REP). Útil para ver cuentas activas y patrones anómalos.
• 4769: TGS solicitado. Pico de 4769 con EncryptionType 0x17 (RC4) hacia cuentas de usuario marca Kerberoasting clásico.
• 4624 / 4625: logon success / failure. Combinado con tipo de logon revela uso de tickets robados.
• 5136: cambio en directorio. DCSync deja huella si se audita correctamente la replicación.
• 4742 / 4738: cambios en cuentas de usuario y máquina. Útil para detectar modificación de delegaciones.

Plataformas como Microsoft Defender for Identity, Wazuh con reglas custom, SIEMs comerciales y EDR con módulo de identity (CrowdStrike Falcon Identity, SentinelOne Singularity Identity) tienen detección preconstruida para Kerberoasting, AS-REP Roasting y patrones de Pass-the-Ticket. La cobertura suele ser buena en Kerberoasting y Golden Ticket; más débil en delegaciones y RBCD, donde la línea entre tráfico legítimo y abuso es más fina.

Cómo se mapean en MITRE ATT&CK

La familia entra en T1558 Steal or Forge Kerberos Tickets con sub-técnicas:

• T1558.001 Golden Ticket
• T1558.002 Silver Ticket
• T1558.003 Kerberoasting
• T1558.004 AS-REP Roasting
• T1558.005 Ccache Files (relevante en Linux con Kerberos cliente)

DCSync entra en T1003.006 OS Credential Dumping: DCSync. Las delegaciones se cubren bajo T1550.003 Use Alternate Authentication Material: Pass the Ticket. Mantener un mapa vivo de cobertura sobre estos identificadores en ATT&CK Navigator es la forma habitual de medir si el SOC los detecta de verdad.

Mitigaciones que sí cierran la puerta

Resumen práctico, ordenado por impacto:

• gMSA en todas las cuentas de servicio que lo soporten. Cierra Kerberoasting de un golpe.
• Rotación periódica de krbtgt con script oficial. Invalida Golden Tickets antiguos. La cadencia razonable es cada 6-12 meses, doble rotación con margen.
• Tier model Microsoft. Separación estricta de cuentas Tier 0 / Tier 1 / Tier 2. Los administradores de dominio no se conectan nunca a estaciones de trabajo o servidores intermedios.
• Protected Users para todos los administradores críticos. Bloquea RC4, NTLM y delegación.
• Eliminar unconstrained delegation salvo casos justificados con expediente firmado.
• Auditar userAccountControl y eliminar DONT_REQ_PREAUTH cuando no esté justificado.
• Credential Guard en endpoints para evitar volcado de tickets desde memoria.
• Forzar AES y deshabilitar RC4 en Kerberos cuando sea posible.
• Privilegios Replicating Directory Changes revisados, auditados y minimizados.

Ningún punto cierra solo el problema. La defensa contra ataques Kerberos es por capas, y la deuda de configuración acumulada en AD se va limpiando con rondas anuales.

Encaje con compliance

Para empresas españolas bajo regulación, demostrar gestión de identidades del dominio es parte explícita del marco:

• NIS2 (artículo 21). Medidas de control de acceso, gestión de identidades y monitorización. Un AD lleno de Kerberoasting trivial no aprueba auditoría seria.
• DORA (artículos 9, 10). Medidas técnicas y organizativas, control de acceso lógico. Las entidades financieras tienen escrutinio adicional sobre identidades privilegiadas.
• ENS Real Decreto 311/2022. Medidas op.acc (control de acceso), op.exp.8 (registro de actividad de usuarios). Cubre nominalmente lo necesario para detectar abuso de Kerberos.
• ISO 27001:2022 (controles 8.5, 8.7, 5.18). Autenticación segura, gestión de privilegios, registro y monitorización.
• PCI DSS v4.0 (req. 7, 8, 10). Control de acceso, autenticación y trazabilidad. AD que sirve a entornos PCI tiene que pasar revisión específica.

Preguntas frecuentes

¿Qué es exactamente la cuenta krbtgt?

Es una cuenta de servicio creada automáticamente al promover el primer DC del dominio. No se usa para iniciar sesión; su única función es firmar y cifrar los TGTs que emite el KDC. Su hash NT es la "llave maestra" del dominio. Por eso un atacante con ese hash puede emitir Golden Tickets indefinidamente.

¿Cada cuánto se debería rotar krbtgt?

Microsoft recomienda hacerlo de forma reactiva tras un incidente y proactivamente entre cada 6 y 12 meses, siempre con doble rotación separada al menos 24 horas para que TGTs legítimos en circulación no se invaliden bruscamente. Hay un script oficial publicado por Microsoft para automatizarlo de forma segura.

¿Sirve de algo deshabilitar Kerberos y usar solo NTLM?

No. NTLM tiene problemas peores (Pass-the-Hash, NTLM Relay) y muchos servicios modernos exigen Kerberos. La línea correcta es endurecer Kerberos (AES only, gMSA, Protected Users, sin unconstrained), no quitarlo.

¿BloodHound encuentra todos estos problemas?

BloodHound visualiza relaciones, ACLs y caminos a Domain Admin a partir de datos enumerados. Detecta unconstrained delegation, RBCD potencial, ACLs peligrosas, Kerberoastable users y AS-REP Roastable users en una pasada. Es el primer paso del trabajo, pero la explotación real (forja, cracking, abuso de delegación) requiere tooling específico (Rubeus, Impacket, Mimikatz) y experiencia.

¿Entra ID (Azure AD) elimina estos riesgos?

Solo parcialmente. Entra ID no usa Kerberos para autenticación cloud, pero sigue habiendo Kerberos en los recursos on-premise sincronizados (servidores AD locales, file shares, aplicaciones legacy). Mientras una empresa tenga AD híbrido, los ataques Kerberos siguen aplicando contra esa parte del entorno. La migración cloud-first reduce la superficie pero no la elimina hasta que se retira el AD on-premise.

¿Puede un escáner de vulnerabilidades detectar Kerberoasting?

No con fidelidad. Nessus o Qualys señalan configuraciones débiles genéricas pero no enumeran SPNs ni piden TGS para validar. La forma realista de descubrirlo es ejecutar el ataque en modo controlado (parte estándar de un pentest interno) o desplegar herramientas específicas de auditoría AD (PingCastle, Purple Knight, Semperis DSP).

Recursos relacionados

• Pentesting de infraestructura interna y externa: donde estos ataques se ejecutan en un proyecto real, con metodología y entregables.
• Qué es MITRE ATT&CK: el framework que cataloga T1558 y permite medir cobertura defensiva.
• Qué es threat hunting: la disciplina que caza patrones de Kerberoasting o Pass-the-Ticket cuando no han disparado alerta.
• Qué es un SIEM y Wazuh open source: plataformas donde se centralizan los eventos 4768/4769 y se construyen detecciones.
• Red Team: guía para empresas y TIBER-EU: ejercicios donde el ataque a Kerberos se incluye casi siempre como parte del plan.
• Qué es un EDR y qué es un MDR: controles que añaden detección de identidad sobre los eventos del DC.

Auditoría de Active Directory en Secra

En Secra hacemos pentesting interno con foco específico en Active Directory: enumeración con BloodHound y PowerView, auditoría de delegaciones, ejecución de Kerberoasting, AS-REP Roasting y validación de detección con purple team, revisión de tier model, mapeo de hallazgos a MITRE ATT&CK y entregable orientado a remediación priorizada. Si tu organización nunca ha auditado el dominio, va por su tercer admin y nadie está seguro de qué SPNs hay vivos, o necesita validar AD antes de una auditoría NIS2 o DORA, escríbenos a través de contacto o consulta nuestro servicio de auditoría de infraestructura.