En un pentest interno autorizado, ¿qué es Kerberoasting, por qué funciona y cómo lo detecta y mitiga el equipo defensivo?

Qué es: en Active Directory, cualquier usuario autenticado puede pedirle al KDC un ticket de servicio (TGS) para cualquier cuenta que tenga un SPN registrado. Una parte de ese ticket está cifrada con una clave derivada de la contraseña de la cuenta de servicio. Ese material se puede atacar offline, sin generar intentos de login fallidos. Si la contraseña es débil, se recupera.

Por qué funciona:

• Pedir TGS es un comportamiento legítimo y no requiere privilegios.
• Muchas cuentas de servicio humanas tienen contraseñas viejas, que no expiran y con privilegios excesivos (a veces Domain Admin).
• Si el servicio admite RC4, la clave es el hash NT, y eso facilita el ataque offline frente a AES.

En un ejercicio autorizado lo reporto como hallazgo de configuración: qué cuentas tienen SPN, su nivel de privilegio y si la contraseña resultó débil. No se reutilizan credenciales fuera del alcance acordado.

Detección:

• Evento 4769 en los DC: alertar por tickets con cifrado 0x17 (RC4) en entornos que ya usan AES y por un mismo usuario que pide TGS para muchos SPN en poco tiempo.
• Cuentas honeypot con SPN falso: cualquier pedido de TGS para ellas es altamente sospechoso.
• Consultas LDAP masivas buscando servicePrincipalName, visibles con telemetría de EDR o de DC.

Mitigación:

• Usar gMSA, con contraseñas largas y rotadas automáticamente por AD.
• Si no se puede, contraseñas de más de 25 caracteres y aleatorias.
• Deshabilitar RC4 y forzar AES (msDS-SupportedEncryptionTypes).
• Mínimo privilegio: ninguna cuenta de servicio en grupos privilegiados.
• Auditar periódicamente las cuentas con SPN y eliminar las que no se usan.

Decir que requiere privilegios elevados o que genera bloqueos de cuenta. Limitarse a la parte ofensiva sin mencionar el evento 4769, los honeypots ni las gMSA.