Kerberoasting y AS-REP Roasting:

por qué una cuenta de servicio débil derrumba el dominio

Serie Red Team / Active Directory  |  unfantasmaenelsistema.com

En los artículos anteriores de esta serie quedó dibujado el mapa: Active Directory es un grafo de permisos y confianzas, y BloodHound sirve para ver por dónde se puede llegar de «un usuario cualquiera» a «Domain Admin». Kerberoasting es una de las aristas más repetidas de ese grafo, y tiene una particularidad incómoda: no explota ningún fallo de software. Explota una decisión de diseño de Kerberos de hace veinticinco años combinada con una contraseña que alguien puso en 2014 y nunca cambió.

Este artículo explica el mecanismo a alto nivel, por qué funciona, y —sobre todo— cómo se detecta y se mitiga en tu propio dominio. No es una guía de intrusión: no hay comandos de ataque paso a paso. El crackeo del ticket, que es un problema de fuerza bruta sobre GPU, ya se trató en el artículo de Hashcat y no se repite aquí.

1. Recordatorio rápido: cómo funciona Kerberos

Kerberos es el protocolo de autenticación por defecto en un dominio de Active Directory. La idea es evitar que la contraseña del usuario viaje una y otra vez por la red. En su lugar hay un intermediario de confianza —el KDC, que en la práctica es el controlador de dominio— que reparte tickets.

• Al iniciar sesión, el cliente pide un TGT (Ticket Granting Ticket) al KDC. Para probar que es quien dice, envía una marca de tiempo cifrada con una clave derivada de su contraseña: es la preautenticación.
• Con el TGT en mano, cuando el usuario quiere usar un servicio (un servidor SQL, un recurso compartido, una web interna) pide un TGS (Ticket Granting Service) para ese servicio concreto.
• El servicio se identifica por su SPN (Service Principal Name), una cadena como `MSSQLSvc/sql01.lab.local:1433` que asocia un servicio y un puerto a la cuenta que lo ejecuta.
• El KDC responde con el TGS. Parte de ese ticket va cifrada con la clave de la cuenta del servicio, para que solo ese servicio pueda leerlo al recibirlo.

Ese último punto es la clave de todo. La «clave de la cuenta del servicio» se deriva directamente de la contraseña de esa cuenta. Si la cuenta de servicio es una cuenta de usuario normal (`svc_sql`, `svc_backup`, `iis_app`…), su clave es una función de una contraseña que escribió una persona.

2. Kerberoasting: el ataque en una frase

Un atacante que ya tiene una cuenta de dominio cualquiera —no necesita ser administrador de nada— pide al KDC un TGS para un servicio con SPN. El KDC se lo entrega sin comprobar si esa cuenta tiene permiso real para usar el servicio: la autorización se supone que la hará el propio servicio más tarde. El atacante nunca contacta con el servicio. Se queda con el ticket, extrae la porción cifrada con la clave de la cuenta de servicio y se la lleva a otra máquina.

Fuera del dominio, sin hacer ruido y sin límite de intentos, prueba millones de contraseñas: para cada candidata deriva la clave, intenta descifrar el ticket y comprueba si el resultado tiene la estructura esperada. Cuando una funciona, ha recuperado la contraseña en claro de la cuenta de servicio. Si esa cuenta pertenece a un grupo con privilegios —y las cuentas de servicio históricas suelen estar en «Domain Admins» «por comodidad»— el dominio ha caído.

3. El papel del cifrado: RC4 frente a AES

No todos los tickets son igual de fáciles de atacar. El tipo de cifrado (`etype`) con el que el KDC protege el TGS determina cuánto cuesta el crackeo offline:

La diferencia es enorme. Con RC4, la clave es literalmente el hash NTLM: sin sal, sin estiramiento, idéntico al que se ataca en cualquier volcado de credenciales. Con AES, cada intento pasa por 4096 rondas de PBKDF2, lo que multiplica el tiempo por varios órdenes de magnitud. Por eso una de las mitigaciones más efectivas es forzar AES en las cuentas de servicio y, donde se pueda, deshabilitar RC4 en el dominio.

4. AS-REP Roasting: la variante que ni siquiera necesita una cuenta

AS-REP Roasting ataca el primer paso de Kerberos, el de la preautenticación. Normalmente, para pedir un TGT hay que demostrar que conoces la contraseña enviando esa marca de tiempo cifrada. Pero existe una opción en cada cuenta —»No requiere autenticación previa de Kerberos» (`DONT_REQ_PREAUTH` en `userAccountControl`)— que desactiva ese requisito.

Cuando una cuenta la tiene activada, cualquiera puede pedir un TGT para ella sin autenticarse en absoluto. El KDC responde con un AS-REP que contiene una porción cifrada con la clave del usuario. A partir de ahí, el ataque es idéntico: crackeo offline por diccionario y reglas. La diferencia es que el atacante no necesita ninguna credencial previa; le basta con conocer o adivinar nombres de cuenta.

La opción de saltarse la preautenticación suele aparecer por compatibilidad con sistemas antiguos (Unix con implementaciones de Kerberos limitadas, dispositivos heredados). Conviene auditarla periódicamente: casi nunca sigue siendo necesaria y casi nadie recuerda haberla puesto.

5. Detección: qué se ve en los logs

Kerberoasting deja rastro porque cada solicitud de ticket de servicio genera un evento en el controlador de dominio: el Event ID 4769 («Se solicitó un vale de servicio Kerberos»). El problema es que ese evento se genera también miles de veces al día por actividad legítima, así que la detección no es «ver un 4769» sino ver un patrón.

