ADKERB-007: Resource-Based Constrained Delegation
- Platform
- Active Directory
- Category
- AD Kerberos Security
- Severity
- High
- Zero Trust pillar
- Identity (weight 3)
- Golden fixtures
- 3
- Branch coverage
- Observed: fixtures prove the verdicts they exercise
- Provenance
- baseline
What it checks
The check binds to the default naming context and runs an LDAP query for (&(|(objectClass=computer)(objectClass=msDS-GroupManagedServiceAccount))(msDS-AllowedToActOnBehalfOfOtherIdentity=*)). For every returned object it reads msDS-AllowedToActOnBehalfOfOtherIdentity, which is a raw octet string containing an NT Security Descriptor. Guerrilla parses the SD with System.Security.AccessControl.RawSecurityDescriptor, walks the DACL, and resolves every ACE SID to a sAMAccountName, distinguishedName, and objectClass. Each trustee is classified as expected (front-end web servers, IIS application pools, SQL service accounts with a documented business case) or unexpected (user accounts, low-privilege computer objects, recently created machine accounts with the default ms-DS-MachineAccountQuota of 10). The check also enumerates writers on the computer object itself by reading nTSecurityDescriptor and surfacing any non-default principal with GenericAll, GenericWrite, WriteDacl, WriteOwner, or the Validated-Write-Computer-AllowedToActOnBehalfOfOtherIdentity extended right (rightsGUID 3f78c3e5-f79a-46bd-a0b8-9d18116ddc79), because those rights enable an attacker to write the attribute even if it is currently empty. Findings are correlated against ms-DS-MachineAccountQuota on the domain root (default 10) to flag environments where any authenticated user can create the controlled computer object needed to complete the attack.
Why it matters
RBCD is the most reliable AD privilege-escalation primitive currently in active use by red teams and intrusion sets. Unlike traditional unconstrained or constrained delegation, configuring RBCD does not require Domain Admin or SeEnableDelegationPrivilege: it only requires write access to the target computer object. The default value of ms-DS-MachineAccountQuota is 10, which means any authenticated user can create a computer account (with a known password) and use it as the "controlled" service principal needed for the S4U2Self / S4U2Proxy chain. Combined with a single object-takeover primitive (often surfaced by BloodHound as GenericWrite or WriteOwner from a stale group, an over-privileged service account, or a relay-coerced machine account), an attacker can pivot to SYSTEM on the target host without touching LSASS, dumping the DC, or triggering protected-process restrictions. RBCD is also a popular persistence mechanism: an attacker who has briefly held Domain Admin can plant msDS-AllowedToActOnBehalfOfOtherIdentity entries on Tier 0 hosts (DCs, ADFS, ADCS, Exchange) granting a low-noise foothold account the ability to impersonate any user against those resources at will, surviving credential rotations and DA cleanup. Microsoft does not log writes to this attribute by default; without targeted SACLs, the modification is invisible in the Security event log.
Attack path
Step 1: Discovery. The attacker, holding any low-privilege foothold, runs BloodHound and queries for AddAllowedToAct edges or runs Guerrilla ADKERB-007 / Get-DomainComputer -ResolveSIDs -Properties msds-allowedtoactonbehalfofotheridentity to identify computers where the current principal (or any group they are in) has GenericWrite, GenericAll, WriteDacl, or WriteOwner. Common sources of this primitive: NTLM relay against LDAP/LDAPS without channel binding (the relayed machine account ends up with WriteDacl over itself via the "Pre-Windows 2000 Compatible Access" or default Domain Computers ACL), stale help-desk groups, Exchange shared permissions, SCCM client push installation accounts, and any service that resets computer passwords. Step 2: Controlled SPN creation. The attacker creates a new computer account using their existing user credentials, exploiting the default ms-DS-MachineAccountQuota of 10. Powermad New-MachineAccount -MachineAccount "evil$" -Password (ConvertTo-SecureString "Summer2026!" -AsPlainText -Force) or impacket addcomputer.py. The new account automatically gets a HOST/evil SPN, which is required for S4U2Self to issue a forwardable ticket. Step 3: Write the attribute. The attacker writes a security descriptor onto msDS-AllowedToActOnBehalfOfOtherIdentity of the target computer granting the new evil$ account the right to act on behalf of any user. PowerView Set-DomainRBCDelegation -Identity TARGET -DelegateFrom evil$ or impacket rbcd.py -delegate-from "evil$" -delegate-to "TARGET$" -action write. Step 4: S4U2Self. The attacker uses the evil$ credentials to request a service ticket to evil$ on behalf of a privileged user (typically Administrator) using S4U2Self. Rubeus s4u /user:evil$ /rc4:<NT hash> /impersonateuser:Administrator /msdsspn:HOST/TARGET. Because evil$ has an SPN, the KDC issues a forwardable ticket. Step 5: S4U2Proxy. The attacker presents the forwardable ticket back to the KDC asking for a service ticket to HOST/TARGET on behalf of Administrator. The KDC checks msDS-AllowedToActOnBehalfOfOtherIdentity on TARGET, sees evil$ is permitted, and issues a service ticket for Administrator to any SPN running on TARGET (CIFS, HOST, HTTP, MSSQLSvc, LDAP if the target is a DC). Step 6: Lateral movement. The attacker injects the service ticket and accesses the target as Administrator. PsExec.exe \\TARGET cmd.exe runs as SYSTEM. Against a domain controller this yields DCSync, against a CA it yields the ability to issue any certificate, against a Tier 0 management host it yields full AD takeover. The entire chain runs without ever touching LSASS or triggering Credential Guard.
How Guerrilla assesses it
Guerrilla performs three coordinated reads. First, an LDAP query for (&(|(objectClass=computer)(objectClass=msDS-GroupManagedServiceAccount))(msDS-AllowedToActOnBehalfOfOtherIdentity=*)) returns every object that currently has RBCD configured. The msDS-AllowedToActOnBehalfOfOtherIdentity octet string is parsed as a RawSecurityDescriptor and every DACL ACE is enumerated; SIDs are resolved against the local domain and trusted domains, and the trustee is classified by objectClass, group membership, whenCreated, and pwdLastSet (recently created machine accounts with no real service workload are flagged as attacker-controlled candidates). Second, the check reads the nTSecurityDescriptor on every computer object and flags non-default writers, specifically any principal outside Domain Admins, Enterprise Admins, SYSTEM, Account Operators, and Cert Publishers that holds GenericAll, GenericWrite, WriteDacl, WriteOwner, or the Validated-Write-Computer-AllowedToActOnBehalfOfOtherIdentity extended right (object GUID 3f78c3e5-f79a-46bd-a0b8-9d18116ddc79). Third, ms-DS-MachineAccountQuota is read from the domain root object; a value greater than zero combined with any unexpected RBCD writer raises the finding severity, because the attacker can self-provision the controlled SPN. Detection output includes the target computer, the principals listed in the SD, the principals with write access to the target, and the MachineAccountQuota value. When Advanced Audit Policy is enabled on the OU and the SACL on computer objects audits Write Property, the check also correlates Event 5136 (Directory Service Changes) entries for attribute LDAPDisplayName "msDS-AllowedToActOnBehalfOfOtherIdentity" from the last 90 days.
Recommended value
All RBCD configurations documented and audited. No unauthorized entries in msDS-AllowedToActOnBehalfOfOtherIdentity. Write access to computer objects restricted to authorized administrators only
Remediation
Enumerate RBCD configurations using Get-ADComputer -Filter {msDS-AllowedToActOnBehalfOfOtherIdentity -ne '$null'} -Properties msDS-AllowedToActOnBehalfOfOtherIdentity. Review each entry for business justification. Audit who has write access to computer objects in AD to identify potential RBCD abuse paths. Remove unauthorized RBCD entries. Implement monitoring for changes to the msDS-AllowedToActOnBehalfOfOtherIdentity attribute
Fixture-proven verdicts
Every verdict below is proven by a golden fixture in the module's gating test suite. This table derives from the last green run; it cannot be edited by hand.
| Scenario | Expected verdict |
|---|---|
| clean | PASS |
| known-bad | WARN |
| throttled | Not Assessed |
Framework mappings
- NIST SP 800-53
- AC-6
- CIS AD Benchmark
- 7.3.4
- MITRE ATT&CK
- T1550.003