(RBCD) Resource-based constrained
Last updated
Was this helpful?
Last updated
Was this helpful?
If an account, having the capability to edit the msDS-AllowedToActOnBehalfOfOtherIdentity attribute of another object (e.g. the GenericWrite ACE, see Abusing ACLs), is compromised, an attacker can use it populate that attribute, hence configuring that object for RBCD.
Machine accounts can edit their own msDS-AllowedToActOnBehalfOfOtherIdentity attribute, hence allowing RBCD attacks on relayed machine accounts authentications.
For this attack to work, the attacker needs to populate the target attribute with the SID of an account that Kerberos can consider as a service. A service ticket will be asked for it. In short, the account must be either (see for more information about the following):
a user account having a ServicePrincipalName set
an account with a trailing $ in the sAMAccountName (i.e. a computer accounts)
any other account and conduct with
The common way to conduct these attacks is to create a computer account. This is usually possible thanks to a domain-level attribute called MachineAccountQuota that allows regular users to create up to 10 computer accounts.
Then, in order to abuse this, the attacker has to control the account (A) the target object's (B) attribute has been populated with. Using that account's (A) credentials, the attacker can obtain a ticket through S4U2Self and S4U2Proxy requests, just like constrained delegation with protocol transition.
In the end, an RBCD abuse results in a Service Ticket to authenticate on the target service (B) on behalf of a user. Once the final Service Ticket is obtained, it can be used with Pass-the-Ticket to access the target service (B).
If the "impersonated" account is "" or a member of the "" group, the delegation will (probably) fail.
Nota bene: the native, RID 500, "Administrator" account doesn't benefit from that restriction, even if it's added to the Protected Users group (source: ).
There are a few additional details to keep in mind, valid as of the time of writing this note: Jan. 24th 2023.
In December 2020, along with patching the (CVE-2020-17049), Microsoft issued patching the CVE-2020-16996 vulnerability. While this second CVE has few information and details about it online, some lab testing indicates it may be linked to the verifications made by KDCs when receiving requests.
Before this patch, some testing indicates that accounts set as "sensitive and cannot be delegated" wouldn't be delegated (intended behavior), but members of the Protected Users group (and without the "sensitive" setting) would be (unintended !).
As it turns out, even after the patch, as of Jan. 24th 2023, members of the Protected Users group are now in fact protected against delegation, except for the native administrator account (RID 500), even if it's a member of the group. No idea if this is intended or not but it seems it's not the only security behavior of that group that doesn't apply for this account (e.g. RC4 pre-authentication still works for the RID-500 admin, even if member of the Protected Users group, source: ).
A technique called AnySPN or "service class modification" can be used concurrently with pass-the-ticket to change the service class the Service Ticket was destined to (e.g. for the cifs/target.domain.local SPN, the service class is cifs).
Once the ticket is obtained, it can be used with pass-the-ticket.
1 - Edit the target's "rbcd" attribute (ACE abuse) ****
's script (Python) _c_an be used to read, write or clear the delegation rights, using the credentials of a domain user that has the needed permissions.
Testers can also use to set the delegation rights with the --delegate-access option when conducting this attack from a relayed authentication.
In this example, controlledaccount can be a computer account created for the attack, or any other account -with at least one Service Principal Name set for the usual technique, or without for - which credentials are known to the attacker.
2 - Obtain a ticket (delegation operation) ****
Once the attribute has been modified, the script (Python) can then perform all the necessary steps to obtain the final "impersonating" ST (in this case, "Administrator" is impersonated but it can be any user in the environment).
In , the delegation will not work. Depending on the context, the vulnerability (CVE-2020-17049) can be used with the -force-forwardable option to try to bypass restrictions.
The SPN (Service Principal Name) set can have an impact on what services will be reachable. For instance, cifs/target.domain or host/target.domain will allow most remote dumping operations (more info on ). There however scenarios where the SPN can be changed (AnySPN) to access more service. This technique is automatically tried by Impacket scripts when doing pass-the-ticket.
3 - Pass-the-ticket ****
In order to run the following commands and tools as other users, testers can check the part.
1 - Edit the target's security descriptor (ACE abuse) ****
The 's cmdlets Set-ADComputer and Get-ADComputer can be used to write and read the attributed of an object (in this case, to modify the delegation rights).
PowerSploit's module is an alternative that can be used to edit the attribute ().
FuzzSecurity's project is another alternative in C# (.NET assembly) to edit the attribute ().
2 - Obtain a ticket (delegation operation) ****
can then be used to request the TGT and "impersonation ST" and inject it for later use.
In , the delegation will not work. Depending on the context, the vulnerability (CVE-2020-17049) can be used with the /bronzebit flag to try to bypass restrictions.
The SPN (Service Principal Name) set can have an impact on what services will be reachable. For instance, cifs/target.domain or host/target.domain will allow most remote dumping operations (more info on ). There however scenarios where the SPN can be changed (AnySPN) to access more services. This technique can be exploited with the /altservice flag with Rubeus.
3 - Pass-the-ticket ****
