Eliran Partush
Investigador de seguridad, Silverfort
La delegación restringida de Kerberos es el mecanismo de suplantación de Kerberos, que se utiliza cuando un servicio o aplicación necesita actuar en nombre de un usuario.
En julio de 2025, encontré problemas interesantes en la forma en que Windows aplica controles de integridad dentro del subprotocolo de suplantación.
En concreto, la compatibilidad heredada con RSA-MD4, combinada con la ausencia de un paso de validación criptográfica en el lado del cliente de una de estas comprobaciones de integridad, permitió manipular campos que debían protegerse, incluida la identidad del usuario suplantado.
En las condiciones adecuadas, este comportamiento se puede utilizar de forma abusiva para eludir los supuestos de confianza de la delegación, lo que conduce a Acceso no autorizado escalada de privilegios.
Kerberos y delegación: antecedentes
Kerberos es un protocolo de autenticación de red basado en primitivas criptográficas robustas. Su objetivo principal es proporcionar... autenticacion mutua, permitiendo que tanto el usuario como la aplicación verifiquen la identidad de cada uno.
La suplantación de identidad ha existido en Kerberos durante mucho tiempo. La especificación original de Kerberos del MIT introdujo un mecanismo de delegación en RFC 4120 (2005) – lo cual, en la práctica, era esencialmente pasar el boleto como característica.
Microsoft decidió implementar la delegación de forma diferente. Con la introducción de Servicio para el usuario (S4U) in Windows Server 2008, y mejoras posteriores en Windows Server 2012Microsoft agregó sus propias extensiones de protocolo, incluidas dos formas distintas de Delegación restringida.
Kerberos y su delegación se han abordado ampliamente en blogs e investigaciones. Varios de estos trabajos sirvieron de inspiración y referencias fundamentales para esta investigación:
- Meneando al perro – Elad Shamir
- El RC4 todavía se considera dañino – Proyecto Cero (James Forshaw)
- S4U2Pwnage – harmj0y
En este artículo, omitiré intencionalmente una introducción general a Kerberos y me centraré en la implementación de las extensiones de delegación de Microsoft.
Antes de profundizar en la vulnerabilidad en sí, primero debemos comprender cómo se supone que funcionan estas características.
Delegación Kerberos
La delegación es el mecanismo que permite a un servicio acceder a los recursos en nombre de un usuario. En Active DirectoryLa delegación es la forma en que las aplicaciones de múltiples niveles preservan el contexto de autorización sin copiar credenciales ni implementar suplantación a nivel de aplicación.
La idea básica es simple: un usuario se autentica en Servicio 1 (el frontend), y ese servicio necesita acceder Servicio 2 (el backend) como usuario.
¿Qué pasa con Kerberos “clásico”?
En un flujo Kerberos estándar:
- El usuario se autentica en el frontend y presenta una ticket de servicio.
- El frontend no puede reutilizar ese ticket para autenticarse en el backend porque:
- Las entradas cuestan no reenviable por defecto.
- El billete está encriptado con el clave a largo plazo del frontend, por lo que solo el frontend puede descifrarlo.
Una alternativa sería que el frontend solicitara su propia El ticket de servicio se envía al backend. Sin embargo, esto presenta nuevos problemas:
- El contexto de autorización ya no es del usuario, sino de la cuenta de servicio.
- Desde una perspectiva de seguridad, esto significa que el backend debe confiar plenamente en el frontend.
- Otorgar a un servicio acceso irrestricto a un recurso backend generalmente es inaceptable.
- Las aplicaciones no deberían tener acceso generalizado sólo para “hacer que las cosas funcionen”.
Ejemplo: Inscripción web de CA
Tomemos como ejemplo la aplicación web de CA: https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/configure-kerberos-constrained-delegation.
Primero, el usuario se autentica en IIS, que aloja la interfaz web de Servicios de Certificados. IIS se encarga de emitir un certificado al usuario comunicándose con el backend de la CA mediante RPC.
En este punto:
- IIS contiene el ticket de servicio del usuario.
- IIS ahora necesita autenticarse en RPCSS en la CA como usuario.
Pero el ticket del usuario no puede simplemente reenviarse:
- Está cifrado con la clave de largo plazo de IIS.
- La CA necesita un ticket cifrado con su propia clave para descifrarlo y autenticar al usuario.
Si IIS en cambio se autentica utilizando su propia ticket de servicio:
- El certificado emitido pertenecerá a la cuenta de servicio, no el usuario.
- Como alternativa, la aplicación podría implementar su propia lógica de suplantación, permitiendo a IIS decidir qué certificado emitir.
- Esto lleva las decisiones de autorización sensibles a la lógica de la aplicación.
- No se debe confiar este tipo de privilegios a las aplicaciones.
La solución a este problema es Delegación Kerberos: una forma controlada de suplantación donde el Servicio 1 (el frontend) es explícitamente de confianza actuar en nombre de los usuarios cuando acceden al Servicio 2 (el backend).
Tipos de delegación Kerberos: Sin restricciones / Con restricciones
Hay dos familias principales de delegación Kerberos: Delegación sin restricciones Delegación restringidaSi bien ambos buscan resolver el mismo problema central (permitir que un servicio actúe en nombre de un usuario), lo hacen de diferentes maneras y con distintas implicaciones de seguridad.
Delegación sin restricciones
La delegación sin restricciones se basa en la está bien delegar bandera y permite que un servicio reciba y reutilice la información del usuario TGT reenviadoEn otras palabras, una vez que se confía en un servicio para una delegación sin restricciones, este efectivamente mantiene el TGT del usuario y puede suplantar al usuario para cualquier servicio en el dominio. Esto hace que la delegación sin restricciones sea eficaz, pero también peligrosa si ese servicio se ve comprometido.
Delegación restringida (KCD)
La delegación restringida adopta un enfoque más controlado. En lugar de entregar el TGT del usuario, se confía en el servicio frontend. Suplantar a los usuarios solo ante servicios backend específicos mediante el uso un ticket de servicio reenviable.
Delegación restringida basada en recursos (RBCD)
RBCD es la última evolución de KCD donde el recurso objetivo controla qué servicios pueden delegarlo, en lugar de configurar permisos de delegación en la cuenta de servicio del frontend.
KCD y RBCD reducen significativamente la superficie de ataque en comparación con la delegación sin restricciones, al menos en teoría.
Para más detalles, siga este enlace: https://www.silverfort.com/glossary/kerberos-delegation/.
Tanto KCD como RBCD son implementaciones de Microsoft de la extensión del protocolo Kerberos MS-SFU.
Extensión del protocolo de servicio para usuario de Microsoft
Microsoft Servicio para el usuario (S4U) Las extensiones de protocolo definen dos mecanismos relacionados: transición de protocolo delegación restringidaEn este modelo, un servicio utiliza su propio TGT para solicitar tickets Kerberos especiales que incorporen un principal de usuario, mientras que KDC sigue siendo responsable para hacer cumplir la política de delegación basada en Active Directory configuración.
Las extensiones S4U introducen dos subprotocolos TGS:
S4U2Self (Servicio del usuario a sí mismo)
S4U2Self es un subprotocolo TGS-REQ utilizado para transición de protocoloFue diseñado para abordar escenarios donde el usuario final no se autentica en una aplicación que utiliza Kerberos, pero la aplicación aún necesita obtener tickets Kerberos que representen la identidad del usuario.
S4U2Proxy (Servicio de usuario a proxy)
S4U2Proxy es un subprotocolo TGS-REQ que se utiliza para realizar delegación restringidaSu finalidad es obtener una ticket de servicio reenviable a un servicio posterior en nombre de un usuario, utilizando evidencia de autenticación previamente establecida.
Estos dos subprotocolos actúan como mecanismos independientes y pueden utilizarse por separado. Sin embargo, en la práctica, suelen ser... Unidos entre sí, con S4U2Self produciendo un ticket de evidencia que luego es consumido por S4U2Proxy para completar el acceso delegado.
S4U2Proxy – Delegación restringida
Solicitud TGS de S4U2Proxy es el mensaje de delegación restringida real. El servicio solicita un ticket a un servidor descendente. SPN objetivo En nombre de ese usuario, proporciona su ticket como prueba. El KDC aplica la política de delegación (KCD o RBCD) y, si se permite, emite un ticket descendente cuya identidad de cliente se deriva del ticket de prueba.
A diferencia de una solicitud TGS normal, S4U2Proxy debe proporcionar inicial Que el usuario ya ha sido autenticado. Esta evidencia puede obtenerse de dos maneras:
- De un ticket de servicio presentado originalmente por el usuario (cuando se utilizó la autenticación Kerberos), o
- De un ticket de servicio obtenido a través de S4U2Self.
S4U2Proxy se implementa como una versión modificada TGS-REQ y TGS-REP e introduce cambios en la Opciones de KDC, PA-DATOS, PAC entradas adicionales.
Parámetros clave de S4U2Proxy TGS-REQ
- El sistema Opción KDC delegación restringida (también conocida como cname-in-addl-tkt) se debe establecer.
- Esta bandera le indica al KDC que extraiga el identificador principal del cliente (cname) desde el billete adicional, en lugar de desde el autenticador, como en un TGS-REQ normal.
- Uno o mas entradas adicionales debe ser incluido
- Este ticket representa al usuario autenticado.
- (Opcional) El cliente puede incluir OPCIONES PA-PAC solicitar:
- Delegación restringida basada en recursos (RBCD)
- Autorización basada en reclamaciones
En esta etapa, el KDC valida tanto la permisos de delegación del servicio solicitante y el integridad del ticket de evidencia.
Ejemplo: S4U2Proxy TGS-REQ
S4U2Proxy TGS-REP
La resultante TGS-REP Parece un ticket de servicio solicitado directamente por el usuario. Sin embargo, se inyectan metadatos de autorización adicionales en el PAC.
En concreto, el KDC añade un INFORMACIÓN DE LA DELEGACIÓN S4U estructura que contiene dos campos críticos:
- Objetivo proxy S4U2 – el SPN del servicio de destino
- Servicios de tránsito S4U – la cuenta que se hizo pasar por el usuario
Esta información está destinada a ser validado por la aplicación recibir el ticket, permitiéndole entender que está siendo suplantado y ¿Qué servicio realizó la delegación?.
Ejemplo: S4U2Proxy TGS-REP
Como se mencionó anteriormente, si el usuario autenticó la aplicación utilizando un protocolo que no sea Kerberos, el ticket de evidencia debe solicitarse utilizando el protocolo S4U2Self.
S4U2Self – Transición de protocolo
S4U2Self es un Subprotocolo TGS-REQ Se utiliza para la transición de protocolo. Fue diseñado para abordar casos en los que el usuario final... No autenticarse en la aplicación mediante Kerberos, pero la aplicación aún necesita obtener tickets de servicio Kerberos para los recursos posteriores en el contexto de seguridad del usuario.
En términos prácticos, una vez que una cuenta de servicio se configura con TRUSTED_TO_AUTH_FOR_DELEGATION Control de cuenta de usuario bandera, el dominio confía explícitamente en ese servicio autenticar usuarios en su nombre, en lugar de confiar en el controlador de dominio para realizar la autenticación inicial.
Esta confianza permite que el servicio solicite una S4U2Boleto de autoservicio que representa la identidad del usuario, aunque no se realizó ninguna autenticación Kerberos entre el usuario y el servicio.
Parámetros clave de S4U2Self TGS-REQ
Una solicitud S4U2Self se diferencia de una solicitud TGS normal en algunos aspectos importantes:
- El sistema quitarse el campo se establece en yo (por ejemplo: machineaccount1$).
- El TGT y el autenticador cname Las identidades también representan la cuenta de confianza.
En este punto, el servicio aún debe especificar qué usuario pretende suplantarDado que no se produjo ninguna autenticación Kerberos entre el usuario y el servicio, la identidad del usuario no se puede derivar del propio ticket.
Esto se hace utilizando uno de dos Datos de preautenticación (PA-DATA) estructuras:
- PA-PARA-USUARIO – identificación basada en nombre de usuario
- PA-PARA-X509-USUARIO – identificación basada en certificados
Ejemplo: S4U2Self TGS-REQ
En la siguiente sección, entenderemos la diferencia entre esas estructuras de datos y descubriremos la debilidad.
PA-DATA TYPE 129: PA-FOR-USER – Identificación basada en nombre de usuario
Esta es la estructura PA-DATA simple y más comúnmente utilizada.
Todos los campos son obligatorios:
- userName.type – el valor predeterminado es 0 (NT-DESCONOCIDO)
- userName.name-string – nombre de usuario o UPN
- userRealm – el reino del usuario
- paquete de autenticación: la cadena “Kerberos”
La suma de comprobación (cksum) se calcula sobre todos los campos anteriores de la siguiente manera:
S4UByteArray =
(LE 4-Byte int) userName.type +
userName string +
userRealm string +
“Kerberos” An HMAC-MD5 Luego, la suma de comprobación se calcula utilizando:
- El sistema Clave de sesión TGT
- Número de uso de la clave 17 (BORDILLO_SIN_BORDILLO_CKSUM_SALT)
- El S4UByteArray
cksum = HMAC-MD5(SessionKey, 17, S4UByteArray) Este diseño garantiza que un atacante debe conocer la Clave de sesión TGT para modificar cualquier campo de la estructura.
Y si un atacante ya tiene la clave de sesión, bueno, tienes un problema diferente:
PA-DATA TYPE 130: PA-FOR-X509-USER – Identificación basada en certificado
Esta estructura de datos es más compleja y significativamente más interesante desde una perspectiva de seguridad.
Consta de dos componentes principales:
- ID de usuario (ID de usuario S4UU), que contiene la información de identidad del usuario
- Checksums, cuyo objetivo es proporcionar protección de la integridad
Identificación de usuario (S4UUserID)
El sistema ID de usuario de S4UU La estructura contiene la información de identidad en la que el KDC confiará en última instancia.
Campos obligatorios:
- nuncio apostólico: Copiado del cuerpo de la solicitud de KDC
- crema: El reino del usuario
Campos opcionales:
cname Si se omite, se debe proporcionar un certificado. Si no se incluye cname, el KDC extrae la identidad del usuario de las extensiones del certificado.
certificado de asignatura: Codificado DER certificado de clave pública X509
opciones:Banderas adicionales:
Checksums
La suma de comprobación se calcula sobre la estructura de identificación de usuario codificada en DER (S4UUserID).
A diferencia de PA DATA 129, donde la suma de comprobación siempre tiene la clave HMAC-MD5 codificada con la clave de sesión del TGT, aquí el tipo de suma de comprobación Depende del tipo de cifrado de la clave de sesión TGT(!)
Por ejemplo:
- Si el tipo de clave de sesión TGT es AES256-CTS-HMAC-SHA1-96 (18), El tipo de suma de comprobación será HMAC-SHA1-96-AES-256 (16)
- Si el tipo de clave de sesión TGT es AES128-CTS-HMAC-SHA1-96 (17), El tipo de suma de comprobación será HMAC-SHA1-96-AES-128 (15)
Sin embargo, cuando se utiliza un tipo de cifrado más antiguo, “no más nuevo”, legado suma de comprobación Se puede utilizar el algoritmo.
Por ejemplo:
- Si el tipo de clave de sesión TGT es RC4-HMAC-NT (23), Entonces el tipo de suma de comprobación puede ser RSA-MD4 (2)
Las sumas de comprobación basadas en HMAC son enchavetado, lo que significa que su integridad depende de material secreto que solo conocen las partes comunicantes. En contraste, RSA-MD4 es un sin clave suma de comprobación.
Según RFC3961, comprobación de integridad del mensaje RSA-MD4 (MIC) es simplemente md4(mensaje) – no hay clave de sesión involucrada.
Las sumas de comprobación sin clave no ofrecen resistencia a la manipulación y no son adecuadas para proteger estructuras de texto plano. Por esta razón, no se recomienda su uso y solo existe para compatibilidad con versiones anteriores.
En el contexto de S4U, las estructuras PA-DATA resultantes son lo suficientemente flexibles para soportar ambas basado en certificados basado en nombre de usuario afirmaciones de identidad para S4U2SelfEn la práctica, estas estructuras pueden coexistir y, en algunos escenarios, incluso transmitirse juntas.
Por qué esto es importante
El punto clave es que No se requieren credenciales de usuario para obtener un ticket Kerberos en nombre de un usuario. La única entrada necesaria para afirmar la identidad de un usuario es un cadena de nombre de usuario.
En un flujo S4U, esa cadena es no protegido criptográficamente contra modificaciones por parte de un atacante.
Esto significa que si un atacante puede controlar esa cadena, puede controlar el flujo de suplantación. El ticket resultante se propaga luego a Proxy S4U2, que confía ciegamente en el resultado de S4U2Self. A partir de ese momento, la cadena de delegación continúa según lo previsto.
Para abordar esta debilidad, Microsoft intentó introducir medidas de seguridad compensatorias.
En el lado del cliente (aplicación):
- Cuando un “no más nuevo” Se utiliza la clave de sesión TGT únicamente PA-DATOS 129 Está permitido.
- PA-PARA-X509-USUARIO no se envía.
- Como resultado, Las sumas de comprobación basadas en MD4 no deberían aparecer en la solicitud.
En el lado del servidor (KDC):
- Al MD4 se utiliza, tanto el solicita responder Los valores de suma de comprobación se incluyen dentro del porción cifrada de la respuesta del KDC.
- Estos valores se devuelven al cliente, que se espera que verifique ambos como una verificación de integridad compensatoria.
CVE-2025-60704 Parte I: Suma de comprobación sin clave habilitada para degradación en PA-S4U-X509-USER
Visión general primitiva
El primer primitivo es la capacidad de forzar la Afirmación de identidad propia basada en certificado S4U2 en un legado, modo de suma de comprobación sin clave.
Esto se vuelve relevante para la seguridad porque la suma de comprobación que protege el ID de usuario de S4UU La estructura se selecciona en función de la tipo de cifrado negociado para la clave de sesión TGT del servicio. Si esa negociación resulta en RC4, la suma de comprobación utilizada por PA-S4U-X509-USUARIO puede degradarse a RSA-MD4, que no proporciona ninguna clave criptográfica.
Una vez que esto sucede, se pierde efectivamente la protección de la integridad de la identidad del usuario declarado.
Paso 1: Reducir el tipo de cifrado TGT mediante Machine-in-the-Middle (MITM)
Para llegar a la ruta del código MD4, necesitamos inyectar nuestro código de mutación en la ruta entre la aplicación (lo llamaremos "Cliente” de ahora en adelante) y el KDC (“Server”), y degradar el tipo de cifrado utilizado en el intercambio de Kerberos. Esto significa forzar la AS-REQ negociar RC4-HMAC (tipo e 23).
En Windows, esto resulta sencillo:
- El valor por defecto AS-REQ Se envía en texto plano, sin firma ni sellado.
- El cliente negociará tipos de cifrado más antiguos si la política lo permite.
Después de la modificación, el KDC responde con un AS-REP, y se instala un nuevo TGT en la caché.
Resultado:
La clave de sesión TGT ahora es RC4-HMAC-MD5 (tipo e 23).
Observación del comportamiento del cliente: degradación de la protección contra sumas de comprobación sin clave
Como era de esperar, el comportamiento del cliente para S4U2Auto TGS-REQ cambia cuando RC4 Se utiliza como tipo de cifrado de clave de sesión:
- Sólo PA-DATA 129 (PA-PARA-USUARIO) se ha enviado.
- PA-DATA 129 está codificado para su uso HMAC-MD5.
En este punto, Microsoft restricción del lado del cliente Parece estar funcionando según lo previsto.
Comportamiento del lado del servidor y condición de derivación
Para entender cómo se puede eludir esta restricción, necesitamos examinar la implementación del lado del servidor, específicamente la lógica KDC en KDCSVC!KdcFindS4UClientAndRealm.
Esta función sigue un flujo de decisión simple:
- Primero llama KerbFindPerAuthDataEntry para localizar PA-DATA tipo 130.
- Si no se encuentra PA-DATA 130, se recurre a PA-DATA tipo 129.
- Luego continúa con pasos de validación adicionales.
Este comportamiento tiene una implicación importante. Si Ambos tipos de PA-DATA están presentes, PA-DATA 129 se ignora a favor de PA-DATA 130.
En esta etapa, el KDC no realiza ninguna validación del tipo de cifrado negociado ni impone ninguna restricción sobre qué estructuras PA-DATA son aceptables cuando se utiliza RC4. Dado que tampoco existe un enlace criptográfico ni protección contra manipulaciones entre el tipo de clave de sesión y los PA-DATA utilizados para afirmar la identidad, un atacante puede inyectar un código manipulado. PA-DATA tipo 130 Incluso en un intercambio basado en RC4.
En otras palabras, aunque el cliente no enviará PA-DATA 130, nada impide que un atacante lo agregue.
Paso 2: Inyección de PA-DATA 130
En este punto, un adversario intermediario puede inyectar una cantidad adicional. PA-S4U-X509-USER (tipo 130) elemento en el S4U2Auto TGS-REQ.
El PA-DATA inyectado codifica una identidad elegida por el atacante dentro del ID de usuario de S4UU Estructura. Esto se puede hacer, por ejemplo, configurando explícitamente:
- cname a la cuenta de destino
- crema al dominio de destino
Se pueden incluir u omitir otros campos opcionales según el modo de construcción.
Como la suma de comprobación ahora no tiene clave, su cálculo es simple:
Checksum = md4(DER(S4UUserID)) Resultado
Cuando se procesa la solicitud, el KDC examina la primer tipo PA-DATA 130 entrada, selecciona RSA-MD4 Como algoritmo de suma de comprobación, acepta la solicitud como válida. Por lo tanto, el KDC confía en la afirmación de identidad falsificada.
Logros de la Parte I
Si la Parte I se completa correctamente, el KDC puede emitir un ticket de servicio S4U2Self válido donde el principal del cliente y el PAC corresponden a una identidad elegida por el atacante. Esto es importante porque el ticket S4U2Self se convierte en el ticket que se presenta posteriormente al KDC durante S4U2Proxy, y la identidad del ticket delegado descendente se deriva de él.
CVE-2025-60704 Parte II: Omitir el proceso de validación del cliente
La Parte I genera un ticket de servicio S4U2Self válido que representa la identidad elegida por el atacante. Sin embargo, este resultado no es suficiente por sí solo, ya que el ticket no se instala en el cliente. Esto supone una barrera crítica, ya que el ticket S4U2Self debe estar presente y ser utilizable para el posterior procesamiento de S4U2Proxy.
La Parte II describe la lógica de validación del lado del cliente que impide la instalación y la derivación que hace que el ticket sea utilizable.
Datos cifrados TGS-REP
MS-SFU define un mecanismo de compensación de integridad para modos de suma de comprobación heredados o sin clave. Cuando el KDC devuelve los datos PA-DATA de S4U relevantes dentro del campo encrypted-pa-data de la parte cifrada del TGS-REP, el cliente DEBE verificar los valores de la suma de comprobación asociados a la solicitud y la respuesta. El propósito de este diseño es aplicar la vinculación entre solicitud y respuesta utilizando valores que solo están disponibles después de descifrar la respuesta. Esto compensa el hecho de que las estructuras externas de PA-DATA pueden ser modificables por atacantes cuando se utilizan algoritmos de suma de comprobación de compatibilidad.
TL; DR
La eliminación de la PA-DATA relacionados con S4U del mensaje de respuesta hace que el cliente omitir la lógica de verificación y aceptar el billete.
Si no necesita comprender el proceso de validación en detalle y desea proceder directamente a la explotación, puede saltar a Paso 1.
Comprender por qué Para que funcione esta omisión, primero debemos examinar cómo el KDC construye la respuesta cifrada y cómo se integran los datos de validación. Las siguientes secciones explican este proceso paso a paso.
Comprensión del proceso de validación de suma de comprobación (KDC – lado del servidor)
En el lado del servidor, esta lógica se implementa en KDCSVC.DLL CRYPTDLL.DLL.
El flujo de validación comienza en kdcsvc!HandleTGSRequest, que, a pesar de su nombre, maneja ambas Procesamiento de mensajes de solicitud y respuesta.
La verificación de la solicitud se realiza de la siguiente manera:
- HandleTGSRequest llama a kdcsvc!KdcFindS4UclientAndRealm para extraer el nombre del cliente.
- Se llama a KerbFindPreAuthDataEntry para localizar PA-DATA tipo 130.
- La estructura se pasa a KerbSignS4UpreauthDataEx para la verificación de la suma de comprobación.
- El tipo de suma de comprobación se selecciona resolviendo primero el tipo de cifrado utilizando:
- cryptdll!CDLocateCSystem
- crytdll!CDLocateSuma de comprobación
- Según el tipo de cifrado resuelto, se selecciona el algoritmo de suma de comprobación apropiado.
- En el escenario de degradación, esto se resuelve así: MD4.
- El KDC calcula la suma de comprobación sobre el solicita y lo compara con la suma de comprobación proporcionada por el cliente.
Si el resultado es válido, HandleTGSRequest llama a BuildReply para construir el mensaje de respuesta y continúa con los siguientes pasos:
- Se llama nuevamente a KerbSignS4UPreauthDataEx para calcular la suma de comprobación responder.
- Si el tipo de cifrado es no AES, el KDC invoca KdcAddEncryptedS4uPaData.
- El KDC concatena la suma de comprobación calculada sobre el solicita con la suma de comprobación calculada sobre el responder.
- Si la suma de comprobación de la solicitud es válida, el KDC procede a construir la respuesta.
- Ambos valores de suma de comprobación (solicitud de 16 bytes + respuesta de 16 bytes) se colocan en pa-para-usuario-x509 bajo el datos cifrados sección del TGS-REP.
- La parte cifrada de la respuesta se sella utilizando la clave de sesión y se envía de vuelta al cliente.
Cuando el cliente recibe el TGS-REP, se espera que descifre la parte cifrada del mensaje utilizando la clave de sesión, Localizar PA-DATA tipo 130 y comparar la suma de comprobación de texto simple en el responder con el últimos 16 bytes de los PA-DATA cifrados y comparar los primeros 16 bytes con la solicitud del cliente
Sólo si todas estas comprobaciones tienen éxito, el ticket debe ser aceptado e instalado en la memoria caché.
Proceso de validación de suma de comprobación (lado del cliente)
En el lado del cliente, la lógica de validación de la suma de comprobación se implementa en KERBEROS.DLL, principalmente dentro de una función con un nombre muy indicativo: kerberos!KerbCheckX509S4uReply. Esta función se encarga de validar el mecanismo de compensación de integridad aplicado a PA-S4U-X509-USUARIO respuestas
El flujo de validación comienza cuando el cliente recibe y descifra la parte cifrada del TGS-REPLa lógica de procesamiento continúa entonces de la siguiente manera:
- El cliente verifica si el mensaje de respuesta contiene las estructuras relacionadas con S4U esperadas.
- Se llama a KerbFindPreAuthDataEntry para localizar PA-DATA tipo 130.
- Si se encuentra el tipo PA-DATA 130, el cliente calcula la suma de comprobación sobre el responder utilizando KerbCredIsoIum::SignS4UPreauthData.
- La suma de comprobación de respuesta calculada se compara con el valor de suma de comprobación proporcionado por el KDC.
- Ahora, el cliente verifica el tipo de cifrado asociado con la clave de sesión.
- Si el tipo de cifrado es AES (tipo e 18 / 0x12), la validación tiene éxito y no se realiza ninguna verificación adicional.
Cuando el tipo de cifrado es RC4 (tipo 23), la función sigue una ruta de control diferente:
- El cliente espera encontrar PA-DATA cifrado tipo 130 que contiene ambos:
- la suma de comprobación repetida del responder, y la suma de comprobación reflejada de la solicitud original.
- El código verifica el tamaño de los buffers de suma de comprobación e intenta extraer un buffer que debe contener la suma de comprobación calculada sobre la solicitud original.
- El cliente intenta comparar este valor con una suma de comprobación calculada localmente para la solicitud.
En este punto, la validación falla.
El cliente nunca calcula un Suma de comprobación MD4 sobre la solicitudy, por lo tanto, no tiene ningún valor local para comparar con la suma de comprobación de la solicitud reflejada. Como resultado, la función finaliza con un error y el ticket no se instala.
Al analizar las posibles vías de éxito, una rama destaca. Si El tipo PA-DATA 130 no está presente, el código salta a una rama interna etiquetada ETIQUETA72En esta ruta, se verifican varias banderas, el valor de retorno se pone a cero y la función devuelve éxito. sin realizar la verificación de enlace de suma de comprobación de datos cifrados pa.
Este comportamiento habilita directamente el bypass.
Paso 1: Eliminar el objeto PA-DATA de la respuesta
Modificando el tipo padata a cualquier otro valor que no sea 130, o eliminando el PA-DATOS Estructura completamente desde la respuesta, el cliente nunca ingresa a la ruta de validación estricta. En su lugar, sigue la rama alternativa y acepta la verificación de integridad del ticket.
En resumen, la presencia de PA-DATOS 130 Determina si el cliente aplica la comprobación de integridad compensatoria. Al eliminarla, la lógica de validación se ejecuta correctamente de forma silenciosa, lo que permite que el ticket S4U2Self falsificado continúe con el flujo de código de instalación.
Paso 2: Restauración de cname
En esta etapa, el cname del billete devuelto deberá ser restituido desde el identidad objetivo atrás para el usuario original.
La razón de esto es sutil pero importante. La aplicación originalmente inició la suplantación de identidad para Usuario A, pero el S4U TGS-REP manipulado ahora contiene un ticket de servicio válido para Usuario BCuando el host que inició la suplantación recibe este ticket, la discrepancia entre el nombre de cliente esperado y el cname del ticket provoca un error en la instalación del ticket. Esto crea una restricción adicional para una explotación exitosa.
Sin embargo, el atacante puede aprovechar el hecho de que el cname El campo no está protegido en cuanto a integridad. Modificando el cname en el ticket devuelto desde Usuario B de nuevo a Usuario A, el ticket vuelve a coincidir con las expectativas de la sesión de inicio de sesión y es aceptado.
Este comportamiento también demuestra un problema secundario importante: No se realiza ninguna verificación adicional del PAC durante la instalación del ticketEl cliente acepta el ticket basándose en comprobaciones de consistencia a nivel de superficie, incluso aunque el PAC integrado en el ticket represente a un usuario diferente.
Logros de la Parte II
En este punto, el atacante obtiene una S4U2Boleto de autoservicio que está instalado en Sesión de inicio de sesión del usuario A, mientras que el incrustado PAC corresponde al Usuario B.
Esto elimina la última barrera del lado del cliente. El ticket ahora es totalmente utilizable y puede presentarse en la siguiente fase del ataque: Proxy S4U2, donde la identidad del ticket de servicio delegado se derivará de este ticket S4U2Self falsificado.
Explotación y ejemplos del mundo real
Para demostrar cómo se puede explotar este comportamiento en la práctica, creé una pequeña aplicación web que autentica usuarios, realiza la delegación Kerberos y accede a archivos remotos a través de CIFS.
La aplicación sigue un patrón común de varios niveles: un frontend IIS autentica al usuario y luego delega el acceso a un servidor de archivos backend.
Nos autenticaremos utilizando una cuenta de dominio con privilegios bajos (usuario), utilizaremos la técnica MitM y ejecutaremos el ataque para obtener privilegios de administrador.
El código examinará cada mensaje y modificará solo los campos necesarios en el AS-REQ , Solicitud de TGS, TGS-REP mensajes como los siguientes:
El uso de este exploit le otorgará al usuario1 el contexto de autorización de 'administrador' (o cualquier otro usuario no sensible):
Ejemplos del mundo real
Mientras investigaba escenarios de abuso prácticos para esta vulnerabilidad, identifiqué dos Aplicaciones sensibles y ampliamente implementadas que ilustran su impacto.
Inscripción web de la autoridad de certificación Utiliza la delegación en un modelo clásico multicapa. Un frontend de IIS autentica al usuario y luego delega en una autoridad de certificación remota para emitir el certificado bajo la identidad del usuario, aplicando la política de dominio, los permisos de plantilla y las reglas de emisión.
Proxy de aplicación Entra Utiliza la delegación en un modelo basado en conectores. Un conector local realiza la transición de protocolo y la delegación restringida para proporcionar un inicio de sesión único desde la identidad en la nube a las aplicaciones Kerberos locales.
Aunque estas aplicaciones cumplen diferentes propósitos comerciales, comparten una característica fundamental: ambas se basan en la identidad delegada para autorizar operaciones posteriores sensibles. Como resultado, ambas representan superficies de escalada de alto impacto cuando se compromete la integridad de la identidad delegada.
Cada una de estas aplicaciones puede ser explotada independientemente. Más importante aún, también pueden ser combinado, amplificando el impacto y demostrando cómo la confusión de identidad en una capa puede propagarse a través de los límites de confianza.
Inscripción web de CA
El servicio de inscripción web de la autoridad de certificación (CA) es un servicio de Microsoft Active Directory Servicio de Servicios de Certificación (AD CS) que proporciona una interfaz basada en web para que los usuarios y las computadoras interactúen con una Autoridad de Certificación.
Actúa como un puente, permitiendo a los usuarios enviar solicitudes de certificados, descargar certificados y recuperar listas de revocación de certificados (CRL) a través de un navegador web sin necesidad de interacción directa y nativa con el servidor de CA.
Aprenda más: https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/configure-kerberos-constrained-delegation.
Proxy de aplicación Entra y delegación Kerberos
Proxy de aplicación Entra es un ejemplo representativo de una arquitectura de identidad híbrida, donde La autenticación se realiza en la nube, mientras La autorización se aplica localmente mediante Kerberos.
A un alto nivel, Entra Application Proxy actúa como un proxy inverso basado en la nube Para aplicaciones web locales. Los usuarios se autentican en la aplicación mediante Microsoft Entra ID inicio de sesión único, y la sesión autenticada se tuneliza luego a través de Conector de proxy de aplicación local.
El conector es responsable de unir estos dos mundos.
Mira aquí: https://learn.microsoft.com/en-us/entra/identity/app-proxy/how-to-configure-sso-with-kcd.
Una vez autenticado el usuario en la nube, el conector debe traducir esa identidad a algo que los servicios locales puedan entender. Cuando la aplicación backend utiliza Kerberos, esta traducción se realiza mediante Transición del protocolo S4U.
El conector utiliza su propio contexto Kerberos para solicitar una Boleto propio S4U2 que representa al usuario autenticado y luego utiliza delegación restringida (S4U2Proxy) para obtener tickets de servicio para recursos locales posteriores.
En otras palabras, la conversión de protocolo no es un caso extremo en este caso; es fundamental para el diseño.
Figura 20: ejemplo de configuración de la guía de Microsoft que muestra la transición de protocolo por diseño
Esta es precisamente la condición requerida para la cadena de vulnerabilidades descrita en esta investigación. Cuando la autenticación en la nube, la transición de protocolo y la delegación restringida se combinan por diseño, las fallas en el modelo de confianza S4U se vuelven relevantes para la seguridad.
Vea aquí el ejemplo de la aplicación Entra Proxy para CA WebEnroll:
Puntos clave
InterpretaciónPrimero comprender, luego implementar. La delegación y S4U permiten que un servicio actúe en nombre de un usuario. Cualquier sistema que pueda solicitar tickets "en nombre" de un usuario debe considerarse un límite de seguridad. La falta de comprensión de dónde se obtiene la identidad, cómo se vincula y qué componente la aplica es lo que convierte a la delegación en una vía de escalada.
Autenticación Su fortaleza depende de su eslabón más débil. Una criptografía robusta en la capa de ticket no es útil si la identidad se introduce por una ruta más débil, se negocia en un modo más débil o se acepta mediante una rama de validación más débil. La garantía de identidad de extremo a extremo se determina por el paso menos protegido de la cadena.
Técnica correcta, uso correcto:
- Hashing se utiliza para integridad.
- Firma / MAC se utilizan para autenticidad e integridad.
- Sellado (cifrado) se utiliza para confidencialidad.
En este caso, Sólo se confiaba en la integridad, dónde integridad autenticidad fueron requeridos.
Mitigaciones
- Aplicar correcciones del proveedor y validar el comportamiento. Aplicar parches a los sistemas Windows según las Guía de actualización de seguridad de noviembre de 2025 y validar que el comportamiento de Kerberos coincida con el modelo fijo en su entorno, con prioridad en los controladores de dominio y los sistemas que realizan la transición y delegación de protocolos.
- Habilite Kerberos FAST (blindaje) para reducir las oportunidades de degradación y manipulación MITM en la preautenticación y negociación, y para fortalecer la integridad del intercambio Kerberos contra interferencias a nivel de tráfico.
- Reforzar la postura criptográfica y las superficies de compatibilidad. Reducir la exposición a los modos heredados deshabilitando los tipos de cifrado más antiguos siempre que sea posible, ya que estos permiten acceder a las asignaciones de suma de comprobación más débiles mediante negociación. Supervisar la configuración de las políticas de cuentas de servicio y dominios para detectar desviaciones de los valores predeterminados modernos.
- Trate la delegación como una superficie de configuración de alto riesgo. Minimice el número de cuentas de servicio confiables para la transición de protocolo y la delegación. Prefiera la delegación restringida y mantenga los SPN objetivo permitidos con un alcance estricto. Audite qué cuentas de servicio son confiables para la transición de protocolo, a qué SPN pueden delegar y asegúrese de que las cuentas privilegiadas se marquen como no delegables, a menos que exista un requisito empresarial de alcance estricto.
- Guía de monitoreo y detección: Monitoree patrones de uso anómalos de S4U2Self y S4U2Proxy, SPN de destino inesperados y discontinuidades de identidad donde los tickets delegados reflejen principales incoherentes con la sesión de inicio. Para servicios de certificación, monitoree la inscripción inesperada de identidades privilegiadas, el uso inusual de plantillas y la actividad de emisión originada en la ruta de la aplicación publicada por el proxy.
Referencias
Especificaciones de cifrado y suma de comprobación para Kerberos 5 RFC 3961
Implementar la suplantación en la aplicación
Configurar la delegación restringida para las páginas de CA Web Enroll