Resource-Based Constrained Delegation is one of the more consistently exploited Active Directory misconfigurations in modern internal penetration tests, largely because it is easy to misconfigure and often overlooked during routine hardening reviews. Unlike classic unconstrained or constrained delegation, RBCD shifts the trust decision to the resource itself, which sounds safer on paper but frequently creates a path for attackers to escalate from a single compromised low-privileged account to full control over a target system. This deep dive covers how RBCD works, how attackers actually exploit it, and how to find and close the gap before it becomes a foothold. Internal Active Directory assessments run by Sagefox Cybersecurity routinely include this exact attack path as part of privilege escalation testing.
Understanding Delegation in Active Directory
Why Delegation Exists in the First Place
Delegation allows a service to authenticate to other services on behalf of a user, which is necessary in multi-tier applications where a front-end service needs to access a back-end resource using the original user's identity rather than its own service account credentials. Classic examples include a web application authenticating to a database server on behalf of the logged-in user.
The Shift from Unconstrained to Resource-Based Delegation
Unconstrained delegation, the original model, allowed a service to impersonate a user to any other service in the domain, which is dangerously broad and has long been flagged as a high-risk configuration. Constrained delegation narrowed this to a specific list of services a given account could delegate to. Resource-Based Constrained Delegation flipped the trust model again: instead of the delegating account specifying what it can access, the resource itself specifies which accounts are allowed to delegate to it, controlled through the msDS-AllowedToActOnBehalfOfOtherIdentity attribute on the target computer object.
Why This Model Introduces New Risk
Because the trust decision lives on the resource object rather than requiring domain administrator involvement to configure, any account with write access to a computer object's attributes, including the ability to modify that specific property, can configure delegation to itself. This means a compromised account with seemingly limited privileges, but with write access to a computer object, can potentially grant itself the ability to impersonate any user, including domain administrators, against that computer.
How the RBCD Attack Chain Works
Step One: Identifying Write Access to a Computer Object
The attack begins by identifying any computer object in the domain where the currently compromised account has write permissions, specifically the ability to modify the msDS-AllowedToActOnBehalfOfOtherIdentity attribute. This commonly occurs when a user account has been granted excessive permissions over an OU or specific object, sometimes unintentionally through delegated administration.
bloodhound-python -u compromised_user -p 'Password123' -ns 10.10.10.10 -d target.local -c AllLoading the resulting data into BloodHound and querying for outbound object control edges quickly reveals which computer objects the compromised account can write to.
Step Two: Creating a Controlled Computer Account
A standard domain user is, by default, permitted to create up to ten computer accounts in the domain through the ms-DS-MachineAccountQuota attribute. This gives an attacker with no elevated privileges at all a way to create an account they fully control, which becomes the account granted delegation rights in the next step.
python3 addcomputer.py -computer-name 'ATTACKERPC$' -computer-pass 'Password123!' \
-dc-ip 10.10.10.10 target.local/compromised_user:Password123Step Three: Configuring RBCD on the Target Object
With write access to the target computer object confirmed, and a controlled computer account created, the attacker configures the target's delegation attribute to trust the newly created attacker-controlled computer account.
python3 rbcd.py -delegate-from 'ATTACKERPC$' -delegate-to 'TARGETSERVER$' \
-dc-ip 10.10.10.10 -action write target.local/compromised_user:Password123This modifies the msDS-AllowedToActOnBehalfOfOtherIdentity attribute on the target server object, establishing that the attacker-controlled machine account is now permitted to delegate on behalf of any user to that target.
Step Four: Requesting a Service Ticket via S4U2Self and S4U2Proxy
With delegation configured, the attacker uses the Kerberos S4U2Self and S4U2Proxy extensions to request a service ticket impersonating a high-value target, such as a domain administrator, to the target server.
python3 getST.py -spn cifs/targetserver.target.local -impersonate 'DomainAdmin' \
-dc-ip 10.10.10.10 target.local/ATTACKERPC\$:Password123!This produces a valid Kerberos ticket granting access to the target server's CIFS service as the impersonated domain administrator account, without ever needing that account's actual password or hash.
Step Five: Using the Forged Ticket for Access
The generated ticket is loaded into the current session's Kerberos cache, granting the attacker access to the target system with the impersonated user's privileges.
export KRB5CCNAME=DomainAdmin.ccache
python3 psexec.py -k -no-pass target.local/DomainAdmin@targetserver.target.localIf the impersonated account has administrative rights on the target server, this results in full command execution on that system, all originating from what started as a single compromised low-privileged domain account with no special permissions beyond writing to one computer object's attributes.
Why This Attack Path Is So Common in Real Environments
Machine Account Quota Is Rarely Reviewed
The default ms-DS-MachineAccountQuota value of 10 is almost never changed after domain deployment, meaning nearly every standard domain user in an unhardened environment already has the ability to create the controlled computer account this attack chain depends on.
Overly Broad Delegated Permissions
Organizations frequently delegate administrative rights over specific OUs or object types to help desk teams or junior administrators without fully scoping what those permissions actually allow. Write access to computer object attributes is often bundled into broader delegation without anyone realizing it enables this specific escalation path.
Limited Visibility Into Object-Level ACLs
Traditional security reviews often focus on group membership and explicit role assignments, while object-level access control lists on individual computer and user objects receive far less scrutiny, despite being exactly where this kind of exploitable permission tends to hide.
Finding RBCD Exposure in Your Own Environment
Auditing Machine Account Quota
Checking the current machine account quota setting is a quick first step in assessing exposure to the account creation portion of this attack chain.
Get-ADDomain | Select-Object -ExpandProperty ms-DS-MachineAccountQuotaA value above zero means standard domain users can create computer accounts, which is a prerequisite for the most common version of this attack.
Identifying Existing RBCD Configurations
Reviewing which computer objects already have a value set for msDS-AllowedToActOnBehalfOfOtherIdentity reveals existing delegation configurations that should be validated against actual business need.
Get-ADComputer -Filter * -Properties msDS-AllowedToActOnBehalfOfOtherIdentity |
Where-Object { $_.'msDS-AllowedToActOnBehalfOfOtherIdentity' -ne $null } |
Select-Object Name, msDS-AllowedToActOnBehalfOfOtherIdentityMapping Write Access with BloodHound
Running a full BloodHound collection and reviewing the resulting attack paths for edges representing generic write, write property, or owns permissions against computer objects surfaces the specific accounts and groups that could exploit this path today, not just in theory.
neo4j console
bloodhoundQuerying for paths where a non-administrative principal has write access to a computer object attribute gives a concrete, prioritized list of what to remediate first, ranked by how directly it connects to high-value targets like domain controllers.
Fixing and Hardening Against RBCD Abuse
Reducing the Machine Account Quota to Zero
Unless a specific business process requires standard users to create computer accounts, which is rare, setting the quota to zero removes the most common enabler of this attack chain entirely.
Set-ADDomain -Identity target.local -Replace @{"ms-DS-MachineAccountQuota"="0"}Reviewing and Tightening Delegated Permissions
Any delegated administrative permissions over OUs containing computer objects should be reviewed specifically for write access to the msDS-AllowedToActOnBehalfOfOtherIdentity attribute and scoped down to only what the delegated role actually requires.
dsacls "OU=Servers,DC=target,DC=local" | Select-String "Allowed-To-Act"Monitoring for Suspicious Delegation Attribute Changes
Enabling auditing on changes to the msDS-AllowedToActOnBehalfOfOtherIdentity attribute allows detection teams to alert on modifications to this attribute outside of expected change windows, since legitimate business reasons to modify this attribute are relatively rare compared to routine administrative activity.
auditpol /set /subcategory:"Directory Service Changes" /success:enable /failure:enableCombined with a SIEM rule specifically watching for event ID 5136 referencing this attribute, security teams can catch an active exploitation attempt in near real time rather than discovering it during a post-incident review.
Protecting High-Value Accounts from Delegation Entirely
Marking sensitive accounts, particularly domain administrators and other tier-zero identities, as "Account is sensitive and cannot be delegated" prevents them from being impersonated through any delegation mechanism, including RBCD, regardless of what delegation configuration an attacker manages to establish elsewhere.
Set-ADUser -Identity "DomainAdminAccount" -AccountNotDelegated $trueCommon Mistakes When Assessing or Remediating RBCD Risk
Focusing Only on Existing Delegation Configurations
Reviewing what delegation is currently configured misses the larger risk, which is what delegation could be configured by an attacker with the right write access. A thorough review needs to include ACL analysis across computer objects, not just a snapshot of current delegation settings.
Reducing Machine Account Quota Without Addressing Existing ACL Issues
Setting the quota to zero closes one path but does not address accounts that already have write access to computer objects through legacy delegated permissions. Both issues need remediation together, since an attacker who already controls a domain-joined machine does not need to create a new computer account at all.
Treating This as a One-Time Fix
Delegated permissions and object ACLs drift over time as IT staff change and new delegation gets granted for temporary projects that are never revoked. Periodic BloodHound-style ACL reviews, not just a one-time hardening pass, are necessary to keep this risk contained long term.
Key Takeaways
Resource-Based Constrained Delegation moved trust decisions closer to the resource itself, but that shift also means far more accounts in a typical environment end up with the ability to grant delegation than administrators usually realize. The attack chain from a single compromised low-privileged account to domain administrator access is well documented, repeatable, and does not require any password cracking or credential theft beyond the initial foothold. Reducing machine account quota, tightening object-level ACLs, and monitoring changes to delegation attributes together close most of the exposure this attack path depends on.
If your organization wants a thorough Active Directory assessment that maps out delegation and ACL-based escalation paths before an attacker finds them, the team at Sagefox Cybersecurity can help identify and close these gaps.
