Ataques de Delegacion Kerberos: de No Restringida a Abuso RBCD

Que Son los Ataques de Delegacion Kerberos?

Los ataques de delegacion Kerberos abusan de funciones legitimas de delegacion en Active Directory que permiten a un servicio acceder a otro servicio en nombre de un usuario. La delegacion existe para flujos de aplicacion reales, como una capa web que se conecta a una capa de base de datos con la identidad del usuario. El problema de seguridad comienza cuando el alcance de la delegacion es mas amplio de lo que la aplicacion realmente necesita, o cuando un atacante puede modificar la relacion de delegacion.

Los tres modelos de delegacion que los defensores normalmente deben revisar son:

• Delegacion no restringida, donde un servicio de confianza puede recibir material Kerberos delegable y usarlo mas alla de un unico servicio backend.
• Delegacion restringida, donde el servicio frontend esta limitado a nombres de principal de servicio especificos listados en Active Directory.
• Delegacion restringida basada en recursos (RBCD), donde el recurso objetivo controla que principals pueden actuar en nombre de usuarios hacia ese recurso.

Estos modelos no deben tratarse como riesgo equivalente. La delegacion no restringida suele ser la maxima prioridad porque el compromiso del host delegado puede exponer credenciales delegadas reutilizables. La delegacion restringida y RBCD tambien pueden ser peligrosas, especialmente cuando los servicios permitidos son demasiado amplios o cuando permisos de escritura permiten a un atacante cambiar los atributos de delegacion.

Como Funciona la Delegacion Kerberos

La delegacion Kerberos extiende la autenticacion de servicio Kerberos normal. En un flujo Kerberos estandar, un usuario obtiene un ticket-granting ticket del Key Distribution Center (KDC) y luego solicita tickets de servicio para servicios especificos. La delegacion agrega la capacidad de que un servicio obtenga o use tickets en nombre del usuario para otro servicio.

Con la delegacion no restringida, la cuenta o el equipo esta marcado como de confianza para delegacion. Si un usuario se autentica ante ese servicio con la delegacion habilitada, el servicio puede recibir material Kerberos delegable. Si el host es comprometido, el atacante puede reutilizar ese acceso delegado. Por eso Microsoft Defender for Identity trata la delegacion Kerberos no restringida como un elemento de evaluacion de seguridad: la configuracion puede exponer credenciales privilegiadas cuando usuarios sensibles se autentican ante servicios delegados.

La delegacion restringida reduce el alcance. En lugar de permitir delegacion hacia cualquier servicio, la cuenta solo puede delegar hacia servicios configurados, representados por valores como msDS-AllowedToDelegateTo. El protocol transition cambia el riesgo de nuevo porque el servicio puede obtener un ticket delegado para un usuario sin que ese usuario se haya autenticado previamente por Kerberos ante ese servicio frontend, cuando esta configurado para usar cualquier protocolo de autenticacion.

RBCD invierte parte del modelo administrativo. El recurso almacena la lista de principals autorizados a actuar en nombre de usuarios hacia ese recurso en msDS-AllowedToActOnBehalfOfOtherIdentity. Esto hace que RBCD sea util para algunos escenarios de aplicacion, pero tambien significa que el control de escritura sobre un objeto de equipo puede convertirse en una via de delegacion.

Condiciones Previas Que Permiten el Abuso de Delegacion

Las configuraciones de delegacion no son automaticamente explotables por si solas. Los casos peligrosos suelen combinar varias condiciones:

• un servidor o cuenta de servicio esta configurado para delegacion no restringida y es mas facil de comprometer que los usuarios que se autentican ante el
• usuarios privilegiados o Domain Controllers se autentican ante sistemas que pueden recibir credenciales delegadas
• los objetos de equipo tienen ACLs debiles que permiten a principals no administrativos modificar atributos relacionados con delegacion
• las cuentas de servicio tienen objetivos de delegacion restringida demasiado amplios que ya no coinciden con la necesidad de la aplicacion
• existen entradas RBCD sin propietario documentado, dependencia de aplicacion o proceso de expiracion
• los Domain Controllers exponen rutas de coercion que provocan que la autenticacion de cuentas de equipo llegue a sistemas donde el material delegado puede capturarse o reutilizarse

