CONSTRAINED DELEGATION

PRIMARY CATEGORY → KERBEROS DELEGATIONS

Theory

KCD → Kerberos Constrained Delegation

KCD with Protocol Transition

• TRUSTED_TO_AUTH_FOR_DELEGATION enabled

Protocol Transition-related Flag/Value within the UserAccountControl Attribute

• msDS-AllowedToDelegateTo populated with a valid SPN

Object Attribute

The operator must control a domain account that has at least WriteProperty over the userAccountControl attribute of a domain service account, whether it’s a user account with at least one servicePrincipalName ( SPN ) set or a computer account

Moreover, the given controlled user account must have the seEnableDelegationPrivilege set

This is mandatory as the adversary must set the TRUSTED_TO_AUTH_FOR_DELEGATION flag in the userAccountControl of the given service account in order to enable KCD with Protocol Transition on the latter

Furthermore, the controlled user account must also have at least WriteProperty on the msDS-AllowedToDelegateTo in order to configure which services ( SPNs ) the service account in question is able to delegate to

If the last requirement is not met and the msDS-MachineAccountQuota domain attribute is not set to 0, one may think of leveraging the compromised domain user account to add a new computer account to the domain

When a machine joins the domain, a computer account related to the latter is created

Some folks may misunderstand the following concept, the owner of a domain computer account is not the user account that performs the connection operation, but rather the Domain Admins group

So, the user account in question cannot grant GenericAll ( FullControl ) to itself or create any other type of ACE in the computer account’s SecurityDescriptor DACL

However, it is granted with several sensitive rights and privileges over the computer account, such as WriteProperty over the UserAccountControl attribute, so we can enable KCD with protocol transition by editing this attribute and adding the TRUSTED_TO_AUTH_FOR_DELEGATION rights

The problem of this approach is that the given user account does not have Write rights over the msDS-AllowedToDelegateTo attribute of the computer account we recently added, so we cannot populate it with at least one SPN

If this attribute is empty, we cannot perform a valid S4U2Proxy as this kerberos extension is basically a TGS_REQ, and we need to specifiy a SPN, which does not exist

At this point, if we are not able to compromise a domain account that has at least WriteProperty over the msDS-AllowedToDelegateTo attribute of a service account, we can simply pivot to Unconstrained Delegation ( KUD ), for which we only need a user account with the seEnableDelegationPrivilege enabled

KCD w/o Protocol Transition

• msDS-AllowedToDelegateTo populated with a valid SPN

Object Attribute

During our assessment, we may not have access to a domain account with the seEnableDelegationPrivilege right, so we won’t be able to configure neither KUD nor KCD with Protocol Transition, as both require certain delegation flags to be enabled in the userAccountControl attribute of the service account in question, namely TRUSTED_FOR_DELEGATION and TRUSTED_TO_AUTH_FOR_DELEGATION

The same applies to KCD without Protocol Transition, in this case, it’s not necessary to modify and enable any delegation-related flag in the userAccountControl attribute of a domain service account, but we must populate the msDS-AllowedToDelegateTo

To do so, the following requirements must be met →

• At least WriteProperty over msDS-AllowedToDelegateTo

• seEnableDelegationPrivilege enabled for the account under our control

So yes, to enable and configure KCD w/o Protocol Transition, as with KUD and KCD with Protocol Transition, the seEnableDelegationPrivilege is required

Therefore, the key point here is that it’s mandatory to control a domain account which has seEnableDelegationPrivilege set in order to enable KUD and KCD ( both with and without Protocol Transition )

That said, in the absence of this powerful privilege, we will have to enumerate the existing delegations in the domain, which is somewhat unlikely

To do this, see Enumerating Kerberos Delegation

Overall Workflow

Zoom In

---

Abusing KCD with Protocol Transition

Workflow

Zoom In

Let us present a case with the following elements →

• Service A → Service Account with KCD with protocol transition enabled
• Administrator → Impersonated User Account (Victim)
• Service B → Service Account for which the ticket resulting from the S4U2Proxy is created for

Since Protocol Transition is enabled ( i.e. TRUSTED_TO_AUTH_FOR_DELEGATION flag enabled on userAccountControl attribute ), the service account (Service A) will receive a Forwardable Service Ticket as a result of the S4U2Self, unless the impersonated user (Administrator) belongs to the Protected Users group or “is sensitive and cannot be delegated”

