Last updated
Last updated
Enabling unconstrained or constrained delegation on a computer requires the user right assignment on domain controllers, which is only granted to enterprise and domain admins. Windows 2012 introduced a new type of delegation called resource-based constrained delegation (RBCD), which allows the delegation configuration to be set on the target rather than the source.
To compare - constrained delegation is configured on the "front-end" service via its msDS-AllowedToDelegateTo attribute. The example provided previously was where cifs/dc-2.dev.cyberbotic.io was in the msDS-AllowedToDelegateTo attribute of SQL-2. This allowed the SQL-2 computer account to impersonate any user to any service on DC-2, and DC-2 really had no "say" over it.
RBCD reverses this concept and puts control in the hands of the "backend" service instead, via a new attribute called msDS-AllowedToActOnBehalfOfOtherIdentity. This attribute also does not require SeEnableDelegationPrivilege to modify. Instead, you only need a privilege like WriteProperty, GenericAll, GenericWrite or WriteDacl on the computer object. This makes it much more likely to present itself as a privilege escalation / lateral movement opportunity.
The two major prerequisites to pull off the attack are:
A target computer on which you can modify msDS-AllowedToActOnBehalfOfOtherIdentity.
Control of another principal that has an SPN.
This query will obtain every domain computer and read their ACL, filtering on the interesting rights. This will produce a handful of results, but the one shown is the one of interest. It shows that the Developers group has WriteProperty rights on all properties (see the ObjectAceType) for DC-2.
A common means of obtaining a principal with an SPN is to use a computer account. Since we have elevated privileges on Workstation 2, we can use that. To start the attack, we need its SID.
We'll then use this inside an SDDL to create a security descriptor. The content of msDS-AllowedToActOnBehalfOfOtherIdentity must be in raw binary format.
These descriptor bytes can then be used with Set-DomainObject. However, since we're working through Cobalt Strike, everything has to be concatenated into a single PowerShell command.
Next, we use the WKSN-2$ account to perform the S4U impersonation with Rubeus. The s4u command requires a TGT, RC4 or AES hash. Since we already have elevated access to it, we can just extract its TGT from memory.
Then perform the s4u.
Finally, pass the ticket into a logon session for use.
To clear up, simply remove the msDS-AllowedToActOnBehalfOfOtherIdentity entry on the target.
If you did not have local admin access to a computer already, you can resort to creating your own computer object. By default, even domain users can join up to 10 computers to a domain - controlled via the ms-DS-MachineAccountQuota attribute of the domain object.
Rubeus hash can take that password and calculate their hashes.
These can then be used with asktgt to obtain a TGT for the fake computer.
And the rest of the attack is the same.
is a post-ex toolkit written by and has the functionality to create a computer with a random password.