Kerberos (III): ¿Cómo funciona la delegación?

Introducción a la delegación en kerberos

Existen varios tipos de delegación utilizados en el protocolo Kerberos. La delegación permite a un servicio suplantar al usuario cliente para interactuar con un segundo servicio, disponiendo de los privilegios y permisos del propio cliente.

Se dispone de los siguientes tipos de delegación:

• Unconstrained Delegation (Delegación sin restricciones)
• Constrained Delegation (Delegación restringida)
• RBCD (Resource Based Constrained Delegation) (Delegación restringida basada en recursos)

En este artículo, se mostrará como funcionan los distintos tipos de delegaciones, incluyendo los casos especiales. Adicionalmente se presentarán varios escenarios donde un atacante podría aprovecharse de estos mecanismos con el objetivo de elevar privilegios o establecer una persistencia en el dominio.

Antes de continuar con las explicaciones, se asume que el lector entiende el funcionamiento y los conceptos básicos de Kerberos. En caso de no estar familiarizado con expresiones como TGT, TGS, KDC o Golden Ticket, se recomienda revisar primero el artículo «¿Cómo funciona Kerberos?» u otra introducción a Kerberos.

Además, la delegación es un tema enrevesado, con muchos detalles a tener en cuenta, por lo que no se debería uno desanimar si no es capaz de entenderlo todo a la primera o solamente quedarse con la idea general, no pasa nada, se pueden revisar los contenidos de este artículo las veces que sean necesarias. Del mismo modo, si se presenta cualquier pregunta relacionada con el tema, se anima al lector a dejar un comentario.

Ahora, manos a la obra.

Servicios, Usuarios y Ordenadores

En primer lugar, dado que Kerberos y la delegación versan sobre como los usuarios interactúan con servicios, que a su vez interactúan con otros servicios, se dará primero una definición de lo que es un usuario, un servicio y su relación. Es importante familiarizarse con estos términos para no perderse en las explicaciones posteriores sobre los mecanismos de delegación.

Usuarios

Un usuario es un agente representado por una cuenta de usuario (o una subclase de esta) en Active Directory. En un dominio de Active Directory, se pueden encontrar los siguientes tipos de usuarios:

• Cuentas de usuario «normales», que pueden ser:
  • Utilizadas por personas físicas para realizar su trabajo.
  • Utilizadas para llevar a cabo tareas específicas, como realizar un backup de una base de datos.
• Cuentas de maquinas, utilizadas por los ordenadores de un dominio. Se pueden reconocer este tipo de cuentas ya que sus nombres terminan con el símbolo «$» en la base de datos de Active Directory.

Es importante entender que, desde la perspectiva de Active Directory, los ordenadores son usuarios, en concreto, una subclase de usuarios.

Servicios

Un servicio:

• Se identifica por un SPN (Service Principal Name) en Active Directory, que indica el tipo y nombre del servicio, así como su usuario propietario y el ordenador anfitrión.
• Se ejecuta en un ordenador (el anfitrión del servicio) como un proceso. Sin embargo, no es que necesario que un servicio esté siendo ejecutado para que un usuario pueda solicitar un TGS para él. Además, debido a que es un proceso, se debe entender que los administradores del ordenador anfitrión pueden acceder a la memoria del servicio y a los tickets manejados por este.
• Se ejecuta en el contexto de un usuario del dominio (el propietario del servicio). Es común que los servicios sean ejecutados en el contexto de la cuenta de máquina de su anfitrión, aunque no siempre es así.
• Puede ser utilizado por varios usuarios, y cualquier usuario puede obtener un TGS para cualquier servicio del dominio.

Lo más importante es entender que los servicios (como cualquier proceso), son ejecutados en el contexto de una cuenta de usuario, y por lo tanto cuentan con los permisos y privilegios de dicha cuenta.

Por otro lado, los usuarios de dominio pueden tener servicios. Los SPN’s de los servicios de un usuario se almacenan en el atributo ServicePrincipalName de su cuenta.