La conclusion defensiva es practica: una revision de delegacion no es solo una lista de atributos. Debe incluir hardening de hosts, rutas de inicio de sesion de cuentas privilegiadas, ACLs de objetos y ownership de aplicaciones.

La Cadena de Ataque

Un ataque de delegacion normalmente sigue una secuencia en lugar de un evento unico.

1. El atacante identifica equipos o cuentas de servicio configurados para delegacion.
2. El atacante compromete un host delegado, una cuenta de servicio o una identidad con acceso de escritura sobre un objeto de equipo.
3. El atacante espera o induce la autenticacion de una cuenta valiosa, o modifica RBCD para que un principal controlado por el atacante pueda hacerse pasar por usuarios ante un recurso objetivo.
4. El atacante reutiliza el acceso delegado resultante para alcanzar un servicio mas sensible.
5. Si la ruta alcanza permisos de replicacion de Domain Controller, sistemas Tier-0 o servicios administrativos privilegiados, el ataque puede convertirse en compromiso total del dominio.

Para la delegacion no restringida, los casos mas graves involucran cuentas privilegiadas o cuentas de equipo de Domain Controller autenticandose ante un servidor delegado comprometido. Para RBCD, la pregunta clave es distinta: quien puede escribir el atributo de delegacion del objeto de equipo objetivo, y la relacion de confianza resultante coincide con una dependencia de aplicacion legitima?

Deteccion

Ningun evento de Windows por si solo prueba un ataque de delegacion Kerberos. La deteccion surge de correlacionar el inventario de delegacion, cambios de objetos, actividad de tickets de servicio Kerberos, eventos de inicio de sesion y telemetria de hosts.

Señales del Inventario de Delegacion

Comience con datos de configuracion:

• cuentas o equipos con delegacion no restringida habilitada
• cuentas con TrustedToAuthForDelegation habilitado
• valores msDS-AllowedToDelegateTo poblados
• valores msDS-AllowedToActOnBehalfOfOtherIdentity poblados
• cuentas privilegiadas no marcadas como sensibles y por lo tanto todavia elegibles para rutas de delegacion
• ACLs debiles en objetos de equipo que permiten a principals inesperados escribir atributos relacionados con delegacion

El inventario por si solo no es suficiente, pero da a las detecciones el contexto que necesitan. Un evento 4769 de ticket de servicio es mas significativo cuando se sabe que la cuenta de servicio esta configurada para delegacion riesgosa.

Eventos de Windows a Correlacionar

El evento 5136 requiere la politica de auditoria y la cobertura SACL correctas. Microsoft documenta que se genera cuando se modifica un objeto de Active Directory, pero una deteccion util depende de conservar los detalles de objeto, atributo y operacion.

Patrones de Deteccion de Alta Señal

Priorice estas detecciones antes de escribir reglas de anomalia amplias:

• un valor msDS-AllowedToActOnBehalfOfOtherIdentity nuevo o modificado en un objeto de equipo
• delegacion no restringida habilitada en un sistema que no es DC
• una cuenta privilegiada autenticandose ante un sistema configurado para delegacion no restringida
• actividad de inicio de sesion de cuentas de equipo de Domain Controller hacia servidores miembro inesperados
• cambios de atributos relacionados con delegacion realizados por cuentas que no son propietarias de la aplicacion
• entradas RBCD donde el principal actuante es de creacion reciente, se usa rara vez o no esta relacionado con el servicio objetivo

La alerta debe incluir ambos lados de la relacion: la cuenta o equipo autorizado a delegar, y el servicio o recurso hacia el que se delega.

Remediacion

Trate la delegacion no restringida en sistemas que no son DC como un hallazgo de alta prioridad. Si una aplicacion todavia necesita delegacion, migre a un modelo mas estrecho y demuestre que la lista de objetivos es correcta.

1. Eliminar la Delegacion No Restringida Donde Sea Posible

Identifique equipos y cuentas de confianza para delegacion no restringida, confirme el ownership de la aplicacion y elimine la configuracion de sistemas que no tengan un requisito de negocio vigente.

Get-ADComputer -Filter {TrustedForDelegation -eq $true} -Properties TrustedForDelegation |
  Select-Object Name, DistinguishedName, TrustedForDelegation

No deshabilite la delegacion a ciegas en servidores de aplicacion de produccion sin probar. Algunas aplicaciones legacy pueden depender de la delegacion para la autenticacion de usuario a backend. La ruta de remediacion segura es: inventario, confirmacion del propietario, staging, cambio y validacion.

