SecurityLayer

Unconstrained Delegation

Ejemplo práctico

Dado los siguientes elementos el modelo Unconstrained Delegation funcionaria de la siguiente manera

| Elemento     | Nombre                        | Tipo                                              |
| ------------ | ----------------------------- | ------------------------------------------------- |
| Usuario      | `johndoe@DOMAIN.LOCAL`        | Usuario Kerberos                                  |
| Servidor Web | `web01.domain.local`          | Cuenta de máquina: `WEB01$`                       |
| SPN del Web  | `HTTP/web01.domain.local`     | (registrado en `WEB01$`)                          |
| Servidor SQL | `sql01.domain.local`          | Cuenta de servicio: `MSSQLSvc/sql01.domain.local` |
| SPN del SQL  | `MSSQLSvc/sql01.domain.local` | (registrado en su cuenta)                         |
| Dominio      | `DOMAIN.LOCAL`                | KDC = DC del dominio                              |

1. TGT – johndoe obtiene un TGT desde el KDC

  • Cliente johndoe se autentica ante el KDC (Kerberos Authentication Service - AS_REQ / AS_REP).

  • KDC verifica su contraseña, y le devuelve un Ticket Granting Ticket o TGT (krbtgt/DOMAIN.LOCAL), con el flag forwardable

  • Resultado: El usuario obtiene un TGT válido, que le permitirá autenticarse ante el TGS del KDC para solicitar acceso a servicios.

Algunas consideraciones a tener en cuenta para esta primera parte:

¿Qué es el flag FORWARDABLE?

Es un bit dentro del TGT (Ticket Granting Ticket) que indica que ese ticket puede ser reenviado (forwarded) a un servicio con delegación habilitada (TrustedForDelegation), por ejemplo, en este caso el servidor web. Si el ticket no es forwardable, el servicio que lo reciba no podrá obtener nuevos tickets (delegar) en nombre del usuario hacia otros servicios.

🔑 En el contexto de delegación (como Unconstrained Delegation), el TGT debe ser forwardable para que el servidor pueda actuar como el usuario. Sin embargo también existen otros elementos que debemos tener en cuenta para que no falle la delegación sin restricción, si se da alguna de estas configuraciones o flags el procedimiento tendrá errores:

  • Si el usuario (johndoe) forma parte del grupo Protected Users, el KDC no emitirá TGTs forwardable para él, ni permitirá delegación con sus tickets.

  • Si el usuario (johndoe) tiene seteada la flag Not_Delegate como true, se le denegara la delegación. En esta situación el KDC NO incluye el TGT en el TGS por ende cuando el servidor web reciba ese TGS no podra extraer ningun TGT forwardable y no podra delegar

2. TGS – Solicitud de acceso a un servicio: johndoe accede al servidor web (web01)

  • johndoe solicita al KDC un ticket de servicio para HTTP/web01.domain.local.

  • Como el servicio tiene delegación sin restricciones, el KDC:

    • Devuelve un TGS para HTTP/web01.domain.local

    • Incluye en el ticket el TGT de johndoe reenviable (esto es lo importante)

  • Luego johndoe se conecta a web01 y le envía ese TGS

Algunas consideraciones a tener en cuenta para esta segunda parte:

TrustedForDelegation (TRUSTED_FOR_DELEGATION - 0x80000)

  • ¿Qué es? Es un flag en el atributo userAccountControl de una cuenta de máquina o servicio que habilita Unconstrained Delegation.

  • ¿Para quién se configura? Para la cuenta de equipo o servicio que actuará en nombre de otros usuarios.

  • ¿Qué permite? Si un usuario envía un TGS al servicio, el KDC incluirá su TGT reenviable dentro del TGS. Esto habilita a ese equipo a hacer solicitudes TGS en nombre del usuario (delegación total).

¿Sobre quién se pone TrustedForDelegation?

Sobre WEB01$

Porque es el servicio intermedio que:

  • Recibe conexiones de usuarios (johndoe)

  • Y luego necesita actuar en nombre de esos usuarios hacia otros servicios (como el SQL)

3. Delegación: el servidor web01 extrae el TGT de johndoe

  • web01.domain.local recibe el TGS y lo desencripta (tiene la clave de su SPN).

  • Extrae el TGT reenviable de johndoe del campo authorization-data.

  • Ahora puede actuar como johndoe y solicitar nuevos tickets.

Este almacenamiento del TGT es lo que habilita la delegación sin restricciones: el servicio actúa como si fuera el cliente porque tiene su TGT y puede presentarlo ante el KDC como si fuera el propio usuario en otras consultas a otros servicios.

4. TGS – web01 solicita un nuevo TGS para MSSQLSvc/sql01.domain.local en nombre de johndoe

  • web01 usa el TGT reenviable de johndoe para hacer una nueva petición TGS al KDC.

  • Envía un nuevo TGS_REQ, esta vez dirigido a otros servicios como: MSSQLSvc/sql01.domain.local

  • Este comportamiento es el núcleo de la delegación sin restricciones: el servicio actúa como un proxy del cliente, usando su identidad y TGT.

El KDC responde con un TGS_REP, que contiene:

  • Un nuevo TGS para el servicio destino.

  • Información de sesión cifrada.

5. Acceso al servicio delegado SQL

SQLServer ahora actúa directamente como johndoe y presenta el TGS obtenido al MailServer.

El mail server recibe un mensaje KRB_AP_REQ con:

  • El TGS específico para ese servicio.

  • Autenticador cifrado con la clave de sesión.

Si los tickets y autenticadores son válidos, el acceso se concede como si fuera el usuario original.

Configuraciones que pueden provocar fallas en la delegación sin restricciones

| Factor                            | Efecto en Unconstrained Delegation          |
| --------------------------------- | ------------------------------------------- |
| `NotDelegated` en el usuario      | El KDC no emite TGT forwardable             |
| Usuario en `Protected Users`      | Se bloquea toda delegación                  |
| SPN faltante o incorrecto         | No se emite TGS → no se activa delegación   |
| Ticket TGT sin flag `forwardable` | Aunque el server tenga delegación, no sirve |
| Políticas Kerberos restrictivas   | Pueden impedir emisión de TGTs forwardables |

¿Cómo podría un pentester aprovechar la Delegación Sin Restricciones?

Un atacante (o pentester en un entorno controlado) puede explotar la Delegación Sin Restricciones (Unconstrained Delegation) en distintos escenarios para escalar privilegios o persistir en el dominio. A continuación se describen los casos más relevantes:

  1. Compromiso de una máquina con delegación sin restricciones habilitada Si un pentester compromete un equipo que tiene habilitada la delegación sin restricciones (por ejemplo, un servidor que ejecuta un servicio con este tipo de configuración), puede acceder a la caché de tickets Kerberos (LSASS) y recuperar los TGT de los usuarios que se hayan autenticado en ese servicio. Esto permite al atacante actuar como esos usuarios en otros servicios del dominio.

  2. Compromiso de una cuenta de usuario con delegación sin restricciones Si se compromete una cuenta de usuario que tiene el flag TrustedForDelegation activado (poco común, pero posible), el atacante podría controlar los servicios que se ejecutan bajo esa cuenta, lo que abre la posibilidad de interceptar TGTs de otros usuarios que interactúan con dichos servicios.

Last updated