Además, se debe tener en cuenta que para añadir un SPN a una cuenta de usuario, se necesita el permiso Validated-SPN sobre dicha cuenta. Este permiso no se concede por defecto al propio usuario (salvo en el caso de cuentas de máquina), por lo que normalmente se requiere de un rol de administrador de dominio o similar para modificar los SPN’s de un usuario.

Servicios en la delegación

Con relación a la delegación de Kerberos, debido a que un servicio es ejecutado en el contexto de su usuario propietario:

• El servicio puede llevar a cabo una delegación solamente si su usuario propietario tiene permiso para hacerla. Puesto de otro modo, si un usuario puede llevar a cabo una delegación, todos sus servicios (y procesos) también.
• Cuando un servicio interactúa con el KDC, se identifica como su usuario propietario. De hecho, el KDC solo es consciente del usuario con el que está interactuando, no del proceso. Esto viene a significar que cualquier proceso del mismo usuario puede llevar a cabo las mismas acciones en Kerberos, sin importar si es un servicio o no.

Medidas Anti-Delegación

Antes de explicar específicamente un tipo de delegación, se debe saber que existen 2 métodos para evitar cualquier clase de delegación de una cuenta de usuario:

• Activar la flag NotDelegated (o ADS_UF_NOT_DELEGATED), almacenada también en el atributo User-Account-Control de las cuentas de usuario. Por defecto, ninguna cuenta del dominio tiene esta flag activada.
• Añadir al usuario al grupo Protected Users (Usuarios protegidos), que fue introducido en Windows Server 2012 R2. Por defecto, este grupo no tiene ningún miembro. En concreto, los miembros del grupo Protected Users son incapaces de:
  • Utilizar autenticación NTLM.
  • Utilizar cifrado DES o RC4 en la pre-autenticación de Kerberos.
  • Ser delegados por cualquier tipo de delegación de Kerberos.
  • Renovar los TGT’s más de 4 horas.

En las secciones posteriores, se asumirá que la delegación no funcionará para un usuario que se encuentre protegido mediante ante uno de estos métodos. Los ejemplos presentados no mostrarán la comprobación de estas protecciones para mejorar la claridad.

Unconstrained Delegation

Unconstrained Delegation es el tipo más simple de delegación, que permite a un servicio suplantar a cualquier usuario autenticado contra él mismo sin limitaciones.

En este tipo de delegación, el servicio obtiene un TGT válido del usuario cliente, lo que le permite actuar como dicho usuario en el mundo de Kerberos (y por tanto en el dominio).

Pero ¿Cómo obtiene un servicio un TGT del usuario cliente?

El propio cliente le envía un TGT suyo al servicio.

Cuando un usuario solicita un TGS para un servicio con Unconstrained Delegation activado, el KDC incluye un TGT dentro del TGS.

Concretamente, este TGT es incluido en la parte del TGS cifrada con la clave del propietario del servicio. De este modo, cuando el servicio recibe el TGS, puede descifrar y extraer el TGT de su cliente.

Pero ¿Cómo sabe el KDC cuando tiene que insertar el TGT dentro del TGS?

El KDC incluye el TGT en caso de que la flag TrustedForDelegation (o ADS_UF_TRUSTED_FOR_DELEGATION) esté activada en la cuenta del propietario del servicio. Esta flag se almacena en el atributo User-Account-Control de las cuentas de usuario de Active Directory.

También se debe destacar que para modificar la flag TrustedForDelegation de un usuario, se requiere el privilegio SeEnableDelegationPrivilege en un controlador de dominio.

De cualquier modo, si el usuario objetivo de la delegación se encuentra protegido, ya sea mediante el grupo Protected Users o la flag NotDelegated, la delegación no funcionará.

Vale ¿Podrías darme un ejemplo de Unconstrained Delegation?

La siguiente imagen muestra el proceso de Unconstrained Delegation:

En este caso:

1. User1 solicita un TGS para ServiceZ, de UserZ.
2. El KDC comprueba si la flag TrustedForDelegation de UserZ está activada (Sí).
3. El KDC incluye un TGT de User1 dentro del TGS para ServiceZ.
4. ServiceZ recibe el TGS y obtiene el TGT de User1, que se almacena para un uso posterior.

Vale, pero ¿Cómo podría un pentester aprovecharse de Unconstrained Delegation?

Pueden darse varios escenarios:

• En caso de que un pentester sea capaz de comprometer una máquina que tiene servicios con permisos de Unconstrained Delegation, existe la posibilidad de encontrar TGT’s de los clientes de dichos servicios.
• En caso de que un pentester comprometa una cuenta de usuario que cuenta con permiso de Unconstrained Delegation, le sería posible recolectar los TGT’s de los servicios del usuario.
• Además, si en cualquiera de los escenarios previos, el pentester es capaz de persuadir a un usuario privilegiado para que interactúe con uno de esos servicios «controlados», entonces podría hacerse con su TGT y llegar a comprometer el dominio.
• En caso de tener el control del dominio, una técnica de persistencia podría ser conceder Unconstrained Delegation a un grupo de usuarios que el pentester pueda controlar de forma fácil.

Constrained Delegation y RBCD

Además de Unconstrained Delegation, existen 2 tipos más de delegaciones:

• Constrained Delegation
• RBCD (Resource Based Constrained Delegation) (Introducida en Windows Server 2012)

En cualquiera de estos tipos, la delegación se encuentra restringida a solamente ciertos servicios que se encuentran permitidos mediante una lista blanca.

Vale ¿Cómo puede Kerberos crear una lista blanca de servicios?

Kerberos per se no cuenta con la capacidad de restringir la delegación a un grupo específico de servicios.

Por este motivo Microsoft implementó 2 extensiones que permiten conseguir este comportamiento:

• S4U2Proxy (Service for User to Proxy)
• S4U2Self (Service for User to Self)

S4U2Proxy

Vale ¿Qué es S4U2Proxy?

S4U2Proxy es una extensión que permite a un servicio utilizar el TGS enviado por el cliente, con objeto de solicitar en nombre del usuario cliente un nuevo TGS para un otro servicio.

Pero ¿Cómo sabe el KDC si un usuario/servicio puede solicitar un TGS para otro servicio utilizando el TGS del cliente?

El KDC comprueba 2 listas:

Por una parte, cada cuenta de usuario guarda una lista de aquellos servicios para los cuales puede solicitar un TGS. Esta lista se almacena en el atributo msDS-AllowedToDelegateTo de la cuenta. Para modificar este atributo se necesita tener el privilegio SeEnableDelegationPrivilege en el controlador de dominio. Esta es la lista utilizada en Constrained Delegation.

Por otra parte, cada cuenta de usuario guarda otra lista con los usuarios que tienen permitido pedir un TGS para cualquiera de sus servicios. Esta lista se almacena en el atributo msDS-AllowedToActOnBehalfOfOtherIdentity. Esta lista puede ser editaba por el propio usuario. Esta es la lista utilizada en RBCD.

Por lo tanto, el KDC comprobará las siguientes condiciones para determinar si se puede utilizar delegación:

• Si el cliente del servicio está protegido frente a delegación, bien porque es miembro del grupo Protected Users o bien porque tiene activada la flag NotDelegated, entonces S4U2Proxy fallará.
• Si el servicio solicitado se encuentra listado en el atributo msDS-AllowedToDelegateTo del usuario que solicita la delegación, entonces el KDC realizará las siguientes comprobaciones:
  • Si el TGS utilizado en la solicitud de delegación es forwardable (tiene la flag forwardable activada), el KDC devolverá un TGS forwardable para el servicio solicitado (en este caso se ha aplicado Constrained Delegation).
  • En otro caso S4U2Proxy fallará.