The service account with the KCD enabled (Service A) can present this ticket as additional-ticket to the KDC’s TGS during a S4U2Proxy, and will receive a Service Ticket for the requested SPN (related to Service B), which must be an SPN of the msDS-allowedToDelegateTo attribute of that service account

Requirements

Enable Requirements

i.e. To enable it

• A controlled domain account with seEnableDelegationPrivilege

To modify both userAccountControl and msDs-AllowedToDelegateTo

• WriteProperty / GenericWrite / GenericAll over userAccountControl on the target service account

• WriteProperty / GenericWrite / GenericAll over msDS-AllowedToDelegateTo on the target service account

• The target account must have at least one SPN registered

i.e. It must be a service account ( e.g. a computer account or a user account with at least one SPN )

Abuse Requirements

• A controlled service account with KCD enabled

It’s required to authenticate ourselves as the latter to perform the Full S4U

• The impersonated account must not belong to the Protected Users Group

• The impersonated account is not configured with “Account is sensitive and cannot be delegated”

It’s a userAccountControl flag

UNIX-Like

See seEnableDelegationPrivilege

Carrying out a Full S4U → S4U2Self + S4U2Proxy

• Impacket’s getST.py

getST.py -spn 'cifs/SERVICE_B' -impersonate Administrator 'domain.local/SERVICE_A:<PASSWD>'

Passing the Ticket

Then, perform PtT with the obtained Service Ticket to the delegated service (AP Exchange) i.e. Service B

Windows

Carrying out a Full S4U → S4U2Self + S4U2Proxy

• Rubeus

rubeus.exe s4u /nowrap /msdsspn:'cifs/SERVICE_B' /impersonateuser:'Administrator' /user:'SERVICE_A' /domain:'domain.local' /password:'<PASSWD>'

Passing the Ticket

Then, perform PtT with the obtained Service Ticket to the delegated service (AP Exchange) i.e. Service B

Resources

The Hacker Recipes: Kerberos Delegation - KCD with Protocol Transition

---

Abusing KCD w/o Protocol Transition

Workflow

Zoom In

Let us present a case with the following elements →

• Service A → Service Account with KCD w/o protocol transition enabled
• User X → User Account that has GenericWrite on Service A to configure RBCD on it
• Administrator → Impersonated User Account (Victim)
• Service B → Service Account for which the ticket resulting from the S4U2Proxy is created for
• Service C → Computer account joined to the domain by the attacker to be able to perform RBCD on Service A

If a service account (service A) is configured with KCD w/o Protocol Transition, the Service Ticket resulting from an S4U2Self will not be Forwardable, because the TrustedToAuthForDelegation flag is not set in the UserAccountControl attribute of the service account

This Service Ticket also cannot be forwardable if the impersonated user (Administrator) belongs to the protected users group or “is sensitive and cannot be delegated

This means that the requirements for a successful S4U2Proxy are not met. Therefore, there is not a direct way to obtain a Forwardable Ticket from a service account with KCD w/o Protocol Transition enabled

However, there are different approaches that attackers can carry out to get a forwardable ticket, on behalf of a user, to the requesting service

The most feasible one, since no user interaction is needed, is by carrying out an RBCD attack to the service account with KCD enabled

RBCD + KCD Kerberos Only

The service account with KCD w/o Protocol Transition (Service A) must be configured for RBCD

In the end, our goal is to obtain a Forwardable Service Ticket, on behalf of a user (Administrator), to the KCD-enabled Service Account (Service A), to use it as additional ticket during a S4U2Proxy

So, we need to add a service account (Service C) of our control to the msDS-AllowedToActOnBehalfOfOtherIdentity attribute of the KCD-enabled Service Account (Service A)

In this way, an attacker can perform a S4U2Self + S4U2Proxy, from the controlled service account (Service C), to obtain a forwardable service ticket as the impersonated user (Administrator) to the KCD-enabled Service Account (Service A)

And then use this forwardable ticket on a S4U2Proxy from the KCD service account (Service A), on behalf of the user Administrator, to the Service B. Resulting in a Service Ticket that an attacker can use to authenticate as Administrator to Service B

Important

In order to configure RBCD on a service account, an attacker must have control over an account (User X) that has specific rights, such as GenericWrite, GenericAll or WriteProperty (among others), on that service account

There is a self-RBCD approach where any service account could set up RBCD for itself, but Microsoft seems to have patched it

