SecurityLayer

Resource-Based Constrained Delegation

Ejemplo práctico

Dado los siguientes elementos el modelo Resource-Based Constrained Delegation funcionaria de la siguiente manera

Elemento           : Nombre                          : Tipo
-------------------:----------------------------------:------------------------------
Usuario            : johndoe@DOMAIN.LOCAL            : Cuenta de usuario
Servidor frontend  : mail01.domain.local             : Cuenta de equipo/servicio (MAIL01$)
Servicio frontend  : HTTP/mail01.domain.local        : SPN registrado en MAIL01$
Servidor destino   : sql01.domain.local              : Cuenta de equipo/servicio (SQL01$)
Servicio destino   : MSSQLSvc/sql01.domain.local     : SPN registrado en SQL01$

¿Qué es Resource-Based Constrained Delegation (RBCD)?

RBCD es una forma moderna de delegación que invierte el control: En lugar de definir en el servidor origen (MAIL01$) hacia dónde puede delegar como vimos en Constrained Delegation, se configura en el servidor destino (SQL01$) quiénes tienen permitido actuar en nombre de otros usuarios.

Esto se configura mediante el atributo:

msDS-AllowedToActOnBehalfOfOtherIdentity

en la cuenta del servicio destino (SQL01$).

Esto permite delegación incluso entre dominios diferentes, y es útil en escenarios de mayor control o automatización.

Flujo de autenticación paso a paso (RBCD)

1. AS_REQ / AS_REP – johndoe obtiene su TGT

johndoe → KDC: Solicita TGT (krbtgt/DOMAIN.LOCAL) KDC → johndoe: Devuelve TGT

Este paso es igual al de cualquier autenticación en Kerberos.

2. TGS_REQ / TGS_REP – johndoe pide TGS para HTTP/mail01

johndoe → KDC: TGS_REQ para HTTP/mail01.domain.local

KDC → johndoe: TGS entregado (TGS)

johndoe se conecta al servicio web en mail01.

3. Suplantación con S4U2Self

MAIL01$ ahora quiere actuar como johndoe, así que:

MAIL01$ → KDC: Solicita TGS para sí mismo en nombre de johndoe (S4U2Self) KDC → MAIL01$: Devuelve TGS S4U2Self

Este ticket sólo sirve dentro de MAIL01$ y representa la identidad de johndoe.

4. Suplantación con S4U2Proxy hacia sql01

MAIL01$ quiere actuar como johndoe hacia el servicio MSSQL:

MAIL01$ → KDC: Solicita TGS para MSSQLSvc/sql01.domain.local actuando como johndoe usando el ticket S4U2Self como prueba

Aquí ocurre la diferencia clave con Constrained Delegation:

  • El KDC ya no consulta el atributo msDS-AllowedToDelegateTo en MAIL01$.

  • En cambio, consulta en la cuenta del servicio destino (SQL01$) si MAIL01$ aparece en el atributo msDS-AllowedToActOnBehalfOfOtherIdentity.

Si la cuenta SQL01$ confía en MAIL01$, el KDC devuelve el TGS final para delegación.

5. MAIL01$ se conecta a sql01 como johndoe

MAIL01$ → sql01: Usa TGS final (AP_REQ) actuando como johndoe

sql01 → Permite el acceso como si johndoe lo hubiese hecho directamente

Requisitos y configuración

En la cuenta SQL01$ (servicio destino)

Debe tener configurado el atributo:

msDS-AllowedToActOnBehalfOfOtherIdentity

Este atributo se puede modificar con PowerShell:

$SQL = Get-ADComputer sql01
$Mail = Get-ADComputer mail01
Set-ADComputer $SQL -PrincipalsAllowedToDelegateToAccount $Mail

Esto autoriza a MAIL01$ a delegar hacia SQL01$ en nombre de otros usuarios.

Ejemplos comunes de abuso de RBCD por un pentester

1. Escalación lateral a otro servidor mediante RBCD

Situación:

  • El pentester compromete una máquina (ej: web01).

  • Tiene permisos para crear un nuevo equipo en AD (AddComputer).

  • Hay un servidor como sql01 que permite delegación desde equipos específicos.

Qué puede hacer:

  • Crear una cuenta de máquina falsa (ej: attacker$).

  • Agregarse como delegado en msDS-AllowedToActOnBehalfOfOtherIdentity de sql01$.

  • Suplantar a un usuario (ej: un admin que se conectó a web01) y acceder a sql01 como él.

Resultado: Acceso como otro usuario (posiblemente admin) a otro servicio sin necesidad de su contraseña ni hash.

2. Persistencia pos-explotación sin privilegios evidentes

Situación:

  • El atacante tiene control sobre un equipo (web01$) o cuenta con permisos de escritura sobre una cuenta de máquina.

Qué puede hacer:

  • Configura en una máquina controlada (sql01$) el atributo msDS-AllowedToActOnBehalfOfOtherIdentity para delegar a un equipo suyo (evilbox$).

  • Así puede suplantar usuarios legítimos en cualquier momento sin necesidad de comprometer sus credenciales directamente.

Resultado: Puede establecer un backdoor Kerberos-based que no aparece en los lugares típicos donde se monitorea privilegios.

3. Abuso de permisos mal delegados (WriteProperty)

Situación:

  • El pentester identifica que una cuenta de usuario o servicio tiene permisos de escritura sobre una cuenta de máquina, por ejemplo:

UserX tiene permiso WriteProperty sobre SQL01$

Qué puede hacer:

  • Modifica directamente el atributo msDS-AllowedToActOnBehalfOfOtherIdentity para permitir delegación desde una máquina que controle.

Resultado: Gana control sobre servicios críticos al actuar como cualquier usuario (incluso Domain Admins) si logran suplantarlos.

4. Ataque combinado con Kerberoasting o DCSync

Situación:

  • El pentester se posiciona en una máquina vulnerable.

  • Un usuario privilegiado (Domain Admin) se conecta a ella.

Qué puede hacer:

  • Usa RBCD para suplantar a ese usuario y obtener un TGS para krbtgt o ldap/dc01, simulando su identidad.

  • Con eso puede:

    • Hacer DCSync (ldap/dc01)

    • Realizar Kerberoasting con privilegios altos

    • Esencialmente comprometer el dominio entero

5. Ataque cross-domain con trust

Situación:

  • Hay dos dominios con trust: DOMAINA ↔ DOMAINB.

  • El atacante tiene control sobre un equipo en DOMAINB.

Qué puede hacer:

  • Usa RBCD configurado en DOMAINA para delegar desde su equipo (en DOMAINB) hacia un recurso del otro dominio.

Resultado: Acceso cross-domain, muy útil en entornos corporativos grandes o forest trust.

Last updated