Kerberoasting y AS-REP Roasting: dos ataques clásicos contra Kerberos en Active Directory

Kerberos es el protocolo que Active Directory usa por defecto para autenticar usuarios y servicios. Fue diseñado para evitar que las contraseñas viajen por la red: el usuario demuestra que las conoce con pruebas cifradas y recibe tickets que luego usa para acceder a los recursos. Durante años se ha considerado uno de los mejores protocolos de autenticación disponibles, y lo sigue siendo.

Pero Kerberos tiene dos puntos donde la criptografía depende de la fortaleza de contraseñas elegidas por humanos: los tickets de servicio (TGS) y, en ciertos casos, la preautenticación inicial. Un atacante que pida esos tickets puede llevárselos a su equipo, crackearlos sin conexión con hashcat y, si alguna contraseña es débil, obtener credenciales de servicios y usuarios sin dejar rastro ruidoso en la red.

Estos dos ataques, Kerberoasting y AS-REP Roasting, aparecen en prácticamente cualquier auditoría de Active Directory con éxito. Los labs orthrus y titancorp de whoami-labs los incluyen en su recorrido.

Practica solo contra dominios propios o entornos autorizados, como los laboratorios de whoami-labs. Atacar Kerberos de un dominio ajeno sin permiso es un delito.

Resumen de cómo funciona Kerberos#

Para entender los ataques, necesitas solo tres ideas:

1. AS-REQ / AS-REP (autenticación inicial). El cliente envía una petición al KDC (Key Distribution Center, que está en el DC) y el KDC le devuelve un TGT (Ticket Granting Ticket). Para probar que es realmente el usuario, cifra parte de la petición con la clave derivada de su contraseña (preautenticación).
2. TGS-REQ / TGS-REP (acceso a servicios). Con el TGT, el cliente pide un TGS (Ticket Granting Service) para un servicio concreto (por ejemplo, HTTP/web01.corp.local). El KDC le devuelve un ticket cifrado con la clave del servicio (derivada de la contraseña de la cuenta que ejecuta ese servicio).
3. AP-REQ (uso del servicio). El cliente presenta el TGS al servicio para autenticarse.

La parte importante para los ataques: tanto el TGT como el TGS contienen datos cifrados con claves derivadas de contraseñas. Si esas contraseñas son débiles, se pueden crackear sin conexión.

Kerberoasting#

La idea#

Cualquier usuario autenticado del dominio puede pedir un TGS para cualquier servicio registrado en el directorio (identificado por un SPN, Service Principal Name). El KDC se lo da sin preguntar más, porque la validación real la hará el servicio cuando el cliente intente usar el ticket.

Ese TGS contiene datos cifrados con la contraseña de la cuenta que ejecuta el servicio. Si es una cuenta de servicio con contraseña débil, un atacante puede pedir el ticket, llevárselo a su equipo y crackearlo con hashcat (modo 13100 para RC4 y 19700 para AES-256).

Por qué funciona#

• Los SPN son públicos en el directorio: cualquier usuario puede listarlos con ldapsearch o Impacket.
• El KDC entrega el TGS sin requerir permiso adicional.
• Muchas cuentas de servicio tienen contraseñas estáticas que no se cambian durante años.
• El ataque es sin conexión: tras obtener el ticket, el crackeo no genera tráfico en el dominio.

Paso a paso en un laboratorio#

En un laboratorio autorizado con cuenta maria del dominio:

# Listar cuentas con SPN (candidatos a Kerberoasting)
GetUserSPNs.py corp.local/maria:Verano2026 -dc-ip IP_DEL_DC

# Pedir los TGS y guardarlos en formato crackeable
GetUserSPNs.py corp.local/maria:Verano2026 -dc-ip IP_DEL_DC -request -outputfile tgs.hashes

Cada línea del archivo es un hash crackeable. Lo pasas a hashcat:

# Modo 13100: Kerberos 5 TGS-REP etype 23 (RC4)
hashcat -a 0 -m 13100 tgs.hashes /usr/share/wordlists/rockyou.txt

Si alguna contraseña está en el diccionario (o en una variación común), hashcat te devuelve la clave en claro. A partir de ahí tienes credenciales válidas de esa cuenta de servicio y puedes usarlas para lo que permita.

En laboratorios como orthrus y titancorp, este ataque es un paso previsto del recorrido.

