RBCD
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 $frontRBCD 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:
The attacker has write permissions on the
msDS-AllowedToActOnBehalfOfOtherIdentityattribute of a target computer object (the back-end, e.g.,[BACK_SERVER_1]).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:
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-MachineAccountQuotais > 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]):
Second, from [WORKSTATION_1] (where we have SYSTEM), we dump the computer account's TGT:
Third, we use Rubeus s4u to impersonate an [ADMIN_USER] targeting [BACK_SERVER_1], using the TGT of [WORKSTATION_1]$:
Step 4: Accessing the Target
We have obtained a ticket for cifs/[BACK_SERVER_1] as [ADMIN_USER]. Now we use it:
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:
Modify
msDS-AllowedToActOnBehalfOfOtherIdentity: They can add a principal of their choice to the trust list.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.
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.
"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
Step 3: Execute the S4U Attack (Targeting Self)
The attacker executes S4U, impersonating an [ADMIN_USER] towards itself, but pointing to the chosen SPN.
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].
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:
In the "Shadow Credentials" scenario, they would revert the self-trust and delete the fake SPN (if Method A was used).
Última actualización