2. Reducir el Alcance de la Delegacion Restringida

Para servicios que todavia necesitan delegacion, restrinja los servicios objetivo permitidos al conjunto viable mas pequeño. Revise los valores de msDS-AllowedToDelegateTo y elimine SPNs obsoletos. Si el protocol transition esta habilitado, verifique que la aplicacion realmente lo necesita y que la cuenta de servicio esta protegida como una identidad privilegiada.

3. Revisar y Limpiar RBCD

Para RBCD, revise cada valor msDS-AllowedToActOnBehalfOfOtherIdentity poblado. Cada entrada debe corresponder a una dependencia de aplicacion documentada. Si la entrada existe solo porque una solucion de problemas la requirio hace meses, eliminela. Tambien revise quien puede escribir sobre el objeto de equipo objetivo, porque el control de escritura suele ser la vulnerabilidad real.

4. Proteger las Cuentas Privilegiadas de la Exposicion por Delegacion

Los usuarios privilegiados no deberian autenticarse de forma interactiva en servidores de menor confianza. Use administracion por niveles, estaciones de trabajo de administracion dedicadas y restricciones de inicio de sesion para que las credenciales Tier 0 no terminen en hosts delegados. Para cuentas sensibles, revise la configuracion de la cuenta y el modelo operativo que previene la exposicion por delegacion.

5. Reducir la Exposicion a Coercion en los Domain Controllers

Si el servicio Print Spooler no es necesario en los Domain Controllers, deshabilitarlo elimina una via de autenticacion de cuenta de equipo bien conocida usada en cadenas de abuso de delegacion. Trate esto como una capa, no como la unica solucion. El problema raiz sigue siendo la delegacion insegura y la exposicion de credenciales.

Validacion Despues de la Remediacion

La remediacion de delegacion no esta completa hasta que valide tanto la seguridad como el comportamiento de la aplicacion:

• confirme que los sistemas que no son DC ya no tienen delegacion no restringida a menos que este explicitamente aprobada
• confirme que los SPN objetivo de delegacion restringida restantes coinciden con el diseño de la aplicacion
• confirme que las entradas RBCD tienen propietarios documentados y ningun principal actuante inesperado
• pruebe el flujo de la aplicacion que anteriormente requeria delegacion
• supervise el evento 5136 para detectar nuevas escrituras de atributos de delegacion despues de la limpieza
• supervise los inicios de sesion privilegiados hacia hosts delegados durante al menos una ventana de cambio despues de la remediacion
• revise las ACLs de objetos de equipo para asegurar que los atacantes no puedan reconstruir la ruta de delegacion

La pregunta final de validacion es simple: si un atacante compromete el mismo servidor de aplicacion mañana, todavia podria recolectar o crear acceso delegado hacia un recurso de mayor confianza?

Como Detecta Esto EtcSec

EtcSec audita las configuraciones de delegacion en equipos y cuentas de servicio en cada escaneo de AD.

UNCONSTRAINED_DELEGATION identifica sistemas y cuentas configurados para delegacion no restringida.

CONSTRAINED_DELEGATION destaca configuraciones de delegacion restringida riesgosas o demasiado amplias.

RBCD_ABUSE revela relaciones de delegacion restringida basada en recursos que merecen revision porque pueden ofrecer una ruta de suplantacion inesperada.

Controles Relacionados

La revision de delegacion debe hacerse junto a Deteccion prevencion kerberoasting: como identificar y proteger cuentas de servicio crackeables, Abuso ACL y DCSync: Las Rutas Silenciosas hacia Domain Admin, Supervision Seguridad AD: Event IDs y SIEM, Malas configuraciones GPO como vector de ataque y Ataque Golden Ticket — Deteccion & Remediacion. En entornos reales, estas rutas suelen encadenarse en lugar de explotarse de forma aislada.

Fuentes Primarias

• Microsoft Defender for Identity: evaluacion de la postura de seguridad de cuentas (delegacion Kerberos insegura)
• 5136: se modifico un objeto del servicio de directorio
• 4738: se cambio una cuenta de usuario
• Configurar la auditoria de eventos de Windows para Microsoft Defender for Identity
• Delegacion restringida Kerberos con Microsoft Entra ID (application proxy)