AS-REP Roasting#

La idea#

Para evitar un ataque de fuerza bruta contra el KDC, Kerberos exige preautenticación: en el AS-REQ, el cliente cifra una marca de tiempo con la clave derivada de su contraseña. Si el KDC no puede descifrarla con la clave que tiene registrada, rechaza la petición.

Pero existe una opción (DONT_REQ_PREAUTH) que desactiva esta preautenticación para ciertas cuentas, normalmente por compatibilidad con clientes antiguos. Cuando esa opción está activa, el KDC devuelve el AS-REP a cualquiera que pregunte, y ese AS-REP contiene datos cifrados con la contraseña del usuario. Crackearlos sin conexión ya no requiere tener cuenta siquiera: el ataque funciona solo conociendo el nombre del usuario.

Paso a paso en un laboratorio#

En un laboratorio autorizado:

# Con cuenta: buscar usuarios con preautenticación desactivada
GetNPUsers.py corp.local/maria:Verano2026 -request -format hashcat -outputfile asrep.hashes

# Sin cuenta: si tienes nombres de usuario de otra fuente
GetNPUsers.py corp.local/ -usersfile usuarios.txt -no-pass -format hashcat -outputfile asrep.hashes

Y se crackea con:

# Modo 18200: Kerberos 5 AS-REP etype 23
hashcat -a 0 -m 18200 asrep.hashes /usr/share/wordlists/rockyou.txt

Las contraseñas débiles de usuarios caen en segundos.

Las dos técnicas, lado a lado#

Ambos se llevan a cabo sin conexión tras obtener los tickets, lo que los hace muy sigilosos para los sensores que vigilan tráfico de red.

Variantes útiles de conocer#

Más allá de los dos clásicos, hay variaciones que aparecen en auditorías más avanzadas:

Targeted Kerberoasting#

Si la cuenta objetivo no tiene SPN, pero el atacante tiene permisos de escritura sobre su atributo servicePrincipalName, puede añadir un SPN temporal, pedir el TGS, crackearlo y luego quitarlo. Es una vía indirecta muy habitual con cuentas que un auditor «no debería poder tocar» pero sobre las que tiene permisos mínimos de escritura heredados de una mala configuración de ACL.

AS-REP Roasting con cuenta pero sin preauth#

En versiones antiguas de Impacket, GetNPUsers.py solo probaba cuentas sin preauth. Las versiones modernas aceptan -request con credenciales, lo que permite listar automáticamente todas las vulnerables del dominio sin tener que pasarle una lista de usuarios.

Timeroasting (CVE-2020-11025)#

Un ataque menos conocido que abusa del servicio de tiempo del controlador de dominio (NTP) para pedir hashes de cuentas de máquina. Funciona en controladores sin parchear y permite obtener hashes NTLM de cuentas $ que luego se crackean como un Kerberoast normal. Requiere configuración muy específica, pero sigue apareciendo en labs y en dominios con mantenimiento deficiente.

Cuentas de máquina con contraseñas débiles#

En teoría, las cuentas de máquina (WS01$, DC01$) tienen contraseñas aleatorias que rota el sistema. En la práctica, encontrar máquinas unidas al dominio con el nombre predecible y la contraseña por defecto (igual al nombre en minúsculas) es sorprendentemente habitual en entornos pequeños. Prueba siempre nxc smb IP -u 'WS01$' -p 'ws01' o variantes con el nombre del equipo por si acaso: es un tirón barato que a veces da sorpresas.

Cómo elegir un diccionario eficaz#

El crackeo depende de la calidad del diccionario. Algunas pistas:

• rockyou.txt: punto de partida obligatorio.
• Mangling con reglas de hashcat (-r rules/best64.rule): aplica variaciones típicas (mayúsculas iniciales, años al final, sustituciones).
• Diccionarios temáticos: nombres de la empresa, productos, lugares, con años. Cuentas de servicio suelen llevar el nombre del servicio (sql2024, backupBOT!).
• CeWL: genera un diccionario a partir de la web pública de la empresa.

Mezclar el diccionario con reglas duplica o triplica la tasa de éxito frente a usar la lista tal cual.

Cómo defenderse#

Cuentas de servicio con contraseñas fuertes o gMSA#

La raíz del Kerberoasting son contraseñas débiles en cuentas con SPN. Las defensas:

