Resource-based constrained delegation: from foothold to domain admin

What resource-based constrained delegation is

Kerberos delegation allows a service to request tickets on behalf of an authenticated user. When a front-end web server needs to call a back-end database as the user who logged in, some form of delegation carries that identity through the hop. Classic constrained delegation, introduced in Windows Server 2003, is configured by domain administrators on the calling service account: the admin decides which services that account may delegate to, and the permission lives in the caller's own AD attributes.

Resource-based constrained delegation, added in Windows Server 2012, reverses the control. Instead of the caller's admin configuring outbound delegation, the target machine controls which accounts may delegate to it. The permission is stored in msDS-AllowedToActOnBehalfOfOtherIdentity on the target computer object. Any principal that holds GenericWrite, GenericAll, WriteDACL or WriteOwner on that object can populate the attribute without domain admin involvement.

That is what makes RBCD dangerous in an assumed breach exercise. The tester begins with a valid, low-privilege account. If that account holds write rights on a computer object anywhere in the domain, RBCD is a viable path to domain admin. The scoping document for an assumed breach engagement defines the foothold and the objectives; this technique sits in the Through phase of the Unified Kill Chain, where the tester moves from initial access toward the stated objective.

Finding computer objects with exploitable write rights

BloodHound is the fastest way to identify RBCD candidates. After collecting data with SharpHound, the Outbound Object Control panel for the owned principal lists every AD object the account can write to. Computer objects with GenericWrite or higher are the targets. The Cypher query below runs directly in BloodHound's raw query view and returns the same list without navigating the UI.

PowerView reaches the same data without a graph database. Get-DomainObjectAcl returns the full access control list for a named object, and filtering on the foothold account's SID shows whether the right is present. For a domain with many computer objects, running the query against each result from Get-DomainComputer is slower but needs no BloodHound infrastructure on the engagement.

The right to watch for is not only GenericWrite. WriteDACL lets the account grant itself any other right, so it is equivalent in practice. WriteOwner lets the account take ownership and then modify the DACL from there. An infrastructure penetration test will record all three classes when it audits Active Directory, but an assumed breach tester is looking for any viable path rather than a full inventory.

MATCH p=shortestPath((u:User {owned:true})-[r:GenericWrite|GenericAll|WriteDACL|WriteOwner*1..]->(c:Computer))
RETURN p

# Run from a session using the foothold account
Get-DomainObjectAcl -Identity 'WORKSTATION01$' -ResolveGUIDs |
  Where-Object { $_.SecurityIdentifier -eq (Get-DomainUser foothold_user).objectsid } |
  Select-Object ObjectAceType, ActiveDirectoryRights

Registering a machine account and writing the delegation attribute

RBCD requires a source account: the one that will request the impersonated ticket. A machine account is the right tool here, because only machine accounts and certain service accounts can use S4U2Self, the first step of the impersonation exchange. In most Active Directory domains, the MachineAccountQuota attribute on the domain object is set to 10, meaning any authenticated user can add up to ten machine accounts. The foothold account does this without elevated rights.

With the machine account created, the tester writes its SID into msDS-AllowedToActOnBehalfOfOtherIdentity on the target computer object. The value is a security descriptor in binary format, not a plain SID string. Impacket's rbcd.py handles the encoding. The write takes a single authenticated request to a domain controller and succeeds as soon as the foothold account's write right is confirmed. The LSASS dumping article in this cluster covers credential access from a local admin context; RBCD is the alternative path when the foothold never reaches local admin on a machine that matters.

One detail to verify before writing the attribute: the target computer must be running Windows Server 2012 or later, and the domain functional level must be at least Windows Server 2012. Both conditions hold in almost every live environment, but Get-ADDomain returns the functional level in one line and takes a second to check.

python3 addcomputer.py -computer-name 'ATTACKER$' \
  -computer-pass 'P@ssw0rd123!' \
  -dc-ip 10.10.10.1 \
  'victim.example/foothold_user:UserPassword1'

# Output
[*] Successfully added machine account ATTACKER$ with password P@ssw0rd123!

python3 rbcd.py -delegate-from 'ATTACKER$' \
  -delegate-to 'WORKSTATION01$' \
  -action write \
  -dc-ip 10.10.10.1 \
  'victim.example/foothold_user:UserPassword1'

# Output
[*] Attribute msDS-AllowedToActOnBehalfOfOtherIdentity is empty
[*] Delegation rights modified successfully!

Requesting the impersonated service ticket

The impersonation exchange is two steps. First, the machine account requests a service ticket to itself on behalf of the target user, using S4U2Self. The KDC issues this ticket based solely on the machine account's own ticket-granting ticket and the target user's principal name: no password or hash for the target user is required. Second, the machine account presents that ticket in an S4U2Proxy request, asking for a ticket to the target service. The KDC validates that the machine account is listed in the target's msDS-AllowedToActOnBehalfOfOtherIdentity and issues the ticket with the target user's identity embedded.

