Deteccion prevencion kerberoasting empieza con un hecho simple: cualquier principal autenticado de Active Directory que tenga un TGT válido puede solicitar tickets de servicio para SPN, y algunos de esos tickets todavía pueden crackearse offline si la cuenta de servicio objetivo es lo bastante débil. La parte difícil no es entender el nombre del ataque. La parte difícil es demostrar qué cuentas respaldadas por SPN siguen siendo realmente explotables en tu dominio, qué telemetría resulta realmente útil y qué acciones de remediación reducen el riesgo de forma medible sin romper producción.
¿Qué es Kerberoasting?
Kerberoasting es el abuso del mecanismo de emisión de tickets de servicio Kerberos para obtener material de ticket que puede crackearse offline contra el secreto de una cuenta de servicio. MITRE clasifica este comportamiento como T1558.003 Kerberoasting.
En Active Directory, Kerberos usa los Service Principal Names (SPN) para asociar una instancia de servicio con la cuenta que ejecuta ese servicio. Microsoft documenta los SPN como el identificador que Kerberos usa para localizar el principal objetivo de un servicio. Cuando un cliente solicita un ticket de servicio Kerberos para ese SPN, el ticket se genera para la cuenta de servicio que lo posee.
Eso no significa que todas las cuentas con un SPN tengan el mismo nivel de riesgo. La exposición real depende de cuatro factores:
- si la cuenta depende de una contraseña gestionada manualmente por un usuario o de una identidad de servicio mejor gestionada;
- si el secreto de la cuenta es antiguo, predecible o nunca se rota;
- qué tipos de cifrado Kerberos se están usando realmente para emitir tickets;
- qué acceso obtiene la cuenta si sus credenciales llegan a recuperarse.
Por eso Kerberoasting no es solo un problema de Kerberos. También es un problema de higiene de cuentas de servicio, de política de cifrado y, en muchos entornos, de gobierno de privilegios.
Por qué Kerberoasting sigue importando en Active Directory
Kerberoasting sigue siendo relevante porque muchos dominios arrastran todavía una larga cola de cuentas de servicio legacy:
- cuentas de servicio respaldadas por usuarios creadas hace años;
- cuentas con
PasswordNeverExpires; - cuentas cuya contraseña se definió una vez y luego se olvidó;
- cuentas que todavía dependen de
RC4por compatibilidad; - cuentas que fueron acumulando derechos de admin local, backup, SQL, orquestación o derechos delegados con el tiempo.
Esa combinación es lo que hace práctica la técnica. La ruta de la petición Kerberos es legítima. El cracking offline ocurre fuera del dominio. El radio de impacto depende de lo que esa cuenta de servicio permita hacer después.
Esto también explica por qué la seguridad de contraseñas en AD y las cuentas obsoletas y sobreprivilegiadas en AD importan tanto aquí. Un ticket de servicio no es el objetivo final. El objetivo es recuperar una credencial que abra un camino de privilegio mayor.
Precondiciones para una exposición Kerberoasting real
Una finding de Kerberoasting merece priorización alta cuando la mayoría de los siguientes puntos son ciertos:
- la cuenta tiene uno o más SPN registrados;
- la cuenta depende de una contraseña gestionada manualmente en lugar de una identidad de servicio gestionada;
- la contraseña es antigua, rara vez se rota o está exenta de expiración;
RC4sigue en uso o sigue permitido donde ya deberían estar presentes tipos de cifrado más fuertes;- la cuenta tiene valor real para movimiento lateral o elevación de privilegios;
- el entorno no revisa de forma habitual el inventario de SPN ni la propiedad de las cuentas de servicio.
La documentación de Microsoft sobre msDS-SupportedEncryptionTypes importa directamente aquí. El KDC usa esa información cuando genera un ticket de servicio para la cuenta. La guía actual de Microsoft sobre Kerberos también señala que RC4 es inseguro, está siendo retirado y debe auditarse y remediarse cuando existan tipos de cifrado más fuertes.
Esa es la diferencia operativa entre un simple ítem de inventario y una exposición Kerberoasting real. Una cuenta de bajo valor con SPN, un secreto largo, aleatorio y rotado recientemente no es el mismo problema que una cuenta SQL respaldada por un usuario, todavía en RC4 y con acceso amplio a servidores.
Cómo funciona Kerberoasting
Microsoft documenta los SPN como la forma en que Kerberos asocia una instancia de servicio con la cuenta que inicia sesión para ese servicio. En la práctica, eso significa que un principal de dominio con un TGT válido puede solicitar un TGS para una cuenta de servicio que tenga un SPN.
MITRE describe Kerberoasting como la obtención de un ticket TGS que puede ser vulnerable a fuerza bruta. El punto que importa a los defensores es que el cracking ocurre offline. Una vez recogido el material del ticket, el atacante ya no necesita interacción continua con el dominio para probar hipótesis de contraseña.
Los puntos defensivos clave son:
- la ruta de petición es tráfico Kerberos legítimo;
- el ticket está vinculado al secreto de la cuenta de servicio, no a una sesión interactiva en el host objetivo;
- la explotabilidad real depende del tipo de cifrado y de la fortaleza de la contraseña;
- el impacto depende de los privilegios de la cuenta de servicio tras la recuperación de la credencial.
La pregunta correcta no es «¿puede ocurrir Kerberoasting en este dominio?». La pregunta correcta es «¿qué cuentas con SPN siguen siendo lo bastante crackeables como para importar y qué desbloquearían si se recuperan?».
Deteccion prevencion kerberoasting: qué deben revisar realmente los defensores
La detección de Kerberoasting debe construirse como correlación, no como una teoría basada en un único evento.
Empezar por el Event ID 4769
Microsoft documenta 4769 como el evento generado cuando el KDC emite un ticket de servicio Kerberos. Se registra en los controladores de dominio. Para revisar Kerberoasting, suele ser el evento nativo más útil porque captura directamente la ruta de solicitud TGS.
Qué conviene buscar:
- una ráfaga de solicitudes TGS desde una misma cuenta o una misma fuente en poco tiempo;
- solicitudes de muchos SPN distintos que no encajan con el comportamiento normal del solicitante;
TicketEncryptionType = 0x17solo cuando RC4 ya no debería ser necesario en ese entorno;- solicitudes SPN procedentes de estaciones o usuarios que normalmente no interactúan con esos servicios.
La guía actual de Microsoft sobre remediación de RC4 recomienda explícitamente auditar el uso de RC4 en los eventos 4768 y 4769, y explica que RC4 se está retirando. Eso hace útil esta telemetría, pero solo dentro de contexto. RC4 por sí solo no demuestra Kerberoasting. En algunos dominios sigue indicando un problema de compatibilidad y no una actividad hostil.
Usar el Event ID 4768 como contexto de correlación
4768 documenta la emisión del TGT, no la solicitud de ticket de servicio en la que se apoya Kerberoasting. Debe tratarse como contexto de apoyo, no como detector principal.
Sirve para responder preguntas como:
- ¿qué cuenta obtuvo el TGT que precedió a una actividad TGS inusual?
- ¿qué sistemas origen están implicados?
- cuando el esquema enriquecido del evento está disponible, ¿qué sugieren los campos sobre claves soportadas y fallback?
Ese contexto es útil cuando se investiga un clúster anómalo de 4769. No sustituye a 4769.
Mantener inventario continuo de cuentas respaldadas por SPN
La calidad de la detección mejora mucho si mantienes un inventario continuo de:
- cuentas con SPN;
- antigüedad de contraseñas;
PasswordNeverExpires;- si la cuenta es un usuario clásico o una identidad de servicio gestionada;
- privilegios efectivos y alcance de admin local;
- postura de cifrado cuando sea relevante para tu entorno.
Un inventario defensivo sencillo puede bastar para sacar a la luz los candidatos de mayor riesgo antes incluso de investigar tráfico sospechoso.
Get-ADUser -LDAPFilter "(servicePrincipalName=*)" -Properties servicePrincipalName,pwdLastSet,PasswordNeverExpires,msDS-SupportedEncryptionTypes |
Select-Object SamAccountName,ServicePrincipalName,PasswordNeverExpires,pwdLastSet,msDS-SupportedEncryptionTypes
La idea no es recopilar todos los SPN y entrar en pánico. La idea es identificar qué cuentas combinan exposición SPN, mala higiene del secreto y privilegios significativos.
Tratar el baselining como obligatorio
Una postura seria de detección de Kerberoasting exige una baseline de los patrones normales de tickets de servicio. Eso implica saber:
- qué hosts suelen solicitar tickets para qué servicios;
- qué cuentas de servicio son accedidas de forma masiva por comportamiento legítimo de aplicaciones;
- qué herramientas de administración, escaneo o gestión generan de forma legítima actividad TGS amplia.
Sin esa baseline, «muchos 4769» no es una estrategia de detección. Solo es un punto de partida.
Prevención y hardening
La prevención de Kerberoasting consiste sobre todo en convertir las cuentas de servicio con SPN en malos objetivos para el cracking y en malos objetivos para la escalada de privilegios.
1. Reducir cuentas de servicio respaldadas por usuarios cuando sea posible
Microsoft documenta las group Managed Service Accounts (gMSA) como cuentas de dominio gestionadas que proporcionan gestión automática de contraseñas y gestión simplificada de SPN, incluso en varios servidores.
Eso no hace que una gMSA quede mágicamente fuera de Kerberos. Sí la convierte en una opción defensiva mucho mejor que una cuenta de usuario gestionada manualmente cuya contraseña no ha cambiado en años.
Cuando la plataforma lo permita, migrar servicios elegibles desde cuentas de servicio clásicas respaldadas por usuarios hacia gMSA es uno de los controles preventivos más útiles que puedes aplicar.
2. Rotar contraseñas de cuentas de servicio legacy
La guía de Microsoft para remediar RC4 indica que cuentas antiguas pueden carecer de claves AES si su contraseña nunca se restableció después de introducirse el soporte Kerberos moderno. Eso importa porque restablecer una contraseña no solo cambia el secreto: también puede refrescar el material de claves utilizable por la cuenta.
Para cuentas de servicio legacy que todavía no pueden pasar a gMSA:
- rota la contraseña;
- hazla larga y aleatoria;
- verifica después que el servicio sigue funcionando correctamente;
- documenta la propiedad para que la cuenta no vuelva a convertirse en deuda técnica compartida.
3. Reducir RC4 con criterio, no a ciegas
Microsoft documenta ahora de forma explícita que RC4 es inseguro, está siendo retirado y debe auditarse mediante telemetría Kerberos. Microsoft también documenta formas concretas de limitar o deshabilitar RC4, incluida la política de tipos de cifrado Kerberos permitidos.
La conclusión correcta no es «desactiva RC4 en todas partes de inmediato». La conclusión correcta es:
- identificar dónde se sigue usando RC4;
- determinar si la dependencia es real o solo configuración heredada no mantenida;
- mover cuentas y hosts elegibles a ajustes compatibles con AES;
- monitorizar fallos de autenticación durante el rollout.
La propia documentación de Microsoft advierte de que deshabilitar RC4 puede romper dependencias legacy si no se han validado antes. Esa advertencia debe formar parte de cualquier plan serio de hardening frente a Kerberoasting.
4. Revisar los privilegios detrás de la cuenta de servicio
La prevención queda incompleta si solo mejoras la contraseña y no revisas los privilegios.
Revisa si la cuenta de servicio tiene:
- admin local en muchos servidores;
- derechos delegados en AD;
- privilegios de backup, orquestación o despliegue;
- acceso de alto valor a bases de datos o ficheros;
- caminos implícitos hacia el anidamiento de grupos AD o la deriva del acceso privilegiado en Active Directory.
Una cuenta de servicio endurecida pero sobreprivilegiada sigue convirtiendo la recuperación de una credencial en un incidente importante.
5. Limpiar SPN que ya no representen servicios reales
Microsoft documenta setspn como la herramienta para leer, añadir, eliminar y consultar SPN. Eso importa operativamente, porque SPN obsoletos o duplicados no son solo un problema de higiene: dificultan el ownership y amplían la superficie de revisión.
Si un SPN ya no respalda un servicio real, elimínalo. Si una aplicación ya no necesita una identidad respaldada por usuario, retira la cuenta en lugar de conservarla indefinidamente.
Validación tras la remediación
Una remediación de Kerberoasting no está completa porque se haya rotado una contraseña una vez o porque se haya cambiado un tipo de ticket en laboratorio. La validación debe demostrar que la exposición en producción realmente ha cambiado.
Conserva al menos un paquete mínimo de evidencias como este:
| Evidencia | Por qué importa |
|---|---|
| Inventario actual de cuentas respaldadas por SPN | Confirma el alcance revisado y el ownership |
| Postura de antigüedad / expiración de contraseñas de cuentas de servicio | Muestra si las cuentas legacy crackeables se remediaron de verdad |
| Clasificación entre cuentas gestionadas y cuentas respaldadas por usuarios | Demuestra dónde la migración a gMSA redujo el riesgo de secretos manuales |
Baseline Kerberos para 4769 | Confirma la lógica de detección tras los cambios |
| Revisión de uso de RC4 con excepciones registradas | Distingue dependencias legacy aceptadas de deriva no gobernada |
| Revisión de privilegios de cuentas de servicio de alto valor | Muestra si el radio de impacto bajó, no solo el problema de contraseña |
Las preguntas de validación deben ser concretas:
- ¿qué cuentas críticas con SPN siguen dependiendo de contraseñas gestionadas manualmente?
- ¿cuáles siguen mostrando antigüedad excesiva o exenciones de expiración?
- ¿qué servicios siguen necesitando RC4 y quién aprobó esa dependencia?
- ¿qué cuentas seguirían permitiendo movimiento lateral significativo si fueran recuperadas?
- ¿ha mejorado de forma material la baseline
4769del dominio tras la remediación?
Esa es la diferencia entre «hemos cambiado algunas contraseñas de cuentas de servicio» y «hemos reducido de forma medible el riesgo de Kerberoasting».
Cómo EtcSec mide el riesgo de Kerberoasting
EtcSec debe describir las condiciones que hacen práctico el Kerberoasting, no fingir que prueba un ataque en curso a partir de un solo evento.
La finding principal es KERBEROASTING_RISK, útil cuando una cuenta tiene un SPN y sigue presentando uno o varios rasgos que hacen que el cracking offline sea materialmente más realista.
Findings de contexto que elevan la prioridad:
PASSWORD_NEVER_EXPIRESPASSWORD_POLICY_WEAKKERBEROS_RC4_FALLBACK
Usados en conjunto, estos checks ayudan a estructurar una revisión repetible de:
- qué cuentas de servicio están expuestas;
- cuáles siguen siendo lo bastante débiles como para importar;
- cuáles están situadas en caminos de privilegio relevantes;
- cuáles todavía necesitan pruebas de remediación después de los cambios.
Controles relacionados
Kerberoasting debe revisarse junto con controles de identidad adyacentes que a menudo amplifican el mismo camino de compromiso:
- AS-REP Roasting, porque ambas técnicas convierten material Kerberos en riesgo de cracking offline;
- Seguridad de contraseñas en AD, porque la calidad y la rotación de contraseñas determinan la explotabilidad;
- Cuentas obsoletas y sobreprivilegiadas en AD, porque las cuentas olvidadas suelen ser dueñas de los SPN más peligrosos;
- Delegación Kerberos, porque las identidades de servicio suelen solaparse con exposición por delegación;
- Auditar la seguridad de Active Directory, porque Kerberoasting es solo un punto dentro de un workflow más amplio de evidencia en AD;
- Supervisión seguridad AD, porque
4769solo resulta útil cuando la recogida de eventos y la baseline ya están en marcha.
Referencias primarias
- MITRE ATT&CK T1558.003: Kerberoasting
- 4769(S, F): A Kerberos service ticket was requested
- 4768(S, F): A Kerberos authentication ticket (TGT) was requested
- Detect and remediate RC4 usage in Kerberos
- Kerberos authentication overview in Windows Server
- Group Managed Service Accounts overview
- Service principal names
- Setspn
- ms-DS-Supported-Encryption-Types attribute
- Audit Directory Service Access
