El ataque Kerberoasting explicado: de un usuario de AD normal a Domain Admin

Entréganos una sola cuenta de dominio válida en casi cualquier red de Active Directory y hay muchas probabilidades de que salgamos con la contraseña de una cuenta de servicio antes de comer. Sin exploit. Sin malware. Sin derechos de administrador. Solo Kerberos haciendo exactamente aquello para lo que fue diseñado. Eso es un ataque Kerberoasting, y sigue siendo una de las rutas más fiables de un usuario corriente a Domain Admin con las que tropezamos en las pruebas internas.

Lo que lo hace obstinado es que no existe un parche para él. La debilidad es un montón de cuentas de servicio con contraseñas débiles, elegidas por personas y que nunca rotan, situadas tras un protocolo que entregará a cualquier usuario autenticado el material necesario para descifrarlas. Un ataque Kerberoasting es silencioso, paciente y casi por completo fuera de línea. Es justo esa combinación la que hace que los defensores lo sigan pasando por alto.

A continuación repasamos cómo funcionan los tickets de servicio de Kerberos, por qué un Service Principal Name (SPN) pone a las cuentas de servicio en el punto de mira, cómo se encadena el ataque hacia el dominio total y las mitigaciones que de verdad sobreviven al contacto con producción. La técnica se corresponde con MITRE ATT&CK T1558.003.

Puntos clave

• Un ataque Kerberoasting permite que cualquier usuario de dominio autenticado solicite tickets de servicio de Kerberos para las cuentas que tienen un SPN y luego descifre esos tickets fuera de línea para recuperar la contraseña en texto claro. No se requieren privilegios elevados.
• El ticket se cifra con una clave derivada de la contraseña de la cuenta de servicio, por lo que las contraseñas débiles o caducadas caen rápido ante hashcat, sobre todo cuando aún se permite RC4 (tipo de cifrado 0x17).
• Las cuentas de servicio suelen tener privilegios excesivos, así que una sola contraseña descifrada a menudo significa administrador local en muchos hosts, acceso a datos sensibles o un camino directo a Domain Admin.
• La detección se apoya en las anomalías del evento 4769 de Kerberos (solicitudes RC4, volumen elevado desde un único usuario) y en cuentas SPN señuelo que ningún servicio real debería consultar jamás.
• La solución duradera son las group Managed Service Accounts (gMSA) o contraseñas aleatorias de 25 caracteres o más, la imposición de AES, la poda de SPN sin uso y el mínimo privilegio respaldado por una segmentación de administradores (admin tiering).

¿Qué es un ataque Kerberoasting?

Un ataque Kerberoasting es una técnica de descifrado de contraseñas fuera de línea dirigida a las cuentas de servicio de Active Directory. Cualquier usuario de dominio puede pedir a un Domain Controller un ticket de servicio para cualquier cuenta que tenga un SPN registrado. Parte de ese ticket se cifra con una clave derivada de la contraseña de la cuenta de servicio. El atacante toma el ticket, se marcha y descifra la contraseña por fuerza bruta en su propio equipo, sin volver a tocar el Domain Controller.

El peligro está en la asimetría. Solicitar un ticket es una acción normal que cada estación de trabajo realiza cientos de veces al día, así que se funde con el ruido. El descifrado ocurre en el hardware del atacante, invisible para tus registros. Y las cuentas con más probabilidad de portar un SPN, como SQL Server, los grupos de aplicaciones de IIS y varios servicios HTTP o MSSQL, suelen ser las que tienen el acceso más amplio y las contraseñas más antiguas. Esa es la peor combinación posible.

¿Cómo funcionan en realidad los tickets de servicio de Kerberos?

La autenticación de Kerberos tiene tres piezas móviles: el cliente, el Key Distribution Center (KDC, que reside en cada Domain Controller) y el servicio de destino. Cuando inicias sesión, el cliente envía un AS-REQ y recibe de vuelta un Ticket Granting Ticket (TGT) en el AS-REP. El TGT es la prueba de quién eres.