• Si el usuario que está solicitando el TGS se encuentra listado en el atributo msDS-AllowedToActOnBehalfOfOtherIdentity de la cuenta del propietario del servicio solicitado, entonces el KDC devolverá un TGS forwardable para el servicio solicitado (en este caso se ha aplicado RBCD).
• En otro caso S4U2Proxy fallará.

Se debe notar, que en el caso de aplicar RBCD, el TGS enviado al KDC no necesita ser forwardable.

Adicionalmente, en caso de que un usuario pueda aplicar tanto Constrained Delegation como RBCD para el mismo servicio destino, Constrained Delegation tendrá preferencia. Esto significa que S4U2Proxy fallará si el TGS enviado al KDC no es forwardable, sin siquiera intentar aplicar RBCD.

Además, un hecho curioso es que el TGS devuelto a través de S4U2Proxy es siempre forwardable.

Por favor ¿Podrías mostrarme un ejemplo de S4U2Proxy que utilice Constrained Delegation?

La siguiente imagen muestra el proceso de S4U2Proxy que se resuelve aplicando Constrained Delegation (por claridad se asume que User1 no está protegido contra delegación mediante Protected Users o NotDelegated, de otro modo la delegación fallaría):

En este ejemplo:

1. User1 envía el TGS a ServiceZ.
2. ServiceZ, de UserZ, usa este TGS para solicitar al KDC un TGS para ServiceX en nombre de User1.
3. El KDC comprueba:
   1. Si ServiceX se encuentra listado en el atributo msDS-AllowedToDelegateTo de UserZ (Sí).
   2. Si el TGS enviado es forwardable (Sí). Se aplica Constrained Delegation.
4. El KDC devuelve un TGS a ServiceZ para interactuar con ServiceX en nombre de User1.
5. ServiceZ usa el nuevo TGS para interactuar con ServiceX suplantando a User1.

Por favor ¿Podrías mostrarme un ejemplo de S4U2Proxy que utilice RBCD?

La siguiente imagen muestra el proceso de S4U2Proxy que se resuelve aplicando RBCD (por claridad se asume que User1 no está protegido contra delegación mediante Protected Users o NotDelegated, de otro modo la delegación fallaría):

En este ejemplo:

1. User1 envía el TGS to ServiceZ.
2. ServiceZ, de UserZ, usa este TGS para solicitar al KDC un TGS para ServiceX en nombre de User1.
3. El KDC comprueba:
   1. Si ServiceX se encuentra listado en el atributo msDS-AllowedToDelegateTo de UserZ (No). No se puede aplicar Constrained Delegation.
   2. Si UserZ se encuentra listado en el atributo msDS-AllowedToActOnBehalfOfOtherIdentity de UserX, propietario de ServiceX (Yes). Se puede aplicar RBCD.
4. El KDC devuelve un TGS a ServiceZ para interactuar con ServiceX en nombre de User1.
5. ServiceZ usa el nuevo TGS para interactuar con ServiceX suplantando a User1.

Vale ¿algo más?

Pues sí. Existe un curioso truco que permite utilizar el mismo TGS para cualquier servicio que pertenezca al mismo usuario . Esto se puede hacer cambiando el nombre del servicio destino del TGS.

Esto es posible debido a 2 cosas:

• El nombre del servicio se especifica en una parte no cifrada del TGS que cualquiera puede modificar.
• Todos los servicios del mismo usuario comparten la misma clave de Kerberos y por tanto cualquiera puede descifrar correctamente un TGS para otro servicio del mismo usuario.

Se puede utilizar este truco para sortear la lista blanca (msDS-AllowedToDelegateTo) de servicios utilizada en Constrained Delegation .

¿Ejemplo?

En este ejemplo:

1. User1 envía su TGS a ServiceZ.
2. ServiceZ, de UserZ, usa este TGS para solicitar al KDC un TGS para ServiceX, de UserXY, en nombre de User1.
3. El KDC comprueba:
   1. Si ServiceX se encuentra listado en el atributo msDS-AllowedToDelegateTo de UserZ (No). No se puede aplicar Constrained Delegation.
   2. Si UserZ se encuentra listado en el atributo msDS-AllowedToActOnBehalfOfOtherIdentity de UserXY, propietario de ServiceX (Yes). No se puede aplicar RBCD.
