# Resource-Based Constrained Delegation

**Ejemplo práctico**

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

{% code fullWidth="true" %}
```vim
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$
```
{% endcode %}

#### ¿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.

<figure><img src="https://3952817437-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fa7XmBBD8fWuk6wM75Um3%2Fuploads%2Ffp9UPXmlvQPlXRMipK9R%2F1.png?alt=media&#x26;token=ae6fabcb-66a2-4242-a5ba-b34898e11720" alt=""><figcaption></figcaption></figure>

#### 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`.

<figure><img src="https://3952817437-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fa7XmBBD8fWuk6wM75Um3%2Fuploads%2FqzsosiwCmm1O1KW0opGB%2F2.png?alt=media&#x26;token=ca6eba07-863a-4b29-8816-d1419a38e1a1" alt=""><figcaption></figcaption></figure>

#### 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.

<figure><img src="https://3952817437-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fa7XmBBD8fWuk6wM75Um3%2Fuploads%2F097OI1U1ZzpXMybVRzNb%2F3.png?alt=media&#x26;token=94c2f5b5-dc5c-4f83-a2b2-07d4b8e748f2" alt=""><figcaption></figcaption></figure>

#### 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.

<figure><img src="https://3952817437-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fa7XmBBD8fWuk6wM75Um3%2Fuploads%2FLRHBWur8CPfx4l9vRqtp%2FRBCD.png?alt=media&#x26;token=215ca9ea-d609-4754-a0fc-d6a329e68505" alt=""><figcaption></figcaption></figure>

#### 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:

```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.
