Kerberos es uno de los protocolos de autenticación más robustos jamás diseñados para entornos corporativos. Sin embargo, su fortaleza no reside únicamente en la criptografía, sino en un modelo de confianza explícita que, cuando se diseña o mantiene incorrectamente, puede convertirse en un vector de compromiso total del dominio sin necesidad de explotar vulnerabilidades de software.
Este artículo analiza un ataque realista y reproducible que abusa de una configuración insegura de Delegación Restringida con Transición de Protocolo (S4U) en Active Directory. El resultado final del ataque es la suplantación de un usuario administrador del dominio y el acceso a recursos críticos del Controlador de Dominio, todo ello sin conocer credenciales del administrador, sin volcar LSASS, sin malware persistente y sin romper Kerberos.
El punto clave —y la razón por la que este ataque sigue siendo especialmente peligroso— es que Kerberos funciona exactamente como fue diseñado. No hay fallos de implementación ni bugs explotados. El Centro de Distribución de Claves (KDC) emite tickets válidos porque confía legítimamente en una cuenta de servicio a la que se le han concedido permisos excesivos.
Por qué este ataque es especialmente relevante hoy
A diferencia de ataques más ruidosos (Pass-the-Hash, DCSync, NTDS.dit, LSASS dumping), este vector se caracteriza por:
- Uso exclusivo de flujos Kerberos legítimos
- Emisión de tickets válidos por el KDC
- Ausencia de credenciales robadas del usuario suplantado
- Dependencia total de decisiones administrativas previas
- Alta dificultad de detección sin telemetría Kerberos avanzada
En entornos empresariales modernos —especialmente aquellos con:
- aplicaciones legacy,
- servicios SQL o web antiguos,
- cuentas de servicio no gestionadas,
- migraciones históricas de AD—
es común encontrar delegaciones configuradas hace años, sin documentación clara y con un alcance mucho mayor del necesario. Este ataque explota precisamente ese contexto.
El error conceptual que habilita el ataque
Uno de los errores más frecuentes en Active Directory es asumir que:
“Si una cuenta de servicio necesita delegación, basta con habilitarla y funcionará.”
En la práctica, esto conduce a configuraciones donde:
- Se habilita Delegación Restringida
- Se marca “Use any authentication protocol”
- Se añaden servicios críticos a la lista de delegación
- No se evalúa el impacto de Protocol Transition (S4U)
El resultado es una cuenta de servicio que puede:
- Solicitar tickets en nombre de cualquier usuario del dominio
- Presentar esa identidad frente a otros servicios
- Obtener acceso administrativo si el servicio delegado lo permite
Desde el punto de vista del KDC, todo es válido.
Desde el punto de vista de seguridad, el dominio queda lógicamente comprometido.
Qué NO es este ataque
Es importante dejar claro desde el inicio lo que no ocurre en este escenario:
- ❌ No se explota ninguna vulnerabilidad de Windows
- ❌ No se rompe la criptografía de Kerberos
- ❌ No se obtienen hashes del Administrador
- ❌ No se realiza movimiento lateral clásico
- ❌ No se abusa de NTLM
El ataque se basa únicamente en:
- confianza excesiva
- delegación mal diseñada
- falta de auditoría de cuentas de servicio
Esto lo convierte en un ataque especialmente peligroso, porque muchas organizaciones no lo consideran un fallo de seguridad, sino una “configuración necesaria para que la aplicación funcione”.
Objetivo del artículo
A lo largo de este análisis se demostrará:
- Cómo una cuenta de servicio puede suplantar a un administrador
- Por qué S4U2Self y S4U2Proxy son flujos críticos
- Qué decisiones de diseño en AD permiten este ataque
- Qué evidencias quedan en Kerberos y en el KDC
- Por qué muchos dominios bien parcheados siguen siendo vulnerables
- Qué controles defensivos pueden prevenir o detectar este escenario
El laboratorio presentado no simula un entorno roto, sino uno plausible, similar al que se encuentra en auditorías reales de Active Directory.
Fundamentos técnicos de Kerberos relevantes para el ataque
Para comprender por qué el ataque descrito es posible, no es necesario repasar Kerberos desde cero. Sin embargo, sí es imprescindible entender qué piezas del protocolo están involucradas, qué asunciones hace el KDC y dónde se introducen relaciones de confianza que pueden ser abusadas.
Este bloque se centra exclusivamente en los elementos de Kerberos que intervienen en la delegación y la suplantación, ignorando todo lo demás.
Resumen Ejecutivo
Este artículo analiza en profundidad un ataque avanzado contra Active Directory basado en el abuso legítimo del protocolo Kerberos, concretamente mediante Delegación Restringida con Transición de Protocolo (S4U).
El escenario demuestra cómo una cuenta de servicio mal configurada puede ser utilizada para suplantar a un administrador del dominio y acceder a recursos críticos del Controlador de Dominio, sin explotar vulnerabilidades, sin robar credenciales y sin generar autenticaciones interactivas.
El ataque no compromete Kerberos ni Windows. Al contrario:
el Key Distribution Center (KDC) emite tickets válidos y criptográficamente correctos porque confía explícitamente en una configuración insegura definida previamente en Active Directory. La raíz del problema no es técnica, sino arquitectónica: una relación de confianza excesiva otorgada a una cuenta de servicio.
A lo largo del artículo se detalla:
- Cómo funcionan los flujos S4U2Self y S4U2Proxy y por qué permiten suplantación sin credenciales.
- Qué decisiones administrativas habilitan este vector de ataque.
- Cómo se ejecuta el ataque paso a paso usando tickets Kerberos legítimos.
- Qué evidencias forenses quedan registradas en el Event ID 4769 del DC.
- Por qué este tipo de ataque suele pasar desapercibido en muchos SOC.
- Qué controles de hardening, delegación y diseño de identidad permiten prevenirlo.
El laboratorio reproducido no representa un entorno artificial o deliberadamente inseguro, sino un caso realista, habitual en organizaciones con aplicaciones legacy, cuentas de servicio históricas y delegaciones poco auditadas.
El mensaje central es claro:
Kerberos no falla.
Falla el modelo de confianza construido alrededor de él.
Este artículo pretende servir como referencia técnica avanzada tanto para equipos ofensivos como defensivos, poniendo el foco en un tipo de riesgo que no se mitiga con parches, sino con buen diseño, auditoría continua y comprensión profunda de Active Directory.
1. El rol real del KDC: autoridad de confianza, no de verificación
En Active Directory, el Key Distribution Center (KDC) cumple dos funciones críticas:
- Emitir tickets de autenticación (TGT y TGS)
- Decidir en quién confía
El KDC no valida intenciones, valida configuraciones.
Si una cuenta tiene permiso para actuar en nombre de otra, el KDC no cuestiona el uso, solo verifica que:
- la cuenta esté autorizada,
- el flujo Kerberos sea correcto,
- los tickets sean criptográficamente válidos.
👉 Este principio es fundamental:
Kerberos no impone límites de seguridad por sí mismo; los hereda del diseño de Active Directory.
2. Tipos de tickets implicados en el ataque
En este escenario intervienen tres tipos de tickets clave:
2.1 Ticket Granting Ticket (TGT)
- Emitido tras autenticación inicial
- Permite solicitar tickets de servicio (TGS)
- Puede ser:
- forwardable
- renewable
- delegable
📌 En el ataque, la capacidad de delegación del TGT es crítica.
2.2 Ticket Granting Service (TGS)
- Emitido para un servicio concreto (SPN)
- Representa la identidad del usuario frente al servicio
- Puede ser reenviado si la política lo permite
En el ataque:
- Se emiten TGS válidos para el usuario Administrator
- Sin que Administrator haya iniciado sesión
2.3 Tickets reenviables (Forwardable tickets)
Un ticket forwardable puede ser reutilizado para acceder a otros servicios.
Este atributo:
- no es peligroso por sí solo,
- se vuelve crítico cuando se combina con delegación.
3. Delegación en Kerberos: concepto clave
La delegación permite que:
Un servicio actúe en nombre de un usuario frente a otro servicio.
Esto es necesario para:
- aplicaciones web con backend,
- servicios intermedios,
- SQL Server accediendo a recursos,
- arquitecturas multi-tier.
Kerberos soporta delegación de forma explícita y controlada, pero no segura por defecto.
4. Los dos flujos S4U que habilitan la suplantación
El ataque se apoya en dos extensiones de Kerberos llamadas Service for User (S4U).
4.1 S4U2Self – Suplantación local
S4U2Self permite que un servicio:
- solicite un ticket para sí mismo
- en nombre de cualquier usuario
- sin que ese usuario se haya autenticado previamente
Esto solo es posible si:
- el KDC confía explícitamente en el servicio
- está habilitada la Transición de Protocolo
📌 Resultado:
- el servicio obtiene un TGS que representa a otro usuario
- el usuario no participa en el proceso
4.2 S4U2Proxy – Suplantación hacia otros servicios
S4U2Proxy permite que:
- un servicio use un ticket obtenido vía S4U2Self
- para solicitar acceso a otro servicio distinto
- en nombre del usuario suplantado
Este flujo NO es automático.
El KDC solo lo permite si:
- existe delegación restringida
- el servicio destino está explícitamente autorizado
- el ticket es forwardable
📌 Este es el punto donde el ataque se completa.
5. Protocol Transition: el punto más peligroso
La Transición de Protocolo rompe una de las asunciones originales de Kerberos:
El usuario debe autenticarse para obtener un ticket.
Con Protocol Transition:
- el servicio puede “inventar” la identidad del usuario,
- el KDC confía en esa afirmación,
- y emite tickets reales.
Esto no es un bug, es una funcionalidad diseñada para compatibilidad con:
- autenticación basada en formularios,
- tokens externos,
- sistemas legacy.
Pero en términos de seguridad:
- amplía enormemente la superficie de ataque.
6. Diferencia crítica entre tipos de delegación
Es habitual confundir estos conceptos, y el laboratorio demuestra por qué es peligroso.
| Tipo de delegación | Permite S4U2Self | Permite S4U2Proxy |
|---|---|---|
| Unconstrained | ❌ | ❌ |
| Constrained (sin PT) | ❌ | ❌ |
| Constrained + PT | ✅ | ✅ |
| RBCD | ✅ | ✅ |
📌 Solo una combinación concreta permite el ataque completo.
7. Por qué Kerberos no “detecta” el ataque
Desde el punto de vista del KDC:
- las peticiones son válidas,
- las claves son correctas,
- los tickets cumplen política,
- el flujo es legítimo.
No existe un concepto de:
“este ticket es sospechoso”
Kerberos no evalúa contexto, solo confianza previa.
Mensaje clave de este bloque
S4U no es una vulnerabilidad.
Es una relación de confianza extremadamente poderosa.
Cuando se concede sin límites claros, el dominio confía demasiado.
En el siguiente bloque entraremos en la arquitectura del laboratorio y la configuración exacta que permitió el ataque, descomponiendo qué decisiones administrativas hicieron posible el compromiso.
Arquitectura del entorno y superficie de ataque
Para entender por qué el ataque funcionó, es imprescindible analizar la arquitectura del entorno y, sobre todo, las decisiones administrativas que definieron la superficie de ataque.
En Kerberos, la topología lógica y las relaciones de confianza son más importantes que la infraestructura física.
Este bloque describe qué componentes existían, cómo estaban relacionados y qué configuraciones concretas habilitaron el abuso.
Requerimientos:
- Sistema – Sistemas para realizar las pruebas
- Programación – Conocimientos altos de programación
Resposabilidad:
En este tutorías utilizaremos técnicas de hacking, con el único fin de aprendizaje. No promovemos su utilización ni con fines lucrativos o incorrectos. No nos hacemos responsables de cualquier daño o menoscabo que pueda generar en los sistemas utilizados. La responsabilidad es absoluta del usuario de este tutorial.
Conocimientos:
- Linux – N/A
- Programación – Muy alto
- Kali Linux – N/A
- Windows – Muy alto Alto
- Redes – Muy alto
Nivel general del Tutorial: Muy Alto
Ideal para: Ingenieros de sistemas, Ingenieros de seguridad, Pentesters
1. Componentes del laboratorio
El entorno reproduce un escenario muy común en empresas medianas y grandes, especialmente aquellas con aplicaciones legacy o integraciones históricas.
1.1 Controlador de Dominio (DC)
- Dominio:
lab.local - Rol:
- Key Distribution Center (KDC)
- LDAP
- DNS
- Servicio CIFS administrativo (
C$)
- Características relevantes:
- Kerberos plenamente operativo
- Tickets forwardable permitidos
- Sin restricciones adicionales a nivel KDC
📌 Punto clave:
El DC no fue comprometido directamente.
El acceso se obtuvo por delegación legítima, no por explotación del DC.
1.2 Estación atacante (Windows 11)
- Miembro del dominio
- Usuario estándar de dominio
- Kerberos con TGT válido
- Capacidad de ejecutar herramientas en memoria
Desde el punto de vista del dominio:
- Es una workstation legítima
- No tiene privilegios elevados
- No presenta anomalías de autenticación
📌 Esto es crítico:
El ataque no requiere acceso privilegiado previo.
1.3 Cuenta de servicio (svc_sql)
Este es el activo crítico del ataque.
Características observadas en el laboratorio:
- Cuenta de usuario estándar (no gMSA)
- Password estática conocida
- SPN asignado: MSSQLSvc/sql.lab.local
- Configuración de delegación:
- Delegación Restringida
- Transición de Protocolo habilitada
- Servicios críticos autorizados como destino
📌 Conclusión:
La cuenta svc_sql se convierte en una autoridad delegada dentro del dominio.
2. La cuenta de servicio como punto único de fallo
En muchos entornos, las cuentas de servicio se consideran:
- “no interactivas”
- “de bajo riesgo”
- “necesarias para que la aplicación funcione”
Este laboratorio demuestra lo contrario.
2.1 Confianza acumulada
svc_sql concentraba simultáneamente:
- Capacidad de autenticarse ante el KDC
- Capacidad de suplantar identidades (S4U2Self)
- Capacidad de delegar esa identidad (S4U2Proxy)
- Acceso delegado a servicios del DC
Cada una de estas capacidades por separado puede ser razonable.
Juntas, crean una ruta directa de compromiso.
2.2 Ausencia de límites de alcance
No existían controles como:
- gMSA con rotación automática
- Restricciones por tiering
- Separación de servicios críticos
- Monitorización de uso de delegación
Desde el punto de vista del KDC:
- No hay razón para sospechar
- La cuenta está autorizada
- La configuración es explícita
3. Superficie de ataque efectiva
Aunque el entorno tenía múltiples componentes, la superficie de ataque real se reducía a:
- Comprometer o conocer la credencial de
svc_sql - Ejecutar el flujo S4U
- Acceder a un servicio delegado de alto impacto
No fue necesario:
- movimiento lateral clásico,
- escalada de privilegios tradicional,
- explotación de servicios expuestos.
📌 La superficie de ataque estaba “embebida” en la configuración de AD.
4. El rol del SPN en el ataque
El SPN no fue un detalle accesorio, sino un elemento estructural.
- El KDC decide a qué servicio se accede
- Basándose únicamente en el SPN solicitado
- Y en la lista de delegación permitida
En el laboratorio:
- El SPN del DC (
cifs/DC) estaba autorizado - El acceso administrativo fue una consecuencia directa
👉 El SPN definió el impacto del ataque.
5. Por qué esta arquitectura es realista
Este escenario no es artificial. Aparece con frecuencia cuando:
- SQL Server accede a recursos remotos
- Aplicaciones web acceden a shares
- Servicios heredados se migran sin rediseñar seguridad
- Nadie revisa delegaciones históricas
En auditorías reales, este tipo de configuración suele existir desde hace años.
Mensaje clave de este bloque
En Kerberos, la superficie de ataque no está en el código,
sino en las relaciones de confianza entre servicios.
Un dominio puede estar totalmente parcheado y, aun así, ser vulnerable si una sola cuenta de servicio concentra demasiada confianza.
En el siguiente bloque entraremos en la ejecución técnica del ataque paso a paso, correlando cada fase con qué decisión de Active Directory la hizo posible y qué evidencias dejó en Kerberos.
Ejecución del ataque: cadena completa de compromiso Kerberos (S4U)
Una vez establecida la arquitectura vulnerable, el ataque se ejecuta como una cadena lógica de peticiones Kerberos válidas, cada una de ellas autorizada explícitamente por el KDC en función de la configuración de Active Directory.
No hay explotación de memoria, ni abuso de NTLM, ni técnicas de escalada tradicionales.
El atacante simplemente recorre un camino de confianza previamente definido.
1. Establecimiento del contexto Kerberos del atacante
El ataque comienza desde una estación de trabajo unida al dominio, utilizando un usuario estándar con un TGT válido.
Desde el punto de vista del dominio:
- No hay privilegios elevados
- No hay comportamientos anómalos
- No hay autenticaciones fallidas
- Usuario de dominio
- TGT válido (
krbtgt/LAB.LOCAL) - Tickets forwardable
2. Enumeración de tickets en la sesión (triage)
El primer paso técnico consiste en inspeccionar la caché Kerberos local para confirmar:
- Existencia de TGT
- Servicios ya utilizados
- Flags relevantes (forwardable, delegation)
Este paso no enumera Active Directory, solo valida el estado local de Kerberos.
- TGT del usuario
- Servicios LDAP / CIFS habituales
- Sin tickets administrativos
3. Obtención de un TGT delegable (tgtdeleg)
A continuación, el atacante fuerza la obtención de un TGT con capacidad de delegación, aprovechando que la política del dominio lo permite.
Este paso es crítico porque:
- habilita la reutilización del ticket,
- prepara el terreno para S4U,
- no requiere interacción del usuario suplantado.
- Delegation request success
- Ticket extraído correctamente
- Sin errores de KDC
4. S4U2Self: suplantación del usuario Administrador
En este punto se ejecuta el primer salto crítico del ataque.
La cuenta de servicio svc_sql, gracias a:
- la Transición de Protocolo habilitada,
- y la confianza explícita del KDC,
puede solicitar un ticket para sí misma, pero en nombre del usuario Administrator.
El Administrador:
- no se autentica,
- no introduce credenciales,
- no genera eventos interactivos.
S4U2Self success- Ticket emitido para
Administrator - Ticket forwardable
5. S4U2Proxy: delegación hacia un servicio crítico
Este es el punto de no retorno del ataque.
Usando el ticket obtenido en S4U2Self, la cuenta svc_sql solicita acceso a un servicio distinto, autorizado explícitamente en la delegación:
en este caso, el servicio CIFS del Controlador de Dominio.
El KDC valida que:
- el servicio está en la lista permitida,
- el ticket es forwardable,
- la cuenta es de confianza.
Resultado: emisión de un ticket administrativo válido contra el DC.
- Solicitud S4U2Proxy
- Ticket emitido sin errores
- Inyección del ticket (
/ptt)
6. Inyección del ticket y validación en la sesión
El ticket emitido es inyectado en la sesión actual del atacante.
Desde este momento, el sistema cree legítimamente que el usuario es Administrator frente al servicio delegado.
- Client: Administrator
- Server: cifs/DC
- Flags válidos
7. Impacto final: acceso administrativo al Controlador de Dominio
El ataque se materializa al acceder a un recurso exclusivo de administradores del dominio.
En el laboratorio:
- Se accede al recurso
C$del DC - Sin credenciales del Administrador
- Sin login interactivo
- Sin alertas inmediatas
Mensaje clave de este bloque
Cada paso del ataque fue autorizado explícitamente por Active Directory.
El atacante no forzó nada: siguió el camino de confianza definido por el dominio.
Evidencias, logs y detección del ataque en Active Directory
Uno de los aspectos más críticos —y peligrosos— del abuso de delegación en Kerberos es que no genera señales evidentes de intrusión.
No hay explotación, no hay malware persistente y no hay autenticaciones interactivas sospechosas. Sin embargo, el ataque sí deja evidencias claras y verificables, siempre que se analicen los logs correctos con el contexto adecuado.
Este bloque analiza las trazas reales generadas en el laboratorio, demostrando cómo el ataque queda registrado en Active Directory y por qué suele pasar desapercibido en entornos productivos.
1. Dónde quedan las evidencias reales del ataque
Toda la evidencia relevante de este ataque se concentra en un único lugar:
Los logs de seguridad del Controlador de Dominio (KDC)
No aparecerán señales útiles en:
- Microsoft Defender del endpoint
- Logs de inicio de sesión interactivo
- Alertas clásicas de fuerza bruta
- Eventos de privilegios especiales (4672)
📌 Si el SOC no monitoriza eventos Kerberos en el DC, este ataque es invisible.
2. Evento clave: Security Event ID 4769 (Kerberos Service Ticket Requested)
El evento 4769 es el evento más importante de todo el ataque.
Se genera cada vez que el KDC emite un Ticket Granting Service (TGS), y es el único lugar donde queda reflejado el abuso de delegación.
El laboratorio genera múltiples eventos 4769, pero uno de ellos destaca claramente como malicioso cuando se analiza correctamente.
3. Análisis forense del evento 4769 capturado
El siguiente evento corresponde directamente a la ejecución del ataque S4U.
3.1 Account Information – El primer indicador crítico
Account Name: svc_sql
Account Domain: LAB.LOCAL
🔴 Indicador clave nº1
- El ticket es solicitado por una cuenta de servicio
- No por el usuario
Administrator - No por el usuario interactivo de la estación
👉 En un acceso administrativo legítimo al DC:
- El Account Name suele coincidir con el usuario
- Aquí no coincide, lo cual es anómalo
Este es el primer indicio claro de suplantación mediante S4U.
3.2 Network Information – El origen del abuso
Client Address: ::ffff:192.168.1.37
Client Port: 57457
🔴 Indicador clave nº2
- La petición no proviene del DC
- No proviene del servidor SQL
- Proviene de una workstation de usuario
👉 Una cuenta de servicio solicitando tickets Kerberos desde una workstation es un patrón altamente sospechoso y típico de escenarios de abuso de delegación.
3.3 Additional Information – La prueba definitiva
icket Options: 0x40820010 Ticket Encryption Type: 0x12 Failure Code: 0x0 Transited Services: svc_sql@LAB.LOCAL
Aquí se encuentra la prueba forense definitiva del ataque.
🔹 Ticket Options: 0x40820010
Este valor indica que el ticket es:
- Forwardable
- Renewable
- Emitido con delegación activa
- Compatible con S4U
📌 Estos flags no son habituales en accesos administrativos normales al DC.
🔹 Transited Services: svc_sql@LAB.LOCAL
🔴 Indicador clave nº3 (crítico)
Este campo:
- Solo aparece cuando hay delegación
- Indica que la identidad fue transitada
- Es característico de S4U2Self / S4U2Proxy
👉 En accesos Kerberos normales, este campo no existe.
Este valor confirma que:
- el KDC permitió que
svc_sql - actuara en nombre de otro usuario
- para acceder a un servicio de alto privilegio
4. Por qué este evento pasa desapercibido en muchos SOC
En la mayoría de entornos, este evento:
- Se marca como
Audit Success - No genera alertas automáticas
- No se correlaciona con la identidad suplantada
- Se considera “ruido Kerberos normal”
Los SOC suelen fallar porque:
- Se busca NTLM, no Kerberos
- Se monitorizan logins interactivos
- No se analizan campos como:
Transited ServicesTicket Options- Relación cuenta solicitante ↔ servicio destino
📌 Kerberos no alerta: documenta. El problema es no leerlo.
5. Qué NO aparece (y por qué eso también es una señal)
Durante todo el ataque NO aparecen:
- Event ID 4672 (Special Privileges Assigned)
- Eventos de inicio de sesión interactivo del Administrador
- Eventos de fallo de autenticación
👉 Esto ocurre porque:
- No hay login
- No hay password
- No hay sesión interactiva
El acceso administrativo se concede únicamente mediante tickets.
6. Indicadores de compromiso (IOCs) reales para este ataque
Indicadores de alto valor que sí aparecen:
- Cuentas de servicio solicitando TGS para:
- servicios del DC
- Campo
Transited Servicespresente - Tickets forwardable con delegación
- Peticiones desde workstations
📌 Todos estos IOCs están en el Event ID 4769.
Mensaje clave de este bloque
El ataque no fue invisible.
Fue silencioso porque nadie estaba mirando donde debía.
Kerberos dejó la evidencia.
El KDC actuó correctamente.
La debilidad estaba en la confianza delegada.
Hardening, mitigaciones y lecciones aprendidas
El ataque descrito en este artículo no depende de exploits, malware ni fallos de parcheo. Depende exclusivamente de decisiones de diseño y configuración en Active Directory.
Por tanto, su mitigación no pasa por “bloquear herramientas”, sino por rediseñar correctamente la confianza Kerberos.
Este bloque analiza cómo romper la cadena del ataque en cada fase, qué controles son realmente efectivos y qué lecciones estructurales deja este escenario.
1. Principio fundamental: la delegación es una capacidad de alto riesgo
La primera lección es conceptual:
Una cuenta con delegación NO es una cuenta de bajo privilegio.
Cualquier cuenta que pueda:
- usar S4U,
- transitar identidades,
- solicitar TGS en nombre de otros,
debe tratarse como un activo crítico de Tier 0/1, aunque no sea administrador.
📌 Error común:
Clasificar cuentas de servicio como “low risk” solo porque no permiten login interactivo.
2. Eliminar la Transición de Protocolo siempre que sea posible
La Transición de Protocolo (Protocol Transition) es el habilitador principal del ataque.
Acción recomendada
- ❌ Evitar “Use any authentication protocol”
- ✅ Usar Kerberos only cuando sea estrictamente necesario
- ✅ Eliminar S4U2Self en servicios que no lo requieran
📌 Si una aplicación necesita Protocol Transition:
- debe justificarse,
- documentarse,
- revisarse periódicamente.
3. Revisar y reducir la delegación restringida (Constrained Delegation)
Muchas delegaciones existen por inercia histórica.
Controles recomendados
- Auditar periódicamente:
msDS-AllowedToDelegateTo
- Eliminar:
- SPNs del DC (
cifs,ldap,host)
- SPNs del DC (
- Limitar delegación solo a servicios estrictamente necesarios
📌 Regla de oro:
Ninguna cuenta de servicio debería delegar hacia el Controlador de Dominio.
4. Migrar cuentas de servicio a gMSA
Las Group Managed Service Accounts (gMSA) reducen drásticamente el riesgo:
- Rotación automática de contraseña
- No reutilizables fuera del servicio
- Menor exposición de credenciales
- Mejor control de uso
Aunque no eliminan el riesgo de delegación mal diseñada, sí:
- reducen el impacto,
- dificultan el abuso,
- mejoran la trazabilidad.
5. Aplicar modelo de tiering (Tier 0 / 1 / 2)
Uno de los motivos por los que este ataque es devastador es la falta de separación de tiers.
Buen diseño:
- Tier 0:
- DCs
- Cuentas administrativas
- Tier 1:
- Servidores de aplicaciones
- Tier 2:
- Workstations
📌 Nunca:
- permitir delegación desde Tier 1 → Tier 0
- permitir uso de credenciales Tier 0 en Tier 2
Este ataque rompe completamente ese principio.
6. Endurecimiento específico de Kerberos
Recomendaciones técnicas
- Deshabilitar:
- RC4 cuando sea posible
- Forzar:
- AES únicamente
- Restringir:
- tickets forwardable para servicios sensibles
- Revisar:
- políticas de delegación en GPO
Estas medidas no impiden el ataque por sí solas, pero:
- elevan la dificultad,
- mejoran la detección,
- reducen impacto.
7. Detección proactiva: lo que un SOC debe vigilar
Un SOC bien configurado debe alertar cuando:
- Una cuenta de servicio solicita TGS para:
cifs/DCldap/DChost/DC
- Aparece el campo Transited Services
- Tickets con:
ok_as_delegateforwardable
- Peticiones Kerberos desde:
- workstations
- fuera de horarios esperados
📌 Esto no es “ruido Kerberos”.
Es movimiento lateral basado en confianza.
8. Auditoría periódica imprescindible
Checklist mínimo que toda organización debería ejecutar:
- Enumerar todas las cuentas con:
TrustedForDelegationTrustedToAuthForDelegation
- Revisar
msDS-AllowedToDelegateTo - Documentar por qué existe cada delegación
- Eliminar delegaciones huérfanas
👉 Si no está documentado, es deuda de seguridad.
9. Lección estratégica final
Este ataque demuestra algo fundamental sobre Active Directory moderno:
La seguridad del dominio no depende solo de parches,
sino del modelo de confianza entre identidades y servicios.
Un dominio puede estar:
- actualizado,
- monitorizado,
- protegido por EDR,
y aun así ser comprometido si una sola cuenta de servicio confía demasiado.
Cierre del artículo
Kerberos no fue explotado.
Kerberos no falló.
Kerberos obedeció exactamente las reglas que se le dieron.
La pregunta no es si el protocolo es seguro.
La pregunta es:
¿Tu Active Directory confía en las entidades correctas?
