Kerberoasting

Un Service Principal Name (SPN) es un identificador único de una instancia de servicio. Los SPN son utilizados por la autenticación Kerberos para asociar una instancia de servicio con una cuenta de inicio de sesión de servicio.
— MSDN

A diferencia del AS-REP Roasting, que no requiere credenciales previas, en Kerberoasting es necesario contar con credenciales válidas en el dominio. Esto puede ser un usuario en texto claro, un hash NTLM, una shell con contexto de usuario de dominio o acceso a nivel SYSTEM en un equipo unido al dominio.

¿Qué es Kerberoasting?

Kerberoasting es un ataque dirigido a cuentas de servicio en Active Directory, que permite a un atacante descifrar contraseñas fuera de línea. A diferencia de AS-REP Roasting, este ataque requiere autenticación previa en el dominio, es decir, el atacante necesita acceso con una cuenta de usuario, aunque sea de bajo privilegio, o un sistema dentro de la red del dominio.

Cuando un servicio se registra en Active Directory, se le asigna un Service Principal Name (SPN), que actúa como alias para una cuenta de servicio real. Esta información incluye el nombre del servidor, el puerto y el hash de la contraseña de la cuenta de servicio. Idealmente, estas cuentas deberían tener contraseñas seguras con mecanismos de auto-rotación, pero en la práctica, muchos SPN están asociados a cuentas de usuario en lugar de cuentas de servicio, debido a configuraciones deficientes o falta de soporte por parte de algunos proveedores.

Si una cuenta de servicio tiene una contraseña débil, un atacante puede explotar esta vulnerabilidad. Cualquier usuario del dominio puede solicitar un Ticket Granting Service (TGS) para cualquier servicio registrado en el dominio. Una vez recibido el TGS, el atacante puede extraerlo y descifrarlo offline, utilizando herramientas como Hashcat o John the Ripper, para intentar recuperar la contraseña de la cuenta asociada al servicio.

Implicaciones de seguridad

Durante una prueba de penetración, si se detecta un SPN vinculado a una cuenta de usuario, pero su contraseña no se puede descifrar, el hallazgo suele considerarse de baja gravedad. Sin embargo, si la contraseña es débil, en el futuro podría ser vulnerable a ataques de fuerza bruta. El propósito de este hallazgo es educar al cliente sobre los riesgos asociados y la importancia de asegurar correctamente estas cuentas.

Desde Linux

Con una máquina Linux, se pueden obtener todos los TGS’s utilizando el script GetUserSPNs.py de impacket. Con el siguiente comando se puede llevar a cabo el ataque y salvar los TGS’s descubiertos:

impacket-GetUserSPNs hacklab.local/pparker:Password123 -dc-ip 192.168.56.10 -request -outputfile hashes.kerberoast

Desde Windows

Del mismo modo, se puede realizar el ataque de Kerberoasting desde Windows con varias herramientas como Rubeus.

.\Rubeus.exe kerberoast /creduser:hacklab.local\pparker /credpassword:Password123 /outfile:hashes.kerberoast

Crackeando los TGS’s

Utilizamos hashcat para romper el hash y recuperar la contraseña de la cuenta de servicio.

hashcat -m 13100 hashes.kerberoast /usr/share/wordlists/rockyou.txt

John The Ripper

john --format=krb5tgs --wordlist=/usr/share/wordlists/rockyou.txt hashes.kerberoast

Asignar SPN a un usuario

En caso de tener un permiso como GenericAll o GenericWrite lo que podemos hacer es Asignar un SPN falso a la cuenta de usuario para luego obtener el hash devuelte por TGS-REP y crackearlo.

Import-module .\PowerView.ps1
Set-DomainObject -Identity <USER> -SET @{serviceprincipalname='nonexistent/BLAHBLAH'}

Mitigación del ataque Kerberoasting

• Utilizar contraseñas robustas.

• Privilegios mínimos: Otorgar a los usuarios únicamente los privilegios necesarios para realizar sus tareas específicas y restringir cualquier privilegio adicional que no sea esencial para evitar posibles riesgos de seguridad. Este enfoque ayuda a reducir la superficie de ataque y a limitar el impacto de posibles violaciones de seguridad.

• No ejecutar las cuentas de Servicio como Administrador del Dominio.