Requirements

Enable Requirements

i.e. To enable it

• A controlled domain account with seEnableDelegationPrivilege

To modify msDs-AllowedToDelegateTo of the target service account

• WriteProperty / GenericWrite / GenericAll over msDS-AllowedToDelegateTo on the target service account

• The target account must have at least one SPN registered

i.e. It must be a service account ( e.g. a computer account or a user account with at least one SPN )

Abuse Requirements

• msDS-MachineAccountQuota greater than 0

• Controlled domain account allowed to add new computer accounts to the domain

• WriteProperty / GenericWrite / GenericAll over msDS-AllowedToActOnBehalfOfOtherIdentities

To enable RBCD on the target service account and get a Forwardable Service Ticket for S4U2Proxy

• Target service account controlled by the attacker

To perform the S4U2Proxy with the acquired Forwardable Service Ticket

UNIX-Like

Adding a Computer Account to the Domain

If an attacker does not have control over a service account, but has compromised any user account, the attacker can leverage of the Domain-Level MachineAccountQuota attribute of that user account to join a Computer Account (Service C) to the domain

• addcomputer.py

addcomputer.py

addcomputer.py -computer-name 'SERVICE_C$' -computer-pass 'SERVICE_C$PASSWD!' 'domain.local/USER_X:USER_XPASSWD!'

Setting Up RBCD on KCD-enabled Service Account

Having control over an account (User X) that has GenericWrite on the KCD-enabled Service Account allows an attacker to configure RBCD on that service account by adding the newly addedcomputer account to the msDS-ActOnBehalfOfOtherIdentity attribute

Thus, when the attacker performs a S4U2Self + S4U2Proxy from Service C, on behalf of the user Administrator, to the KCD-enabled Service, a Forwardable Service Ticket will be issued

• rbcd.py

rbcd.py

rbcd.py -delegate-to 'domain.local/SERVICE_A' -delegate-from 'SERVICE_C$' -action write 'domain.local/USER_X:USER_XPASSWD!'

S4U2Self + S4U2Proxy (Full S4U) from the Controlled Service Account to the KCD-enabled Service Account

Controlled Service Account = Newly added Computer Account

Once RBCD is configured on the KCD-enabled Service Account (Service A), just perform a Full S4U from the newly added Computer Account (Service C), as the Administrator User (impersonated), to that Service Account (Service A)

The SPN specified during the S4U2Proxy can be any (e.g. CIFS/TARGET, HOST/TARGET)

• getST.py

getST.py

getST.py -spn 'HOST/SERVICE_A' -impersonate 'Administrator' -dc-ip <DC> 'domain.local/SERVICE_C$:SERVICE_CPASSWD!'

We will receive a Forwardable Service Ticket issued as Administrator to the KCD-enabled Service

Additional S4U2Proxy

The attacker uses the received Forwardable Service Ticket to Service A as additional-ticket on a S4U2Proxy to request Service Ticket from the KCD-enabled Service Account (Service A), on behalf of Administrator, to the Service B

getST.py -spn 'HOST/SERVICE_B' -impersonate 'Administrator' -additional-ticket <SERVICE_A_ST.CCACHE> 'domain.local/SERVICE_A:SERVICE_APASSWD!'

A Service Ticket to Service B, in a CCACHE format, is obtained

Optional: Modifying Service Ticket’s SNAME

anySPN

Reference

Unlike the PAC, the SNAME field of a Service Ticket is not in the encrypted section of the ticket. This information is basically related to the requested SPN by the client

Therefore, an attacker could tamper it modifying its value to indicate another Service Class for the Service Ticket resulting from the S4U2Proxy

Related option → -altservice

getST.py -spn 'HOST/SERVICE_B' -altservice 'CIFS/SERVICE_B' -impersonate 'Administrator' -additional-ticket <SERVICE_A_ST.CCACHE> 'domain.local/SERVICE_A:SERVICE_APASSWD!'

Pass the Ticket

Then, perform PtT with the obtained Service Ticket to the delegated service (AP Exchange) i.e. Service B

Windows

🛠️⌛

Resources

The Hacker Recipes: Kerberos Delegation - KCD w/o Protocol Transition

---

Resources

The Hacker Recipes: Constrained Delegation

Deep Hacking: Constrained Delegation & RBCD

You do (not) Understand Kerberos Delegation