# Constrained Delegation

## Theory:

* Service for the user to itself (S4U2self): If a service account has a "*UserAccountControl*" value containing `TRUSTED_TO_AUTH_FOR_DELEGATION` (T2A4D), then it can obtain a TGS for itself (the service) on behalf of any other user.
* Service for user to proxy (S4U2proxy): A service account can obtain a TGS on behalf of any user for the service defined in "`msDS-AllowedToDelegateTo`". To do this, it first needs a TGS from that user for itself, but it can use S4U2self to obtain this TGS before requesting the other.

{% hint style="warning" %}
Note: If a user is marked as "Sensitive account and cannot be delegated", you won't be able to impersonate them.
{% endhint %}

To summarize without going into too much detail: when a user requests the use of a service that will itself use a resource, the service must authenticate itself to resource B as the user. It will then ask the KDC for a TGS (Ticket Granted Service) in the user's name, encrypted with the service's hash. This TGS will then be sent to the service for validation. 

This means that if you compromise the service hash, you can impersonate users and gain access on their behalf to the services configured in the `msDS-AllowedToDelegateTo` attribute.

{% hint style="info" %}
A [closer look](https://beta.hackndo.com/constrained-unconstrained-delegation/#constrained--unconstrained-delegation) at the management of the delegation reveals two points: 

* In the first case, the **TRUSTED\_FOR\_DELEGATION** flag is set on the account, and the service can only relay kerberos authentications. It cannot use the **S4U2Self** extension to create a ticket.
* In the second case, the **TRUSTED\_TO\_AUTHENTICATE\_FOR\_DELEGATION** flag is set. If this is the case, then the service with this capability can impersonate any of the services in its list via the **S4U2Self** extension.

For example, if you have access to the *CIFS* service, you may also have access to the *HOST* service. Note that if you have access to the *LDAP* service on the DC, you will have sufficient privileges to use a *DCSync*-type attack.
{% endhint %}

{% hint style="warning" %}
Machine account can edite their own `msDS-AllowedToDelegateTo` own and so perform S4U2Self to impersonate anyone on the machine. 
{% endhint %}

## Practice:

{% tabs %}
{% tab title="Linux" %}
Find delegation:

```
findDelegation.py <DOMAIN>/<USER>:<PASSWORD> -target-domain <DOMAIN>
```

Exploit by requesting a TGS:

```
getST.py -spn 'CIFS/<COMPUTER>' -impersonate <DOMAIN_ADMIN> -dc-ip <DC_IP> <DOMAIN>/<USER>:<PASSWORD>
```

{% endtab %}

{% tab title="Windows" %}

```powershell
.\Rubeus.exe s4u /user:<USER> /rc4:<hash> /impersonateuser:Administrator /msdsspn:"CIFS/DC.DOMAIN.CORP" /altservice:ldap /ptt
```

{% endtab %}
{% endtabs %}

{% embed url="<https://www.cyberark.com/resources/threat-research-blog/weakness-within-kerberos-delegation>" %}
Blog de CyberArk
{% endembed %}

{% embed url="<https://beta.hackndo.com/constrained-unconstrained-delegation#constrained--unconstrained-delegation>" %}
Blog de Pixis
{% endembed %}

{% embed url="<https://www.guidepointsecurity.com/blog/delegating-like-a-boss-abusing-kerberos-delegation-in-active-directory>" %}

{% embed url="<https://book.hacktricks.xyz/windows-hardening/active-directory-methodology/silver-ticket#available-services>" %}