5 - Kerberoasting
Kerberos está diseñado para manejar la autenticación de usuarios, no la autorización, y esta limitación es lo que hace posible ataques como el Kerberoasting.
Este ataque se basa durante la solicitud KRB_TGS_REP, cuyo mensaje se compone de los siguientes elementos:
En un entorno Kerberos, cualquier usuario autenticado en el dominio puede solicitar un Ticket Granting Service (TGS) para cualquier servicio registrado con un SPN, sin que el controlador de dominio verifique si ese usuario tiene permiso para acceder al recurso. Esto se debe a que la función del controlador de dominio es únicamente autenticar al usuario y emitir un TGS que contiene el Privilege Attribute Certificate (PAC), el cual incluye información de seguridad como grupos y SID. Sin embargo, este diseño tiene una implicancia crítica: si el SPN está vinculado a una cuenta de usuario (en lugar de una cuenta de máquina), el ticket entregado se cifra con la clave derivada de la contraseña de esa cuenta, permitiendo que un atacante lo capture y realice un ataque offline para obtener el hash NTLM y crackearlo. Esta separación entre autenticación y autorización, sumada a la falta de verificación previa de acceso, es lo que habilita ataques como el Kerberoasting.
¿Qué es Kerberoasting?
Kerberoasting es una técnica que le permite al atacante obtener TGS cifrados con la clave del servicio, para luego intentar romper esa clave mediante ataques de fuerza bruta offline.
El ataque se basa en que los TGS están cifrados con una clave derivada del hash NTLM del propietario del servicio (cuenta de usuario o de máquina). Aunque las cuentas de máquina suelen tener contraseñas robustas y aleatorias (por lo que son difíciles de crackear), algunos servicios están asociados a cuentas de usuario, que pueden tener contraseñas débiles o reutilizadas.
Dado que Kerberos no válida privilegios en la emisión de TGS, cualquier usuario autenticado en el dominio puede solicitar un TGS para cualquier servicio. El atacante puede luego extraer los tickets del caché local y usar herramientas como impacket-GetUserSPNs para formatearlos como hashes crackeables (tipo 23).
Esta técnica es especialmente peligrosa cuando las cuentas de servicio con SPN están vinculadas a usuarios con privilegios elevados.
¿Cómo podríamos explotar este tipo de vulnerabilidades?
Ejemplo Practico 1
Si disponemos de las credenciales válidas de una cuenta del dominio —por ejemplo, SVC_TGS:GPPstillStandingStrong2k18— y dicha cuenta tiene permisos para acceder al servicio LDAP, podemos utilizarla para enumerar cuentas de usuario que tengan un Service Principal Name (SPN) configurado. Estas cuentas, al estar asociadas a un SPN, permiten que se les solicite un Ticket de Servicio (TGS). El TGS se cifra utilizando la clave derivada del hash NTLM de la cuenta de servicio asociada al SPN. Si esta cuenta tiene privilegios elevados y utiliza una contraseña débil, es posible extraer el ticket, crackearlo offline y recuperar las credenciales en texto claro, lo cual puede otorgar acceso a servicios críticos dentro del dominio. Este es el principio detrás del ataque conocido como Kerberoasting. Para ilustrar esta primera parte vamos a tomar como ejemplo el siguiente comando de la herramienta impacket-GetUserSPNs y su resultado:
En este caso, la herramienta impacket-GetUserSPNs aprovecha el hecho de que la cuenta que tenemos tiene permisos para consultar, a través de LDAP, qué cuentas de usuario tienen configurado un Service Principal Name (SPN). Una vez identificadas, la herramienta solicita un Ticket de Servicio (TGS) para cada SPN. El KDC emite este ticket cifrado con una clave derivada del hash NTLM de la cuenta asociada al SPN, sin verificar si el solicitante tiene acceso real al servicio. Luego, la herramienta guarda ese TGS en un formato que puede ser crackeado offline. Si la cuenta de servicio tiene una contraseña débil, es posible recuperar sus credenciales en texto claro usando herramientas como hashcat o johntheripper. En el ejemplo, se solicita un TGS para el SPN asociado a la cuenta Administrator, y se obtiene un hash Kerberos ($krb5tgs$...) listo para atacar mediante fuerza bruta o diccionario como veremos en el siguiente paso:
La vulnerabilidad principal que nos permite implementar fuerza bruta con exito, reside en el uso de RC4-HMAC debido a su debilidad criptográfica comparado con algoritmos más modernos, como AES-128 o AES-256 (identificados como tipo 17 y tipo 18 respectivamente). Aunque en entornos más actualizados se recomienda migrar a estos algoritmos más robustos, RC4-HMAC sigue siendo ampliamente utilizado por razones de compatibilidad y por la permanencia de configuraciones heredadas. Esto lo convierte en un potencial objetivo a la hora de testear este tipo de vulnerabilidades. RC4-HMAC es uno de los algoritmos de cifrado utilizados por el protocolo Kerberos para proteger los tickets de autenticación. Específicamente, es un algoritmo de cifrado de flujo que combina el cifrado RC4 con un mecanismo de integridad basado en HMAC (Hash-based Message Authentication Code). Dentro del protocolo Kerberos, este algoritmo es identificado como el "tipo 23", lo cual simplemente representa su valor numérico en la especificación del protocolo.
Ejemplo Practico 2
Una vez que logramos acceso a un equipo Windows dentro del dominio —por ejemplo, comprometiendo una cuenta privilegiada o explotando una vulnerabilidad local— es posible ejecutar un ataque de Kerberoasting directamente desde la máquina comprometida. En este escenario, no es necesario interactuar directamente con el controlador de dominio desde una máquina externa como lo hicimos en el caso anterior. En su lugar, podemos usar las funciones del sistema operativo y herramientas como Rubeus, que nos permiten consultar el dominio desde el contexto del sistema comprometido. Pero para lograr esto previamente debemos cargar el ejecutable al equipo víctima.
Rubeus nos permite realizar una enumeración de todas las cuentas del dominio que tengan un Service Principal Name (SPN) asociado y que estén configuradas para usar el cifrado RC4-HMAC. Al ejecutar el comando Rubeus.exe kerberoast, se consulta al dominio por cuentas "Kerberoasteables" y se solicitan los correspondientes tickets de servicio (TGS). Estos tickets son devueltos por el KDC cifrados con una clave derivada del hash NTLM de la cuenta que posee el SPN. Rubeus extrae estos TGS y los imprime en un formato compatible con herramientas de crackeo como Hashcat o JohnTheRipper. Cada hash obtenido puede ser crackeado offline, sin necesidad de interactuar nuevamente con el entorno comprometido, lo que reduce significativamente la posibilidad de detección por parte de sistemas de monitoreo.
El siguiente ejemplo indica que se encontraron dos cuentas con SPNs: SQLService y HTTPService. Ambas utilizan RC4-HMAC como tipo de cifrado (Supported ETypes: RC4_HMAC_DEFAULT), lo cual las hace especialmente vulnerables a este tipo de ataque. Rubeus proporciona detalles como el nombre de la cuenta, el SPN completo, la fecha del último cambio de contraseña y el ticket cifrado. Esta modalidad de Kerberoasting es particularmente eficaz, ya que puede ejecutarse sin tráfico externo y desde un entorno autenticado, aprovechando la arquitectura del protocolo Kerberos y su falta de verificación de autorización en la emisión de tickets.
Last updated