La delegación de Kerberos ya se conoce como una expansión de la superficie de ataque local habitual. Nuestra última... Investigación sobre la vulnerabilidad de la delegación de Kerberos realizada por Eliran Partush (CVE-2025-60704) es un gran ejemplo de cómo se puede aprovechar la delegación para la elevación de privilegios (EoP) de un usuario débil a administrador de dominio.
Una suposición común que aún vemos en el campo es que el riesgo de delegación es "una cuestión del usuario". Si un usuario se considera sensible, la delegación debería deshabilitarse para esa cuenta y el problema estaría resuelto. En esta publicación, mostraremos por qué esa suposición es incompleta: Delegación Kerberos en Active Directory Se aplica también a las cuentas de computadora. Esto significa que un servicio confiable para delegación puede actuar no solo en nombre de otros usuarios, sino también en nombre de cuentas de máquinas, las identidades no humanas (NHI) más críticas en cualquier dominio.
El riesgo es evidente. Si un adversario aprovecha la delegación, puede actuar en nombre de cuentas de equipos sensibles, que en muchos entornos tienen privilegios equivalentes a los de un administrador de dominio.
Resumen ejecutivo
- La delegación no se limita a los usuarios. Se pueden delegar cuentas de computadora en nombre de, incluidas identidades de máquinas altamente privilegiadas, como controladores de dominio.
- La interfaz de usuario ADUC crea un punto ciego peligroso. La casilla "La cuenta es confidencial y no se puede delegar" existe para los objetos de usuario, pero no para los objetos de equipo. No se muestra la pestaña "Cuenta" para los equipos.
- La protección todavía existe bajo el capó. La función ANUNCIOS_UF_NO_DELEGADOS un poco en Control de cuenta de usuario Se puede configurar en cuentas de computadora mediante PowerShell.
- Se trata de una brecha de endurecimiento generalizada. Según nuestros datos de investigación, rara vez vemos cuentas de máquinas sensibles protegidas explícitamente contra la delegación.
Informe técnico
CVE-2025-60704: Fallos de validación en Windows Kerberos S4U: de la transición de protocolo a la escalada de privilegios
TL; DR
Marcar cuentas de máquinas sensibles como no delegables:
PowerShell
Set-ADAccountControl -Identidad “HOST01$” -CuentaNoDelegada $true
La delegación no es una característica marginal
La delegación Kerberos es un mecanismo de plano de control común que se utiliza para preservar la identidad en todos los niveles cuando un componente front-end debe acceder a un servicio back-end que aplica la autorización en el contexto del llamador.
La Inscripción Web de CA es un ejemplo representativo de delegación restringida que se utiliza para extender la identidad del usuario a un nivel de servicio de back-end que realiza operaciones sensibles. El componente IIS recibe una solicitud de usuario y debe interactuar con el back-end de la CA para enviar las operaciones de inscripción. La delegación restringida permite a la CA recibir un ticket Kerberos que representa al usuario solicitante para que la emisión del certificado se pueda autorizar mediante la identidad del dominio, la pertenencia a grupos, los permisos de plantilla y la política de emisión.
Este patrón aparece en todas partes. El doble salto de Kerberos de SQL Server, donde un servidor de aplicaciones front-end consulta a un back-end de SQL en nombre del usuario que realiza la llamada, es una de las configuraciones de delegación restringida más comunes en entornos empresariales. La mayoría de los administradores de AD la han configurado al menos una vez.
La delegación es poderosa, común y está profundamente arraigada en las arquitecturas reales. Por eso también se manifiesta en los ataques.
La trampa de la interfaz de usuario: “Sensible y no se puede delegar” no existe para las computadoras
En la delegación Kerberos, un servicio confiable para la delegación puede solicitar tickets en nombre de cualquier usuario o cuenta de equipo de forma predeterminada. Para evitar que se deleguen cuentas de usuario sensibles, existe un método sencillo a través de la interfaz de usuario: active la opción "La cuenta es sensible y no se puede delegar" y el usuario estará protegido.
Sin embargo, este método sencillo no está disponible para las cuentas de ordenador. La consola ADUC no muestra una pestaña "Cuenta" para las cuentas de ordenador, y hay muy poca documentación o conocimiento diario de que la misma protección se aplica a los ordenadores.
Esto crea un punto ciego práctico. Las organizaciones refuerzan el acceso a usuarios privilegiados, pero las máquinas sensibles suelen seguir siendo delegables porque los administradores no reciben una indicación clara en la interfaz de usuario, y la mayoría de las directrices se centran exclusivamente en las cuentas de usuario.
Lo que estamos viendo en la naturaleza
Este problema es especialmente preocupante porque no es infrecuente. Según los datos de nuestra investigación, rara vez vemos cuentas de máquinas sensibles protegidas explícitamente contra la delegación, lo que lo convierte en una brecha de seguridad generalizada.
En otras palabras, muchos entornos aún tienen al menos una identidad de máquina sensible en cuyo nombre se puede delegar, a menudo sin ninguna conciencia operativa de que falta la protección.
Silverfort Los clientes ya han sido alertados sobre esta configuración incorrecta y tienen la visibilidad y los pasos de solución necesarios para abordarla en sus entornos.
Demostración: FIdentidad de máquina sensible a ROM Sincronización DC
Para demostrar el peligro de la delegación de cuentas de máquinas sensibles, explotamos CVE-2025-60704 contra un entorno con la inscripción web de AD CS habilitada.
El ataque combina dos técnicas en dos capas de protocolo diferentes. En la capa HTTP, modificamos la solicitud de inscripción del certificado para especificar la plantilla DomainController. Esta plantilla no aparece en las opciones disponibles de la interfaz de inscripción web, pero el punto final de la CA subyacente la acepta, lo que nos permite solicitar un certificado de clase DC que el administrador podría no saber que es accesible mediante la inscripción web.
En la capa Kerberos, el servicio de inscripción web realiza una delegación restringida al controlador de dominio en nombre del usuario solicitante. Al realizar un ataque de adversario en el medio en ese flujo de delegación (CVE-2025-60704)Aprovechamos el paso criptográfico faltante para escalar desde una identidad de usuario débil a la identidad de la máquina del controlador de dominio.
Con el certificado del controlador de dominio en la mano, demostramos el dominio del dominio a través de una ruta DCSync.
Esta cadena de ataques refuerza un patrón: la interfaz de usuario te oculta información. La casilla NOT_DELEGATED está oculta para las cuentas de equipo. La plantilla DomainController está oculta para la interfaz de registro web. La brecha criptográfica en el flujo de delegación está oculta para cualquiera que asumiera que el protocolo protegía la integridad. Tres puntos ciegos y una ruta para comprometer el dominio.
Bandera NOT_DELEGATED bajo el capó
La casilla de verificación de la interfaz de usuario para los usuarios establece en última instancia el bit NOT_DELEGATED en Control de cuenta de usuario:
- ANUNCIOS_UF_NO_DELEGADOS = 0x00100000 (1048576)
Aquí está el punto clave: Control de cuenta de usuario Existe tanto en objetos de usuario como de computadora. Por lo tanto, aunque ADUC no exponga la casilla de verificación para computadoras, la protección existe y funciona al aplicarse a las identidades de máquina.
Si aplicamos el atributo NOT_DELEGATED a una cuenta de computadora, la cuenta está protegida: las solicitudes de S4U2Proxy dirigidas a esa cuenta fallarán, que es exactamente lo que queremos para las máquinas de nivel 0.
¿Qué cuentas de máquinas deben considerarse sensibles?
Cualquier cuenta de equipo de nivel 0 debe considerarse confidencial y debe protegerse de la delegación. En la práctica, esto incluye:
- Controladores de dominio y otra infraestructura de nivel 0
- Servidores PKI y AD CS y niveles de inscripción
- ADFS, Entra Connect y servidores de puente de identidad híbridos
- Infraestructura de identidad y sistemas de gestión del plano
- Cuentas de máquina con permisos de clase de replicación (categoría de riesgo DCSync)
- Cuentas de máquina que pueden restablecer contraseñas o modificar identidades privilegiadas (autoridad de estilo de administrador de sombra)
Si una identidad de máquina (NHI) puede controlar la identidad, es sensible.
Seguridad de la identidad no humana
Cada NHI: a la vista y bajo control
- Descubra automáticamente todos los NHI en sus entornos.
- Mapear sus actividades y establecer líneas de base.
- Imponer control y cercar su actividad.
Mitigación
La mitigación es sencilla y requiere un solo comando de PowerShell, como documenta Microsoft. Un pequeño cambio como este puede eliminar todo un tipo de riesgo de delegación y una posible superficie de ataque.
Para cada cuenta de máquina sensible, ejecute:
PowerShell
Set-ADAccountControl -Identidad “HOST01$” -CuentaNoDelegada $true
Luego, supervise y valide que no haya fallas. Activar esta opción provocará que las solicitudes de S4U2Proxy dirigidas a la cuenta protegida fallen, lo que significa que cualquier servicio legítimo con delegación restringida para interactuar con esta máquina en nombre de otras identidades dejará de funcionar. Antes de cambiar de estrategia, audite su... msDS-PermitidoDelegarA y el msDS-AllowedToActOnBehalfOfOtherIdentity configuraciones para comprender qué servicios pueden verse afectados.
Si algo falla, investigue qué aplicación o servicio intenta delegar en nombre de una cuenta de equipo de nivel 0 y determine si ese comportamiento es esperado y aceptable. En muchos casos, descubrir que un servicio estaba delegando en nombre de un controlador de dominio es en sí mismo un hallazgo que vale la pena investigar.
Pensamientos de cierre
Todos hemos interiorizado el “no delegar usuarios sensibles”. La diferencia es que las identidades sensibles de las máquinas a menudo no reciben el mismo tratamiento., porque la interfaz de usuario no lo hace obvio y hay muy poca documentación o conciencia de que el mismo control se aplica a las cuentas de computadora.
Esta publicación destacó tres puntos donde la interfaz de usuario oculta riesgos a los administradores: la ausencia de la casilla NOT_DELEGATED en los equipos, las plantillas de certificado no expuestas en la inscripción web y el flujo de delegación sin protección que posibilitó la CVE-2025-60704. El patrón es consistente: lo que no se ve en la consola probablemente no se haya reforzado.
Teniendo en cuenta la cantidad de control que el plano empresarial moderno tiene impulsado por identidades de máquinaEste es un paso de fortalecimiento de alto nivel: identifique las cuentas de sus máquinas sensibles, configúrelas como no delegables y conviértalas en parte de su línea base de Nivel 0.
Obtenga más información sobre los riesgos de seguridad de la identidad no humana y lo que puede hacer al respecto en nuestro último informe de investigación. "Inseguridad en las sombras."
Reportes