Una regla razonable para empezar en un SIEM: alertar cuando una misma cuenta origen genera solicitudes 4769 para más de N SPN distintos en una ventana corta, dando más peso a las que llegan con cifrado RC4. Es una heurística, no una firma perfecta, pero cubre el caso ruidoso, que es el más habitual con herramientas automáticas.

# Triaje rapido de 4769 con cifrado RC4 en un DC (lectura de eventos, no ataque)
Get-WinEvent -FilterHashtable @{ LogName='Security'; Id=4769 } |
  Where-Object { $_.Message -match 'Tipo de cifrado de vale:\s+0x17' -or
                 $_.Message -match 'Ticket Encryption Type:\s+0x17' } |
  ForEach-Object {
    $x = [xml]$_.ToXml()
    [pscustomobject]@{
      Hora        = $_.TimeCreated
      CuentaOrigen = ($x.Event.EventData.Data | ? Name -eq 'TargetUserName').'#text'
      SPN          = ($x.Event.EventData.Data | ? Name -eq 'ServiceName').'#text'
      IP           = ($x.Event.EventData.Data | ? Name -eq 'IpAddress').'#text'
    }
  } | Group-Object CuentaOrigen | Sort-Object Count -Descending |
  Select-Object Name, Count

6. Mitigación: cómo se cierra de verdad

6.1 gMSA: cuentas de servicio administradas por el dominio

La solución de fondo es no tener contraseñas humanas en las cuentas de servicio. Las gMSA (Group Managed Service Accounts) usan una contraseña de 240 bytes generada y rotada automáticamente por el propio dominio cada 30 días. Nadie la conoce, nadie la escribe y es imposible de crackear por fuerza bruta. Un ticket robado de una gMSA no lleva a ninguna parte. Migrar los servicios que lo soporten (SQL Server, IIS, tareas programadas, muchos servicios de terceros modernos) a gMSA elimina el problema de raíz para esas cuentas.

6.2 Para las cuentas de servicio que no pueden ser gMSA

• Contraseñas de 25+ caracteres, aleatorias, gestionadas en una bóveda. A partir de esa longitud y con suficiente entropía, el crackeo offline deja de ser viable aunque el ticket salga en RC4.
• Forzar AES en la cuenta (`msDS-SupportedEncryptionTypes` solo AES) y trabajar para deshabilitar RC4 en todo el dominio.
• Rotación periódica de esas contraseñas, idealmente automatizada.
• Mínimo de SPN: revisar el atributo `servicePrincipalName` de las cuentas de usuario. Cada SPN sobrante en una cuenta de persona es un objetivo gratis. Los SPN duplicados o huérfanos se eliminan.

6.3 Reducir el valor de lo que se pueda robar

• Sacar las cuentas de servicio de los grupos privilegiados. Una cuenta de servicio casi nunca necesita ser «Domain Admin»; necesita permisos concretos sobre recursos concretos. Este único cambio convierte muchos Kerberoasting exitosos en callejones sin salida.
• Protected Users para las cuentas de administración: los miembros de ese grupo no pueden usar RC4 ni DES y tienen otras protecciones de Kerberos. No es para las cuentas de servicio (rompe muchas), pero sí para los administradores.
• AS-REP: revisar que ninguna cuenta tenga la preautenticación deshabilitada salvo que sea absolutamente imprescindible, y en ese caso tratarla como una cuenta de servicio débil (contraseña larguísima).

7. Practicarlo en el laboratorio

Para entender el ataque y, sobre todo, para probar si tu detección funciona, hace falta un dominio de Active Directory de pruebas, aislado y sin salida a producción: un controlador de dominio y un cliente Windows en un rango 192.168.56.x, con un par de cuentas de servicio creadas a propósito (una con contraseña débil y RC4, otra con contraseña fuerte y AES) y una cuenta señuelo con su SPN.

• Genera actividad de solicitud de tickets desde el cliente con una cuenta de usuario normal del laboratorio y observa los Event ID 4769 que aparecen en el DC: fíjate en el tipo de cifrado y en el SPN de destino.
• Comprueba que tu regla de SIEM (o tu script de triaje) distingue el patrón ruidoso de la actividad normal de fondo.
• Verifica que la cuenta señuelo dispara la alerta al primer acceso.
• Cambia la cuenta de servicio débil por una gMSA y confirma que el ticket resultante ya no ofrece una vía de crackeo realista.
• El paso de crackeo offline, si quieres cerrar el círculo, se hace con las herramientas y el enfoque del artículo de Hashcat, siempre sobre los tickets de tus propias cuentas de laboratorio.

Conclusión

Kerberoasting no es un exploit: es la factura de una decisión cómoda. Cada cuenta de servicio con contraseña de diccionario, cada SPN puesto «para que funcione» en una cuenta de persona, cada cuenta de servicio metida en «Domain Admins» por no perder una tarde configurando permisos, es un ticket que el KDC entregará educadamente a cualquiera que lo pida y que se romperá en una GPU esa misma noche.

La defensa no pasa por un producto, sino por higiene: gMSA donde se pueda, contraseñas largas y aleatorias donde no, AES en lugar de RC4, cuentas de servicio con los permisos justos, una cuenta señuelo que avise, y una regla de correlación sobre el Event ID 4769. Ninguna de esas cosas se compra; todas se hacen. Y juntas convierten el ataque más fiable contra Active Directory en uno que hace ruido y no lleva a ningún sitio.

unfantasmaenelsistema.com | Seguridad, sistemas y todo lo que no debería funcionar (pero funciona)