Kerberoasting es una técnica de ataque a Active Directory que permite a un atacante con acceso básico al dominio extraer y crackear contraseñas de cuentas de servicio. No necesita privilegios de administrador. No explota ningún bug. Simplemente abusa de cómo funciona el protocolo Kerberos por diseño. Un kerberos hack limpio, elegante y devastador que se aprovecha de los SPN (Service Principal Names) para solicitar tickets de servicio cifrados con la contraseña de la cuenta objetivo. Si esa contraseña es débil —y suelen serlo—, el atacante la obtiene en minutos.
Y lo peor: tu SIEM probablemente ni se entere. Porque solicitar un ticket de servicio es una operación completamente legítima dentro de Kerberos. El atacante no dispara ninguna alarma. Solo pide educadamente lo que el protocolo le ofrece.
Cómo funciona Kerberoasting paso a paso
Para entender el ataque SPN, primero hay que entender qué hace Kerberos. Kerberos es el protocolo de autenticación por defecto en entornos Windows Active Directory desde Windows 2000. Funciona mediante tickets: el usuario se autentica contra el KDC (Key Distribution Center), obtiene un TGT (Ticket Granting Ticket) y luego solicita tickets TGS (Ticket Granting Service) para acceder a servicios específicos.
Aquí está la trampa. Cuando solicitas un ticket TGS para un servicio, el KDC lo cifra con el hash NTLM de la cuenta de servicio asociada a ese SPN. Y te lo entrega sin verificar si realmente vas a usar ese servicio. Es como si un hotel te diera la llave de cualquier habitación solo porque has hecho check-in.
El flujo del ataque es este:
- Reconocimiento: el atacante enumera todos los SPN registrados en el dominio. Cualquier usuario autenticado puede hacerlo con una simple consulta LDAP.
- Solicitud de tickets: pide tickets TGS para las cuentas de servicio identificadas. Operación 100% legítima dentro del protocolo Kerberos.
- Extracción offline: exporta los tickets TGS, que contienen datos cifrados con el hash de la contraseña de la cuenta de servicio.
- Cracking offline: usa herramientas como Hashcat o John the Ripper para romper el cifrado por fuerza bruta. Sin generar tráfico de red. Sin bloqueos de cuenta.
Si la cuenta de servicio tiene una contraseña tipo Summer2024! o ServiceAccount1, el atacante la tendrá en cuestión de segundos. Con una GPU moderna, Hashcat procesa millones de combinaciones por segundo contra el cifrado RC4-HMAC que muchos entornos todavía usan.
Herramientas reales que usan los atacantes (y los pentesters)
El ecosistema de herramientas para ejecutar un kerberoasting es amplio y maduro. Estas son las más utilizadas en auditorías reales y, por tanto, las que los atacantes también emplean:
- Impacket (GetUserSPNs.py): la navaja suiza de los ataques a Active Directory. Permite enumerar SPNs y solicitar tickets TGS desde una máquina Linux sin estar unida al dominio. Solo necesitas credenciales válidas de cualquier usuario del dominio.
- Rubeus: herramienta en C# diseñada para operar directamente en memoria dentro de un equipo Windows unido al dominio. Su módulo
kerberoastpermite filtrar por cuentas con privilegios elevados. - PowerView (PowerSploit): módulo PowerShell que facilita la enumeración de SPNs con
Get-DomainUser -SPN. - Hashcat (modo 13100 para RC4, 19700 para AES): el estándar para cracking offline de tickets Kerberos.
Un comando típico con Impacket sería algo tan simple como:
GetUserSPNs.py dominio.local/usuario:password -request -outputfile tickets.txt
Eso es todo. Con una línea, tienes los hashes listos para crackear. El ataque completo, desde el acceso inicial hasta la obtención de credenciales de servicio, puede ejecutarse en menos de cinco minutos. Si alguna vez te has preguntado cómo funcionan los exploits zero-day, Kerberoasting es casi lo contrario: no explota ninguna vulnerabilidad, sino el funcionamiento normal del sistema.
Por qué las cuentas de servicio son el eslabón débil
Las cuentas de servicio en Active Directory suelen ser un desastre de seguridad. Y no por negligencia individual, sino por problemas estructurales que se repiten en la mayoría de organizaciones.
Primer problema: contraseñas estáticas. Muchas cuentas de servicio llevan la misma contraseña desde que se configuraron hace años. Nadie se atreve a cambiarla porque "si toco eso se rompe todo". Es el clásico miedo que paraliza a los equipos de sistemas.
Segundo problema: privilegios excesivos. Las cuentas de servicio frecuentemente son miembros de Domain Admins o tienen permisos equivalentes. Se configuraron así "provisionalmente" durante una implementación y nadie revisó después. Un atacante que crackea una de estas cuentas obtiene acceso total al dominio.
Tercer problema: cifrado débil. Muchos entornos todavía permiten el cifrado RC4-HMAC (también conocido como etype 23) en tickets Kerberos. RC4 es significativamente más rápido de crackear que AES-256. Microsoft lo considera obsoleto desde hace años, pero sigue habilitado por compatibilidad con sistemas legacy.
Si quieres entender cómo los atacantes escalan desde un acceso inicial hasta el control total, el patrón es similar al que siguen los grupos de Ransomware as a Service: primero comprometen un usuario básico, luego se mueven lateralmente usando técnicas como Kerberoasting hasta alcanzar cuentas privilegiadas.
Casos reales y contexto del ataque
Kerberoasting no es un ataque teórico de laboratorio. Es una técnica documentada en el framework MITRE ATT&CK como T1558.003 y aparece consistentemente en informes de incidentes reales.
El grupo APT29 (Cozy Bear, vinculado a servicios de inteligencia rusos) ha utilizado variantes de este kerberos hack en campañas contra organizaciones gubernamentales y del sector privado. El grupo FIN7, especializado en ataques financieros, también incluye Kerberoasting en su arsenal para escalar privilegios dentro de redes corporativas comprometidas.
En 2022, el equipo de respuesta a incidentes de CrowdStrike reportó que Kerberoasting estaba presente en una proporción significativa de las intrusiones que investigaron en entornos Active Directory. La técnica se ha convertido en un paso casi estándar dentro de la cadena de ataque post-compromiso.
Y no hace falta ser un APT sofisticado. Cualquier pentester junior con acceso a un tutorial de YouTube y cinco minutos puede ejecutar un ataque a Active Directory con Kerberoasting. La barrera de entrada es absurdamente baja para el impacto que tiene.
Cómo proteger tu Active Directory contra Kerberoasting
La buena noticia: defenderse es posible. La mala: requiere disciplina y cambios que muchos equipos de IT llevan posponiendo años. Estas son las medidas concretas, ordenadas por impacto.
1. Contraseñas de servicio de mínimo 25 caracteres. Un ticket cifrado con una contraseña de 25+ caracteres aleatorios es prácticamente imposible de crackear con tecnología actual. Genera contraseñas con un gestor y guárdalas en un vault como CyberArk, HashiCorp Vault o Azure Key Vault.
2. Usa Group Managed Service Accounts (gMSA). Microsoft introdujo las gMSA precisamente para resolver el problema de las cuentas de servicio con contraseñas estáticas. Las gMSA rotan automáticamente su contraseña (de 120 caracteres aleatorios, 240 bytes) cada 30 días. No hay excusa para no usarlas en servicios compatibles.
3. Desactiva RC4-HMAC. Fuerza el uso de AES (etype 17 para AES-128, etype 18 para AES-256) en tu dominio. AES es órdenes de magnitud más lento de crackear. Revisa qué servicios todavía dependen de RC4 con:
Get-ADUser -Filter {ServicePrincipalName -ne "$null"} -Properties msDS-SupportedEncryptionTypes
4. Monitoriza solicitudes TGS anómalas. Configura alertas para el Event ID 4769 en tus Domain Controllers. Un usuario que solicita tickets TGS para múltiples servicios en un periodo corto es sospechoso. Herramientas como Microsoft Defender for Identity (antes Azure ATP) detectan patrones de Kerberoasting automáticamente.
5. Aplica el principio de mínimo privilegio. Revisa todas las cuentas con SPN registrado. ¿Realmente necesitan ser Domain Admin? Seguramente no. Reduce privilegios al mínimo necesario para que el servicio funcione.
Para proteger la infraestructura de red de tu empresa a otro nivel, también conviene implementar DNS cifrado, que dificulta el reconocimiento previo al ataque.
Kerberoasting vs. AS-REP Roasting: diferencias clave
A menudo se confunden estas dos técnicas. Ambas atacan Kerberos, pero de forma distinta:
| Característica | Kerberoasting | AS-REP Roasting |
|---|---|---|
| Objetivo | Cuentas con SPN registrado | Cuentas con pre-autenticación Kerberos desactivada |
| Ticket atacado | TGS (Ticket Granting Service) | AS-REP (Authentication Service Response) |
| Requisitos | Cualquier usuario autenticado del dominio | No requiere autenticación previa |
| MITRE ATT&CK | T1558.003 | T1558.004 |
| Herramienta típica | GetUserSPNs.py / Rubeus kerberoast | GetNPUsers.py / Rubeus asreproast |
AS-REP Roasting es menos común porque requiere una configuración específica (DONT_REQUIRE_PREAUTH), pero cuando existe, es incluso más fácil de explotar que el ataque SPN clásico.
Preguntas frecuentes
¿Kerberoasting requiere privilegios de administrador?
No. Cualquier usuario autenticado del dominio puede solicitar tickets TGS para cualquier servicio registrado con un SPN. Esa es precisamente la razón por la que este ataque a Active Directory es tan peligroso: la barrera de entrada es mínima.
¿Se puede detectar un ataque de Kerberoasting en tiempo real?
Sí, aunque no es trivial. Monitoriza el Event ID 4769 en los Domain Controllers y busca patrones anómalos: múltiples solicitudes TGS desde un mismo usuario en poco tiempo, especialmente con cifrado RC4. Microsoft Defender for Identity y soluciones SIEM como Splunk o Elastic Security tienen reglas predefinidas para detectar este patrón.
¿Qué diferencia hay entre Kerberoasting y Pass-the-Ticket?
Kerberoasting extrae tickets para crackear contraseñas offline. Pass-the-Ticket roba tickets ya generados para suplantar la identidad del usuario. Son técnicas complementarias: un atacante podría usar Kerberoasting para obtener credenciales y luego Pass-the-Ticket para moverse lateralmente.
¿Las Group Managed Service Accounts eliminan completamente el riesgo?
Reducen el riesgo drásticamente, pero no al 100%. Las gMSA generan contraseñas de 120 caracteres aleatorios (240 bytes) que rotan cada 30 días, lo que hace el cracking offline inviable con tecnología actual. Sin embargo, servicios legacy que no soportan gMSA seguirán necesitando cuentas de servicio tradicionales.
El siguiente paso
Abre una consola PowerShell en tu Domain Controller y ejecuta Get-ADUser -Filter {ServicePrincipalName -ne "$null"} -Properties ServicePrincipalName, PasswordLastSet | Select Name, PasswordLastSet. Eso te dará la lista de todas las cuentas con SPN y cuándo se cambió su contraseña por última vez. Si ves fechas de hace más de un año, ya sabes por dónde empezar. Migra esas cuentas a gMSA, establece contraseñas de 25+ caracteres para las que no puedas migrar, y desactiva RC4. Tu Active Directory te lo agradecerá.