Because the ticket is issued by the KDC under normal authentication flow, it appears in event logs as a standard Kerberos service ticket request. MITRE ATT&CK records delegation abuse under T1558 Steal or Forge Kerberos Tickets within the TA0004 Privilege Escalation tactic. The technique exploits the design of the delegation mechanism rather than a software vulnerability, a case CWE-266 Incorrect Privilege Assignment covers: the domain granted the foothold account a configuration right it was never intended to have. Logon events from the impersonated account are also generated: T1078 Valid Accounts at MITRE ATT&CK describes how legitimate credentials are used for access, and event ID 4624 at the target records the authentication.

With the ticket cached, the tester connects to the target machine. Any Kerberos-aware tool accepts it. Using psexec.py demonstrates command execution; secretsdump.py demonstrates credential access from the target. If the target is a domain controller, secretsdump over the impersonated ticket achieves DCSync and retrieves all domain account hashes. The cloud token theft article in this cluster shows what a tester does after reaching domain level in an environment with Azure AD integration.

python3 getST.py -spn 'cifs/WORKSTATION01.victim.example' \
  -impersonate 'Administrator' \
  -dc-ip 10.10.10.1 \
  'victim.example/ATTACKER$:P@ssw0rd123!'

# Output
[*] Getting TGT for user
[*] Impersonating Administrator
[*]   Requesting S4U2self
[*]   Requesting S4U2Proxy
[*] Saving ticket in Administrator.ccache

export KRB5CCNAME=Administrator.ccache
python3 psexec.py -k -no-pass 'victim.example/[email protected]'

# Output
[*] Requesting shares on WORKSTATION01.victim.example.....
[*] Found writable share ADMIN$
[*] Uploading file ...
Microsoft Windows [Version 10.0.19045.4651]
(c) Microsoft Corporation. All rights reserved.

C:\Windows\system32>

What the attack leaves in event logs

The RBCD chain writes to Active Directory before it requests any ticket, and that write is the most reliable detection point. Windows event ID 5136 is emitted every time an AD object attribute is modified; a SIEM rule filtering on attribute name msDS-AllowedToActOnBehalfOfOtherIdentity catches the write regardless of which tool performed it. The event carries the account that made the change, the target object, and the new attribute value. This is the class of signal that your SIEM should capture during an assumed breach exercise.

The S4U2Proxy exchange produces event ID 4769 at the domain controller, as it does for any Kerberos service ticket request. What distinguishes an RBCD-sourced ticket is the presence of a Transited-Services field in the ticket, which names the intermediate service account. Filtering 4769 events where Transited-Services is non-empty and the requesting account name ends in $ is a reliable heuristic for delegation abuse, though it fires on legitimate constrained delegation as well. Pairing it with a preceding 5136 on the same computer object removes the false positives.

Once the misconfiguration is found, hardening is fast. Remove the write right from any account that does not operationally need it. Setting MachineAccountQuota to 0 on the domain object removes the ability to add machine accounts without elevated rights, closing the first step for accounts that do not already control one. Placing high-value accounts in the Protected Users security group prevents them from being impersonated through any form of delegation. For organisations that want a formal demonstration against production controls, the red team engagement is the appropriate context; a targeted assumed breach test scoped to this technique specifically gives a faster answer to whether this path is open.

RBCD misconfigurations in UAE Active Directory environments

Active Directory remains the dominant identity infrastructure in UAE enterprise environments, covering government entities in Abu Dhabi and commercial organisations across Dubai's free zones and mainland. The RBCD misconfiguration described in this article, accounts with write rights on computer objects, appears in almost any domain that has grown through mergers, departmental provisioning or legacy service account management without a formal AD hygiene program. No single deployment decision creates it deliberately; it accumulates over time.

Several UAE regulatory frameworks require security testing, and this misconfiguration falls within their scope. The UAE Information Assurance Regulation, published by TDRA and applicable federally, requires organisations to identify and remediate privilege escalation paths in their directory services. CBUAE guidance for financial institutions operating in Abu Dhabi and Dubai includes requirements for access control testing and privileged access management. An assumed breach exercise scoped to Active Directory privilege escalation addresses those requirements directly, because it starts from the realistic position of a compromised insider account rather than testing whether the perimeter can be breached.

DESC governs Dubai government entities and their direct suppliers. Its technical security standard requires periodic access rights reviews, which should include a review of write rights on computer objects in Active Directory. For organisations subject to DESC, documenting an assumed breach test that surfaces and remediates an RBCD path provides evidence of that review in a form that is specific, reproducible and verifiable.

The findings from an assumed breach test of this kind carry more weight with an internal audit or external regulator than a vulnerability scan, because they demonstrate the actual distance from a compromised account to domain admin rather than reporting a configuration flag. That distance is what a risk assessment needs to measure.

Frequently asked questions