Kerberoasting

Kerberos emite un ticket de servicio a cualquier usuario autenticado del dominio que lo pida. Parte de ese ticket va cifrada con una clave derivada de la contraseña de la cuenta bajo la que corre el servicio, y por eso el ticket le sirve a un atacante: es un hash de contraseña que el dominio entrega a petición.

La secuencia es corta. El atacante enumera las cuentas que llevan un nombre principal de servicio, le pide al centro de distribución de claves un ticket de servicio para cada una, y guarda la porción cifrada. En la red no ocurre nada más. El crackeo se ejecuta offline, en el hardware del propio atacante, contra un diccionario. Si la contraseña de la cuenta es débil, cae; si es una cadena aleatoria larga, no.

Dos detalles deciden el resultado. El primero es el tipo de cifrado: un ticket emitido con el tipo heredado RC4 se rompe mucho más rápido que uno emitido con AES, y muchos dominios siguen permitiendo el tipo heredado por compatibilidad. El segundo es de quién es la cuenta. Una cuenta de servicio creada hace años por un administrador, con una contraseña elegida por una persona y nunca rotada, es la ganadora habitual.

La enumeración en sí es trivial, y conviene decírselo claramente al cliente. La lista de cuentas con nombre principal de servicio la puede leer de Active Directory cualquier usuario autenticado. No hace falta ningún privilegio para saber exactamente por qué cuentas merece la pena preguntar.

El fallo no está en Kerberos. Kerberos hace exactamente aquello para lo que se diseñó. El fallo es que las organizaciones crean cuentas de servicio igual que crean personas, con una contraseña que alguien tecleó, y después les conceden a esas cuentas mucho más de lo que necesitan.

En una prueba interna, esta suele ser la ruta más corta desde un usuario corriente hasta algo que importa. Nos autenticamos con una cuenta de dominio normal, pedimos todos los tickets de servicio a los que tenemos derecho, y crackeamos offline. La cuenta que cae rara vez es la que alguien vigilaba. Es un servicio de informes, un agente de copias o una tarea programada a la que se le dio pertenencia a un grupo privilegiado hace años porque era más rápido que averiguar los permisos correctos.

Esto sobrevive porque la petición en sí es legítima. No hay exploit, no hay malware y no se cruza ninguna frontera de privilegio en el momento de la petición. Los controles construidos alrededor de bloquear acciones malas no ven a un usuario pidiendo un ticket que tiene permitido pedir.

La segunda razón es que el crackeo es invisible. Ocurre en hardware que quien defiende no ve, a una velocidad en la que no puede influir, y sin más contacto con la red. Cuando la contraseña se usa, el evento que la produjo tiene ya varios días y está enterrado.

Los dos recuperan de Kerberos un bloque crackeable sin tocar la máquina objetivo, y se confunden a menudo. No son el mismo ataque y no tienen la misma corrección.

La consecuencia práctica: el AS-REP roasting es algo que un atacante puede intentar antes de tener ningún punto de apoyo, así que su sitio está en la conversación sobre acceso externo e inicial. El kerberoasting necesita antes un punto de apoyo, y por eso aparece a mitad de una prueba interna y no al principio.

Tratarlo como una vulnerabilidad de Kerberos que hay que parchear. No hay nada que parchear. La corrección es higiene de cuentas y política de cifrado.

Rotar la contraseña sin alargarla. Una contraseña nueva elegida por una persona se rompe igual de rápido que la anterior. Lo que cambia el resultado es la longitud y la aleatoriedad, no la frescura.

Forzar AES y parar ahí. AES hace el crackeo más lento, no imposible. Una contraseña corta bajo AES sigue siendo una contraseña corta.

Dar por hecho que se conocen todas las cuentas de servicio. Los nombres principales de servicio se acumulan. En casi todos los parques que probamos, la lista contiene entradas que nadie de los presentes sabe explicar.

Alertar sobre las peticiones de ticket en general. La actividad corriente genera un flujo continuo de ellas. La regla que funciona habla del patrón y no del evento, y una regla escrita solo contra el evento se desactiva en quince días por ruido.

Inventaría todas las cuentas con nombre principal de servicio y confirma que cada una sigue en uso. Pasa las cuentas que controlas a contraseñas gestionadas que sean largas, aleatorias y rotadas por el directorio en lugar de por una persona. Retira los nombres principales de servicio de las cuentas que ya no ejecutan ningún servicio. Deshabilita el tipo de cifrado heredado RC4 donde el parque lo aguante, y mide qué se rompe antes de hacerlo.

Después revisa la pertenencia a grupos: el daño de una cuenta de servicio rota lo decide por entero hasta dónde se le permitía llegar a esa cuenta, y ahí es donde el mínimo privilegio se gana el sueldo. Una cuenta de servicio con contraseña débil y sin privilegios es una observación. La misma contraseña en una cuenta de un grupo privilegiado es el encargo entero.

En cuanto a detección, la señal no es la petición de ticket en sí, sino el patrón: una cuenta pidiendo tickets de muchos servicios distintos en una ventana corta, y peticiones que especifican el tipo de cifrado heredado cuando el resto del parque ya ha pasado página. Una segunda señal, más barata, es una cuenta trampa: crea una cuenta con nombre principal de servicio, sin privilegios y sin ningún servicio real detrás, y alerta ante cualquier petición de ticket para ella. Nada legítimo pregunta nunca por ella.

En un informe interno, el kerberoasting rara vez aparece como hallazgo suelto. Aparece como un paso dentro de un camino de ataque, entre el acceso inicial al dominio y aquello que abrió la cuenta recuperada, y el hallazgo se escribe contra la cuenta, no contra Kerberos.

La evidencia que entregamos es la reproducción, no una captura de pantalla de una herramienta: el nombre de la cuenta y su nombre principal de servicio, el tipo de cifrado con el que se emitió el ticket, el hecho de que la contraseña se recuperó offline, y las pertenencias a grupos que hicieron que importara. La contraseña recuperada no se incluye en el cuerpo del informe.

La severidad se mueve con una sola pregunta: hasta dónde llegaba la cuenta. La misma técnica contra una cuenta olvidada y sin privilegios es una observación; contra una cuenta de un grupo privilegiado es el hallazgo alrededor del cual se construye el informe entero. Cuando la cuenta recuperada permitió además movimiento lateral hacia otro nivel, el camino se escribe paso a paso para que el cliente vea qué cambio aislado lo rompe.

Esto forma parte de lo que miramos en un pentesting ejecutado desde dentro de la red.

¿Sigue siendo relevante el kerberoasting? Sí. No necesita exploit ni software sin parchear, así que no envejece como envejece una vulnerabilidad. Deja de funcionar en un parque donde todas las cuentas de servicio tienen una contraseña gestionada, larga y aleatoria, cosa que todavía es poco común.

¿Hacen falta derechos de administrador para hacer kerberoasting? No. Cualquier cuenta autenticada del dominio puede pedir los tickets. Ese es todo el sentido de la técnica y la razón de que cueste distinguirla de la actividad normal.

¿AES detiene el kerberoasting? No. Ralentiza el crackeo offline de forma considerable, lo que encarece el ataque, pero una contraseña débil sigue cayendo. El tipo de cifrado y la fortaleza de la contraseña son dos controles distintos y hacen falta los dos.

¿En qué se diferencia del pass-the-hash? El kerberoasting recupera una contraseña rompiéndola offline. El pass-the-hash no recupera la contraseña en absoluto: reutiliza el hash directamente para autenticarse. Uno produce una credencial que puedes teclear; el otro reutiliza una credencial que no puedes leer.