4. El KDC rechaza la solicitud hecha por ServiceZ.
5. ServiceZ solicita al KDC, en nombre de User1, un TGS para ServiceY, otro servicio de UserXY.
6. El KDC comprueba:
   1. Si ServiceY se encuentra listado en el atributo msDS-AllowedToDelegateTo de UserZ (Sí).
   2. Si el TGS enviado es forwardable (Sí). Se aplica Constrained Delegation.
7. El KDC devuelve un TGS a ServiceZ para interactuar con ServiceY en nombre de User1.
8. ServiceZ (UserZ) cambia el nombre del servicio objetivo del TGS de ServiceY a ServiceX.
9. ServiceZ usa el TGS editado para interactuar con ServiceX suplantando a User1.

Se debe tener en cuenta que el comportamiento descrito en este ejemplo es más propio de un pentester que de un servicio legítimo, ya que este último no debería tener que utilizar este truco para acceder a recursos legítimos.

S4U2Self

Vale, pero si se puede suplantar al usuario con S4U2Proxy ¿Para que sirve S4U2Self?

El propósito de S4U2Self es permitir el uso de delegación a servicios que no soportan autenticación mediante Kerberos, y por lo tanto, no pueden obtener un TGS del usuario cliente.

Para ello, S4U2Self permite a un servicio solicitar al KDC un TGS para sí mismo, a nombre del usuario cliente. Esto se conoce como Protocol Transition (Transición de protocolo).

¿Puede cualquier usuario utilizar S4U2Self?

No. El KDC comprobará las siguientes condiciones cuando un usuario utilice S4U2Self:

• Si la cuenta del usuario que solicita el TGS no tiene servicios, S4U2Self fallará y no devolverá el TGS.
• Si el usuario para el cual se pide el TGS está protegido contra delegación (debido al grupo Protected Users o la flag NotDelegated), se devolverá un TGS no forwardable (sin la flag forwardable activa). Parece ser que en ocasiones el TGS devuelto por el KDC contiene un nombre de servicio incorrecto, pero que puede ser cambiado como se ha visto anteriormente.
• Si la flag TrustedToAuthForDelegation está activada para el usuario que solicita el ticket, se devolverá un TGS forwardable.
• Si la flag TrustedToAuthForDelegation no está activada para el usuario que solicita el ticket, se devolverá un TGS no forwardable.

La flag TrustedToAuthForDelegation (o ADS_UF_TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION) se almacena en el atributo User-Account-Control de la cuenta de usuario. Para modificar este atributo se necesita tener el privilegio SeEnableDelegationPrivilege en el controlador de dominio.

Por favor ¿Podrías mostrarme un ejemplo de S4U2Self?

La siguiente imagen muestra el proceso de S4U2Self (por claridad se asume que User1 no está protegido contra delegación mediante Protected Users o NotDelegated, de otro modo el KDC devolvería un TGS no forwardable):

En este ejemplo:

1. User1 se autentica contra ServiceZ sin utilizar Kerberos. Se podría haber hecho uso de NTLM o cualquier otro protocolo.
2. ServiceZ, de UserZ, solicita un TGS para sí mismo en nombre de User1.
3. El KDC comprueba:
   1. Si UserZ tiene algún servicio registrado (Sí).
   2. Si la flag TrustedToAuthForDelegation está activada en la cuenta de UserZ (Sí).
4. El KDC devuelve a ServiceZ un TGS forwardable para sí mismo, a nombre de User1, que puede ser utilizado en S4U2Proxy.

Por favor ¿Podrías mostrarme un ejemplo de S4U2Self y S4U2Proxy utilizados conjuntamente?

En el siguiente ejemplo se muestra el uso conjunto de S4U2Self y S4U2Proxy, consiguiendo delegación a través de Constrained Delegation (por claridad se asume que User1 no está protegido contra delegación mediante Protected Users o NotDelegated, de otro modo la delegación fallaría):