Cuando quieres alcanzar un servicio, el cliente presenta ese TGT y envía un TGS-REQ que nombra el SPN, por ejemplo MSSQLSvc/db01.acme-corp.local:1433. El KDC responde con un TGS-REP que contiene un ticket de servicio. Aquí está el detalle que importa: el ticket se cifra con la clave de largo plazo de la cuenta propietaria del SPN. Para RC4, esa clave es literalmente el hash NT de la cuenta. Para AES, es una clave derivada de la contraseña y una sal.

Ahora la parte que los atacantes adoran. El KDC nunca comprueba si de verdad tienes permiso para usar el servicio. Solo verifica que posees un TGT válido y entonces devuelve un ticket cifrado con la clave de la cuenta de servicio. La autorización ocurre después, en el propio servicio. Así que el KDC le dará de buena gana a cualquier usuario autenticado un blob cifrado derivado de la contraseña de cualquier cuenta de servicio. Solo hay que pedirlo con educación, y dice que sí.

¿Qué es un SPN y por qué las cuentas de servicio son el objetivo?

Un Service Principal Name es una cadena única que vincula una instancia de servicio con la cuenta que la ejecuta, para que Kerberos sepa qué clave usar al cifrar el ticket. Las cuentas de equipo también tienen SPN, pero sus contraseñas son largas cadenas aleatorias que rotan por sí solas, lo que las hace prácticamente indescifrables. Los objetivos blandos son las cuentas de usuario con SPN: las cuentas de servicio del dominio que un humano creó y configuró a mano.

Ahí es donde se acumula el riesgo. En nuestros trabajos encontramos con regularidad cuentas de servicio con contraseñas fijadas hace cinco años o más, elegidas por un administrador que quería algo que pudiera recordar y reutilizadas con frecuencia entre entornos. Las excepciones a la política de contraseñas son aquí la norma, porque “la aplicación se rompe si la contraseña rota.” Encontrar estas cuentas es trivial para cualquier miembro del dominio, ya que los SPN son atributos de directorio legibles. Una sola línea los saca a la luz:

