En las auditorías de Active Directory, el Kerberoasting forma parte de los ataques que se comprueban sistemáticamente, ya que es una técnica eficaz, rápida y discreta. En pocos segundos, una simple cuenta de usuario sin ningún privilegio puede obtener lo necesario para crackear, fuera de línea y sin hacer ruido, las contraseñas de cuentas a veces muy poderosas. Este artículo detalla su funcionamiento, por qué tiene éxito tan a menudo y, sobre todo, cómo protegerse.
Un poco de Kerberos y de SPN
En un dominio Windows, la autenticación se basa en Kerberos, un protocolo fundamentado en tickets emitidos por el controlador de dominio. El principio se remonta a los años ochenta (el proyecto Athena del MIT), y Microsoft lo adoptó como mecanismo de autenticación por defecto desde Windows 2000. Cada servicio accesible mediante Kerberos se identifica con un SPN, por Service Principal Name, una etiqueta del tipo MSSQLSvc/serveur.entreprise.local:1433 que vincula un servicio (una base SQL, un servidor web, un recurso compartido) a una cuenta de servicio del directorio.
Como recordatorio, una cuenta de servicio es una cuenta de usuario dedicada a ejecutar una aplicación. Suele tener derechos elevados y su contraseña rara vez se cambia, porque modificarla puede interrumpir la aplicación que depende de ella. Es un secreto que envejece mal.
Por qué las cuentas de servicio son un imán tan potente
Estas cuentas concentran todos los defectos que busca un atacante. Se crearon hace tiempo, a menudo durante la instalación de un software, con una contraseña elegida a mano por un administrador con prisas. Esa contraseña no caduca nunca, por lo general, porque una caducidad supondría una caída de la aplicación. Y para colmo, estas cuentas acaban con frecuencia siendo miembros de grupos muy privilegiados, a veces Administradores del dominio, «el tiempo justo para que la aplicación funcione», y luego se olvida deshacer el cambio. Un atacante lo sabe y apunta prioritariamente a estos SPN.
El mecanismo del ataque
La clave cabe en una frase: cualquier usuario autenticado del dominio puede solicitar un ticket de servicio (un TGS, por Ticket-Granting Service) para cualquier SPN. Es un funcionamiento perfectamente normal de Kerberos, no una vulnerabilidad. Ahora bien, una parte de este ticket está cifrada con una clave derivada directamente de la contraseña de la cuenta de servicio. Al obtener el ticket se obtiene, por tanto, una muestra cifrada que puede atacarse con toda tranquilidad.
El atacante enumera los SPN del directorio, solicita los tickets correspondientes y los extrae. Con GetUserSPNs.py, de la suite Impacket, basta un solo comando desde Linux:
GetUserSPNs.py entreprise.local/utilisateur:MotDePasse -request -outputfile tickets.txtEn Windows, la herramienta Rubeus hace lo mismo desde un equipo ya comprometido y sabe seleccionar las cuentas más interesantes:
Rubeus.exe kerberoast /outfile:tickets.txtPunto crucial: en ningún momento el atacante necesita escribir en el controlador de dominio ni probar contraseñas contra él. Todo el cracking se realiza después en su propia máquina, fuera de línea. No hay, por tanto, ninguna cuenta bloqueada ni ningún pico de fallos de autenticación visible en los registros.
El cracking fuera de línea
Una vez obtenidos los tickets, el atacante los somete a una herramienta de cracking como hashcat. El formato Kerberos TGS corresponde al modo 13100:
hashcat -m 13100 tickets.txt dictionnaire.txt -r regles.ruleEl parámetro -r aplica un conjunto de reglas que reproduce los hábitos humanos: mayúscula inicial, número final, sustituciones clásicas. Frente a una contraseña débil del tipo Serveur2021, el resultado llega en pocos segundos en un simple portátil equipado con una tarjeta gráfica. Y ahí reside todo el problema:
- las cuentas de servicio suelen tener contraseñas cortas, elegidas por una persona hace años;
- casi nunca se renuevan;
- acumulan privilegios elevados, a veces hasta la administración completa del dominio.
Basta con crackear una sola contraseña débil para que el atacante herede directamente los derechos de la cuenta, sin exploit ni escalada de privilegios adicional. Es un atajo espectacular entre «soy un usuario cualquiera» y «controlo el directorio».
RC4, el combustible discreto del ataque
Un detalle técnico agrava a menudo la situación: por compatibilidad, muchos tickets siguen cifrándose con el algoritmo RC4, derivado del hash NTLM de la contraseña. Y RC4 se presta especialmente bien al cracking masivo. Forzar el uso de AES en las cuentas de servicio encarece notablemente el cracking. Las herramientas de ataque lo saben: Rubeus, por ejemplo, solicita de buen grado tickets en RC4 cuando están disponibles, precisamente porque son más fáciles de procesar.
Lo que revela el terreno
En una misión típica, la enumeración devuelve con regularidad varias decenas de SPN. Basta con que uno solo corresponda a una cuenta con una contraseña antigua para abrir una brecha. Las cuentas de copia de seguridad, de monitorización o de base de datos aparecen con frecuencia, a menudo con privilegios elevados y protegidas por una contraseña que retoma el nombre del fabricante del software seguido de un año. El impacto para el negocio es inmediato: quien controla una cuenta así controla la autenticación de toda la empresa. La BOX Oxyscan detecta precisamente estas cuentas de servicio expuestas al Kerberoasting en todo un directorio, lo que permite corregirlas antes de que un atacante las encuentre.
Corregir la vulnerabilidad: pasar a cuentas de servicio administradas
Dado que el Kerberoasting no explota un defecto de software sino la debilidad de una contraseña, la corrección consiste en hacer que esa contraseña sea imposible de crackear. Las cuentas de servicio administradas de grupo (gMSA, por group Managed Service Accounts) responden exactamente a esta necesidad: su contraseña la genera aleatoriamente el dominio, ocupa 240 bytes y se renueva automáticamente, sin ninguna intervención humana. Un atacante que obtenga un ticket cifrado con un secreto así puede dedicarle todas las tarjetas gráficas que quiera, no lo recuperará.
Como recordatorio, este es ya el comportamiento de las cuentas de equipo (aquellas cuyo nombre termina en $): su contraseña es aleatoria y muy larga, lo que las hace inmunes al Kerberoasting. La gMSA simplemente extiende este principio a las cuentas que ejecutan los servicios de aplicación.
La implantación se reduce a tres comandos de PowerShell en el controlador de dominio. Primero se genera, una sola vez para todo el dominio, la clave raíz del servicio de distribución de claves (KDS):
Add-KdsRootKey -EffectiveImmediatelyPese a su nombre, la opción -EffectiveImmediately solo hace utilizable la clave tras su replicación en todos los controladores de dominio, con un margen de seguridad que puede llegar a diez horas. Este plazo debe respetarse en producción. A continuación se crea la cuenta administrada, indicando su nombre DNS y el host o los hosts autorizados a recuperar su contraseña:
New-ADServiceAccount -Name sql-service -DNSHostName sql-service.exemple.local -PrincipalsAllowedToRetrieveManagedPassword "GRP-SRV-SQL$"Después se instala la cuenta en la máquina que ejecutará el servicio:
Install-ADServiceAccount sql-serviceSolo queda designar esta cuenta como identidad del servicio. En el administrador del servidor, se indica la cuenta administrada, reconocible por su sufijo $, como cuenta personalizada, en este caso para la identidad de un grupo de aplicaciones de IIS:
No todo el software es todavía capaz de funcionar con una gMSA. Para estos casos residuales, la regla es doble: una contraseña de al menos veinticinco caracteres, generada aleatoriamente y guardada en un almacén seguro, y el estricto respeto del mínimo privilegio, ya que una cuenta de servicio casi nunca necesita pertenecer a los administradores del dominio. Además, conviene forzar el cifrado AES de los tickets, mucho más costoso de crackear que el RC4 heredado, y vigilar las solicitudes anormalmente numerosas de tickets de servicio, a menudo la primera señal de una campaña de Kerberoasting en curso.
Conclusión
El Kerberoasting no explota un bug: explota una mala contraseña asignada a una cuenta demasiado poderosa. Por eso figura entre las técnicas más rentables para un atacante interno, y entre las más fáciles de descuidar en el lado de la defensa. La buena noticia es que las contramedidas son conocidas, están documentadas (en particular por MITRE y por la ANSSI) y son eficaces.
Recomendaciones: asignar a las cuentas de servicio contraseñas muy largas (25 caracteres o más) o, mejor aún, migrar a cuentas de servicio administradas de grupo (gMSA), cuya contraseña renueva automáticamente el dominio; aplicar el principio de mínimo privilegio (ninguna cuenta de servicio debería ser administradora del dominio sin una justificación sólida), forzar el cifrado AES en lugar de RC4 y vigilar las solicitudes masivas de tickets TGS, a menudo la primera señal de un ataque en curso.
Para saber más
- Consultoría y acompañamiento en ciberseguridad de Oxydian, para llevar a cabo el bastionado de un directorio (gMSA, cifrado AES, mínimo privilegio).
- Por qué las contraseñas corporativas caen en una auditoría, el artículo dedicado al cracking fuera de línea y a la higiene de los secretos.
- MITRE ATT&CK, técnica T1558.003 (Kerberoasting), descripción, detección y medidas de mitigación.
- ANSSI, recomendaciones de seguridad para un directorio Active Directory.
- Microsoft Learn, introducción a las cuentas de servicio administradas de grupo (gMSA).
- hashcat, la herramienta de referencia para el cracking fuera de línea (modo 13100 para los tickets Kerberos).
- Suite Impacket (GetUserSPNs.py), el conjunto de herramientas open source utilizado para la recogida de los tickets.