• gMSA (Group Managed Service Accounts): el propio AD genera y rota una contraseña larga automáticamente cada 30 días. Es la mejor opción.
• Si no puedes usar gMSA, al menos contraseñas aleatorias de 25+ caracteres y rotación.

Forzar AES en lugar de RC4#

Los TGS cifrados con RC4 se crackean mucho más rápido que los cifrados con AES (modos 13100 vs 19700 de hashcat). Forzar AES ralentiza enormemente el ataque:

• En cada cuenta de servicio, marcar la opción «Esta cuenta admite cifrado AES-128/AES-256 de Kerberos».
• Desactivar RC4 a nivel de dominio cuando sea posible.

Eliminar la opción DONT_REQ_PREAUTH#

Es la raíz del AS-REP Roasting. Enumera y corrige:

Get-ADUser -Filter 'DoesNotRequirePreAuth -eq $true' -Properties DoesNotRequirePreAuth

Para cualquier cuenta devuelta, desactiva la opción salvo que haya una razón imposible de evitar.

Protected Users y SPN «dinámicos»#

El grupo Protected Users aplica una serie de restricciones duras, incluido no permitir cifrado RC4 ni delegación. Las cuentas sensibles deberían ir ahí. Además, revisar periódicamente los SPN del dominio: si una cuenta antigua tiene uno que ya nadie usa, bórralo.

Auditoría#

• Evento 4769 de Windows registra cada TGS emitido. Un pico de 4769 desde una misma cuenta a muchos SPN es Kerberoasting en directo.
• Evento 4768 con Pre-Authentication Type: 0 registra AS-REP sin preauth.
• Herramientas como PingCastle detectan ambas configuraciones vulnerables.

Errores comunes#

• Cuentas de servicio con contraseñas de 8 caracteres «porque nadie las usa». Son el objetivo favorito.
• Dejar RC4 activo «por compatibilidad». Crackear RC4 es orden de magnitud más rápido que AES.
• Pensar que sin cuenta no hay riesgo. AS-REP Roasting solo necesita el nombre del usuario.
• No auditar los SPN. Cuentas huérfanas con SPN viejos siguen siendo kerberoasteables.
• Olvidar las variaciones. Una contraseña «Verano2024!» cae en el diccionario con reglas.

Preguntas frecuentes#

¿Kerberoasting requiere privilegios?#

No. Cualquier usuario autenticado del dominio puede pedir TGS para cualquier SPN registrado. Esa es precisamente la gracia del ataque.

¿Se puede detectar un Kerberoasting?#

Sí: el evento 4769 registra cada TGS emitido. Un volumen anormal de peticiones desde una cuenta es señal clara. Herramientas de SIEM lo detectan bien.

¿AS-REP Roasting siempre funciona?#

Solo contra cuentas con DONT_REQ_PREAUTH activa, que en entornos bien gestionados son muy pocas o ninguna.

¿Qué hago si cracke la contraseña?#

En una auditoría: documentar, demostrar impacto con un intento controlado y continuar la cadena. Nunca usar la credencial para acceder a datos reales sin autorización explícita.

¿Dónde practico?#

En los laboratorios enlazados al final de esta lección, que incluyen cuentas kerberoasteables con contraseñas débiles diseñadas para esta técnica.

Resumen#

• Kerberoasting: un usuario del dominio pide TGS para SPN, recibe tickets cifrados con la contraseña de la cuenta de servicio y los crackea sin conexión (hashcat 13100/19700).
• AS-REP Roasting: se aprovecha de cuentas con DONT_REQ_PREAUTH para recibir AS-REP crackeables sin ni siquiera tener que autenticarse (hashcat 18200).
• Ambos son sin conexión tras obtener los tickets, lo que los hace difíciles de detectar por tráfico.
• Se defienden con gMSA, contraseñas fuertes, AES, eliminando DONT_REQ_PREAUTH y Protected Users.
• La auditoría activa (eventos 4769 y 4768) permite detectarlos en tiempo real.

Fuentes y lecturas recomendadas#

• Impacket: GetUserSPNs, GetNPUsers
• Hashcat: modos 13100, 19700, 18200
• Microsoft: gMSA (Group Managed Service Accounts)
• MITRE ATT&CK T1558.003: Kerberoasting
• MITRE ATT&CK T1558.004: AS-REP Roasting