# Native, no tooling required
setspn -Q */*

# Impacket, from a non-domain-joined attacker box
GetUserSPNs.py acme-corp.local/lowpriv:'Password123' -dc-ip 10.0.0.10 -request

# Or on-host with Rubeus
Rubeus.exe kerberoast /outfile:hashes.txt

¿Cómo funciona el ataque Kerberoasting paso a paso?

El ataque es corto y no necesita más que una cuenta de dominio operativa. Enumerar las cuentas que tienen un SPN, solicitar un TGS para cada una, extraer la porción cifrada de cada ticket y luego descifrarla fuera de línea. Cuatro movimientos, y solo los dos primeros tocan la red.

La fase de solicitud es donde Rubeus y el GetUserSPNs de Impacket hacen su trabajo. Consultan el directorio en busca de objetos de usuario con el atributo servicePrincipalName establecido, disparan un TGS-REQ por cada uno y dan formato a los tickets devueltos como cadenas listas para hashcat. La mayoría de las herramientas también te dejan forzar RC4 para recuperar el tipo de hash más rápido, que es precisamente el comportamiento que un defensor puede vigilar. Un hash Kerberoast de RC4 empieza por $krb5tgs$23$; AES256 vuelve como $krb5tgs$18$.

La fase de descifrado es puro cálculo fuera de línea. Los tickets RC4 usan el modo 13100 de hashcat. Los tickets AES son más lentos, pero aun así se desmoronan ante una lista de palabras decente, con los modos 19600 (AES128) y 19700 (AES256).

# RC4 (etype 23 / 0x17) - fastest to crack
hashcat -m 13100 hashes.txt rockyou.txt -r rules/best64.rule

# AES256 (etype 18) - slower, still viable against weak passwords
hashcat -m 19700 hashes.txt rockyou.txt

Ten en cuenta que nada vuelve a contactar con el Domain Controller mientras corre el descifrado. Una vez capturados los tickets, el atacante puede desenchufar el cable de red y seguir triturando. Una contraseña corta o basada en un diccionario puede caer en minutos. Por eso la fortaleza de la contraseña de la cuenta de servicio lo es todo.

¿Por qué las contraseñas débiles de cuentas de servicio hacen esto tan letal?

Porque toda la defensa del ticket cifrado descansa en la entropía de la contraseña, y en nada más. Kerberos no limita el ritmo de los intentos fuera de línea. No hay bloqueo de cuenta. No hay ninguna alerta una vez que el ticket abandona el KDC. Una contraseña de diez caracteres construida con una palabra de diccionario y dos dígitos no es un badén frente a una GPU moderna. Una contraseña genuinamente aleatoria de 25 caracteres es un muro de ladrillo.

La reutilización y el envejecimiento lo empeoran. Las contraseñas de las cuentas de servicio casi nunca cambian, así que una que descifres hoy puede haber sido válida durante años, y válida a la vez en pruebas, preproducción y producción. Hemos visto cómo una sola cuenta descifrada abría decenas de servidores simplemente porque se había añadido al grupo de Administradores local de cada máquina en la que se ejecutaba.

¿Cómo se encadena Kerberoasting hacia Domain Admin?

Descifrar la contraseña es el punto de giro, no la meta. Lo que viene después depende de cuán privilegiada sea la cuenta, y las cuentas de servicio son famosas por la acumulación de privilegios. Las cadenas que vemos con más frecuencia son así:

• La cuenta es administrador local en muchos hosts, así que obtenemos ejecución de código y volcamos más credenciales de LSASS en cada uno, recogiendo por el camino sesiones de administrador de dominio en caché.
• La cuenta se añadió directamente a Domain Admins o a un grupo igual de poderoso, normalmente “por ahora” durante una migración, y luego nunca se quitó. Ese es todo el trabajo resumido en una línea.
• La cuenta posee derechos de directorio peligrosos, como la capacidad de restablecer las contraseñas de otros usuarios o de escribir la pertenencia a un grupo, que BloodHound dibujará como un camino hacia el Tier 0.

La cuestión es que un ataque Kerberoasting rara vez termina en una sola cuenta. Es un punto de apoyo que se convierte en movimiento lateral y luego en escalada de privilegios, y los caminos más cortos a Domain Admin son casi siempre los que nadie sabía que existían. BloodHound hace que esos caminos sean rápidos de encontrar, para el atacante y para ti.

¿Cómo se detecta un ataque Kerberoasting?

La detección se centra en las solicitudes de tickets de servicio de Kerberos, registradas como evento 4769 en los Domain Controllers. Por sí solas, esas entradas son puro ruido. La señal está en la forma. Vigila una cuenta de usuario que solicite tickets para un gran número de SPN distintos en una ventana de tiempo ajustada, y especialmente las solicitudes que especifican RC4 (tipo de cifrado de ticket 0x17) en un entorno que debería funcionar con AES. Los clientes modernos negocian AES de manera predeterminada, así que una ráfaga de solicitudes RC4 es una huella clásica de Kerberoasting.

El control de mayor señal que recomendamos es un SPN señuelo. Levanta una cuenta de usuario cebo, adjúntale un SPN que no corresponda a ningún servicio real, dale una contraseña larga y aleatoria y no la toques jamás. Ningún proceso legítimo debería solicitar nunca su ticket, así que un único 4769 que nombre esa cuenta es un indicador de intrusión casi seguro, con apenas falsos positivos. Combínalo con alertas sobre volúmenes anómalos de RC4 y atraparás la mayoría del roasting oportunista antes incluso de que termine el descifrado.

¿Cómo se previene Kerberoasting?

La prevención se reduce a eliminar los dos ingredientes: contraseñas débiles y exposición innecesaria. Por orden de prioridad, esto es lo que aconsejamos hacer a los clientes.

• Cámbiate a gMSA. Las Group Managed Service Accounts reciben contraseñas largas y aleatorias que el dominio rota por su cuenta, de modo que sus tickets son prácticamente indescifrables. Migra cada cuenta de servicio que pueda soportar una.
• Usa contraseñas largas y aleatorias donde las gMSA no encajen. Para las cuentas que deban seguir siendo objetos de usuario estándar, establece una contraseña aleatoria de 25 caracteres o más. A esa longitud, ni siquiera un ticket RC4 merece la pena descifrar.
• Impón AES y retira RC4. Configura msDS-SupportedEncryptionTypes solo en AES y elimina RC4 en todo el dominio. Ralentiza cualquier intento de descifrado y convierte cada solicitud RC4 restante en una señal de detección limpia.
• Aplica el mínimo privilegio. Saca las cuentas de servicio de Domain Admins y de otros grupos de Tier 0, concede solo los derechos que el servicio necesita de verdad y audita la pertenencia a los grupos de administrador local.
• Poda los SPN obsoletos. Cada SPN en una cuenta de usuario es superficie de ataque. Retira los SPN de las cuentas que ya no ejecutan ese servicio.
• Adopta una segmentación de administradores. Aísla las identidades de Tier 0 para que una cuenta de servicio de aplicación descifrada nunca pueda llegar, de entrada, a los controladores de dominio ni a las credenciales de administrador de dominio.

Cómo ayuda CyberXplore

Kerberoasting es una de las primeras cosas a las que recurre nuestro equipo en cualquier trabajo interno, porque es rápido, silencioso y funciona muy a menudo. Nuestra evaluación de seguridad de Active Directory traza tus rutas de ataque reales como lo haría un intruso: enumerando SPN, probando la fortaleza de las contraseñas de las cuentas de servicio y siguiendo cada cadena que acaba en Domain Admin, para luego entregarte una lista de correcciones priorizada construida en torno a gMSA, la imposición de AES y la segmentación. Si quieres saber si un solo usuario víctima de phishing podría adueñarse de todo tu dominio, pide un presupuesto y te mostraremos exactamente hasta dónde llega.

FAQ

¿Necesita un ataque Kerberoasting privilegios de administrador?

No, y por eso está en todas partes. Cualquier cuenta de dominio autenticada, incluido un usuario con pocos privilegios o un servicio comprometido, puede enumerar SPN y solicitar tickets de servicio. El KDC no comprueba la autorización antes de emitir el ticket, así que no hacen falta derechos especiales para marcharse con material descifrable.

¿Cambiar a AES detiene Kerberoasting por completo?

No, pero ayuda mucho. Los tickets AES son mucho más lentos de descifrar que los de RC4, así que una contraseña fuerte tras AES está prácticamente a salvo. Dicho esto, una contraseña débil tras AES todavía puede caer, de modo que AES no sustituye a las contraseñas largas y aleatorias ni a las gMSA. Imponerlo también convierte cualquier solicitud RC4 sobrante en una señal de detección útil.

¿Cuánto se tarda en descifrar un hash de Kerberoast?

Depende por completo de la fortaleza de la contraseña y del tipo de cifrado. Un ticket RC4 débil basado en una palabra de diccionario puede caer en segundos o minutos con una GPU moderna. Una contraseña genuinamente aleatoria de 25 caracteres, o una contraseña de gMSA, no se descifrará en ningún plazo realista. No hay bloqueo del lado del servidor que frene al atacante, así que la entropía es la única defensa que cuenta.

¿Cuál es la diferencia entre Kerberoasting y AS-REP roasting?

Ambos descifran material de Kerberos fuera de línea, pero golpean cosas distintas. Kerberoasting (T1558.003) ataca las cuentas de servicio con SPN descifrando tickets de servicio. El AS-REP roasting (T1558.004) apunta a cuentas que tienen desactivada la preautenticación de Kerberos y descifra el AS-REP en su lugar. El AS-REP roasting puede hacerse sin ninguna credencial válida, siempre que conozcas un nombre de usuario objetivo.

¿Son las gMSA realmente inmunes a Kerberoasting?

A efectos prácticos, sí. Una contraseña de gMSA es un valor largo y aleatorio que el dominio rota automáticamente, de modo que, aunque su ticket pueda solicitarse y capturarse, descifrarlo es inviable. La única salvedad: cualquiera al que se le conceda el derecho de leer la contraseña gestionada de la gMSA puede recuperarla directamente, así que protege ese permiso con cuidado.

¿Cómo puedo comprobar si mi dominio es vulnerable?

Ejecuta una enumeración controlada de las cuentas con SPN y evalúa la fortaleza de sus contraseñas, idealmente como parte de una evaluación completa de Active Directory. El GetUserSPNs de Impacket o Rubeus sacarán a la luz cada cuenta susceptible de roasting, y los SPN señuelo junto con la supervisión del evento 4769 te dirán si ya hay intentos en marcha. Hacerlo como un ejercicio autorizado te da la misma visión que obtiene un atacante, antes de que él la tome.