PRIMARY CATEGORY → KERBEROS DELEGATIONS

RBCD → Resource-based Constrained Delegation

msDS-AllowedToActOnBehalfOfOtherIdentity

This attribute was introduce with Windows Server 2012

This implies that RBCD only works when the Domain Controller Functionality Level (DCFL) is Windows Server 2012 or higher


Workflow

Zoom In


RBCD

Let us present a case with the following elements →

  • Service AService Account for which RBCD is configured
  • AdministratorUser Account that is impersonated
  • User XUser Account that has GenericWrite ACE on the Service Account A
  • Service BComputer Account that User X joins to the domain

To configure RBCD on a service account (Service A), is mandatory that the attacker has control over an account (User X) that has an ACE such as GenericWrite or GenericAll on that service account (Service A)

Therefore, an attacker could use that controlled account (User X) to append the SID of another compromised service account (Service B) to the msDS-AllowedToActOnBehalfOfOtherIdentity attribute of the Service A

With that, the newly added Computer Account (Service B) can perform a Full S4U (S4USelf + S4U2Proxy) to request a Service Ticket, on behalf of the Administrator user, to the Service A

Then, the attacker can carry out a PtT with the S4U2Proxy Service Ticket

Adding a Computer Account to the Domain

Reference

The standard workaround when an attacker does not have control over a service account to perform a Full S4U, is to leverage the Domain-Level MachineAccountQuota (MAQ) attribute of a controlled user account (User X) to add an arbitrary computer account (Service B) to the domain

  • addcomputer.py

addcomputer.py

addcomputer.py -computer-name 'SERVICE_B$' -computer-pass 'SERVICE_CPASSWD!' 'domain.local/USER_X:USER_XPASSWD!'
Setting up RBCD on the Target Service Account

Microsoft patched the ability of a service account to configure RBCD for itself, i.e. the attacker did not need a domain account that had an EACs such as GenericWrite on the service account for which RBCD was to be configured

However, an attacker currently needs control over a domain account that has the mentioned EACs (GenericWrite, GenericAll, WriteProperty…) on the service account (Service A)

So, we append the SID of the newly added computer account (Service B) to the msDS-AllowedToActOnBehalfOfOtherIdentityattribute of the Service A in order to perform a Full S4U with Service B

  • rbcd.py

rbcd.py

rbcd.py -delegate-to 'SERVICE_B$' -delegate-from 'SERVICE_A' -action write 'domain.local/USER_X:USER_XPASSWD!'
Full S4U (S4U2Self + S4U2Proxy)

Once RBCD is configured for the given service account (Service A), an attacker could perform a Full S4U from the controlled computer account to request a Service Ticket, on behalf of the Administrator user, to Service A

The attacker can request any Service Class of the Target, i.e. any SPN from the Service Account A, such as HOST/SERVICE_A, CIFS/SERVICE_A

  • getST.py

getST.py

getST.py -spn 'HTTP/SERVICE_A' -impersonate 'Administrator' -dc-ip '<DC>' 'domain.local/SERVICE_B:SERVICE_BPASSWD!'

Resources

The Hacker Recipes: Resource-based Constrained Delegation - RBCD

Deep Hacking: Constrained Delegation & RBCD

You do (not) Understand Kerberos Delegation