En este ejemplo:

1. User1 se autentica contra ServiceZ sin utilizar Kerberos. Se podría haber hecho uso de NTLM o cualquier otro protocolo.
2. ServiceZ, de UserZ, solicita un TGS para sí mismo en nombre de User1.
3. El KDC comprueba:
   1. Si UserZ tiene algún servicio registrado (Sí).
   2. Si la flag TrustedToAuthForDelegation está activada en la cuenta de UserZ (Sí).
4. El KDC devuelve a ServiceZ un TGS forwardable para sí mismo, a nombre de User1.
5. ServiceZ usa este TGS para solicitar al KDC un TGS para ServiceX en nombre de User1.
6. El KDC comprueba:
   1. Si ServiceX se encuentra listado en el atributo msDS-AllowedToDelegateTo de UserZ (Sí).
   2. Si el TGS enviado es forwardable (Sí). Se aplica Constrained Delegation.
7. El KDC devuelve un TGS forwardable a ServiceZ para interactuar con ServiceX en nombre de User1.
8. ServiceZ usa el nuevo TGS para interactuar con ServiceX suplantando a User1.

En el siguiente ejemplo se muestra el uso conjunto de S4U2Self y S4U2Proxy, consiguiendo delegación a través de RBCD (por claridad se asume que User1 no está protegido contra delegación mediante Protected Users o NotDelegated, de otro modo la delegación fallaría):

En este ejemplo:

1. User1 se autentica contra ServiceZ sin utilizar Kerberos. Se podría haber hecho uso de NTLM o cualquier otro protocolo.
2. ServiceZ, de UserZ, solicita un TGS para sí mismo en nombre de User1.
3. El KDC comprueba:
   1. Si UserZ tiene algún servicio registrado (Sí).
   2. Si la flag TrustedToAuthForDelegation está activada en la cuenta de UserZ (Sí).
4. El KDC devuelve a ServiceZ un TGS forwardable para sí mismo, a nombre de User1.
5. ServiceZ usa este TGS para solicitar al KDC un TGS para ServiceX en nombre de User1.
6. El KDC comprueba:
   1. Si ServiceX se encuentra listado en el atributo msDS-AllowedToDelegateTo de UserZ (No). No se puede aplicar Constrained Delegation.
   2. Si UserZ se encuentra listado en el atributo msDS-AllowedToActOnBehalfOfOtherIdentity de UserX, propietario de ServiceX (Yes). Se puede aplicar RBCD.
7. El KDC devuelve un TGS forwardable a ServiceZ para interactuar con ServiceX en nombre de User1.
8. ServiceZ usa el nuevo TGS para interactuar con ServiceX suplantando a User1.

¿Cómo podría un pentester aprovecharse de Constrained Delegation?

Se podrían dar varios escenarios:

• Si un pentester es capaz de comprometer una máquina en la que se ejecutan servicios con Constrained Delegation, existe la posibilidad de encontrar TGS’s de los clientes de dichos servicios para terceros servicios.
• En caso de que un pentester comprometa una cuenta de usuario que cuenta con permiso de Constrained Delegation, le sería posible recolectar los TGS’s de los servicios del usuario. Además, si la cuenta comprometida tuviese activada la flag TrustedToAuthForDelegation, entonces el propio pentester podría utilizar S4U2Self para solicitar TGS’s de otros usuarios directamente al KDC.
• Además, en cualquiera de los escenarios previos, para cada TGS se podría modificar el nombre del servicio para aumentar la cantidad de servicios con la que se podría interactuar.

¿Cómo podría un pentester aprovecharse de RBCD?

Si un pentester es capaz de comprometer la cuenta de UserZ, que se encuentra listado en el atributo msDS-AllowedToActOnBehalfOfOtherIdentity de otro usuario UserX, entonces se podría encadenar el uso de S4U2Self y S4U2Proxy para obtener acceso a los servicios de UserX suplantando a este usuario.

Se muestra a continuación un ejemplo de este escenario en el que UserZ utiliza S4U2Self y S4U2Proxy para interactuar con el servicio ServiceX suplantando a su propietario UserX (se asume que UserX no está protegido contra delegación mediante Protected Users o NotDelegated):

En este ejemplo:

1. UserZ (pentester), propietario de ServiceZ, solicita un TGS para ServiceZ en nombre de UserX (S4U2Self).
2. El KDC comprueba:
   1. Si UserZ tiene algún servicio registrado (Sí).
   2. Si la flag TrustedToAuthForDelegation está activada en la cuenta de UserZ (No).
3. El KDC devuelve a UserZ un TGS no forwardable para ServiceZ mismo, a nombre de UserX.
4. UserZ usa este TGS no forwardable para solicitar al KDC un TGS (S4U2Proxy) para ServiceX en nombre de UserX.
5. El KDC comprueba:
   1. Si ServiceX se encuentra listado en el atributo msDS-AllowedToDelegateTo de UserZ (No). No se puede aplicar Constrained Delegation.
   2. Si UserZ se encuentra listado en el atributo msDS-AllowedToActOnBehalfOfOtherIdentity de UserX, propietario de ServiceX (Yes). Se puede aplicar RBCD.
6. El KDC devuelve un TGS forwardable a ServiceZ para interactuar con ServiceX en nombre de UserX.
7. ServiceZ usa el nuevo TGS para interactuar con ServiceX suplantando a UserX.

Otra interesante posibilidad, como mecanismo de persistencia, es configurar RBCD desde usuarios arbitrarios a la cuenta krbtgt. Estos usuarios podrían entonces generar TGS’s para el servicio krbtgt en nombre de cualquier usuario, lo que significa poder generar TGT’s de manera arbitraria (ya que un TGT es un TGS para el servicio krbtgt) para cualquier usuario del dominio, de forma similar al ataque Golden Ticket.

Conclusión de la delegación en kerberos

Como se ha visto, Kerberos parece tener una superficie de ataque infinita ahora que se tienen en cuenta la delegación con sus 3 respectivos tipos. Ser consciente de este tipo de posibilidades podría suponer la diferencia entre el éxito o el fracaso de una intrusión.

Por lo tanto, en el próximo artículo, se verá como realizar ataques aprovechando los mecanismos de delegación desde un punto de vista práctico, así como las herramientas que se pueden usar para llevarlos a cabo y las mitigaciones que se pueden aplicar, ahora que los conceptos están en mente.

Nos vemos.

Referencias de delegación en Kerberos

• [MS-SFU]: Kerberos Protocol Extensions: Service for User and Constrained Delegation Protocol => https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-sfu/3bff5864-8135-400e-bdd9-33b552051d94
• Wagging the Dog: Abusing Resource-Based Constrained Delegation to Attack Active Directory => https://shenaniganslabs.io/2019/01/28/Wagging-the-Dog.html
• Active Directory Security Risk #101: Kerberos Unconstrained Delegation => https://adsecurity.org/?p=1667
• Trust? Years to earn, seconds to break => https://labs.mwrinfosecurity.com/blog/trust-years-to-earn-seconds-to-break/
• S4U2Pwnage => https://harmj0y.medium.com/s4u2pwnage-36efe1a2777c
• The Most Dangerous User Right You (Probably) Have Never Heard Of => https://blog.harmj0y.net/activedirectory/the-most-dangerous-user-right-you-probably-have-never-heard-of/
• Another Word on Delegation => https://blog.harmj0y.net/redteaming/another-word-on-delegation/
• Kerberos Delegation, SPNs and More… => https://www.secureauth.com/blog/kerberos-delegation-spns-and-more
• Protected Users => https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn466518(v=ws.11)

Descubre nuestro trabajo y nuestros servicios de ciberseguridad en www.tarlogic.com/es/

En TarlogicTeo y en TarlogicMadrid.