Resource-Based Constrained Delegation

Enabling unconstrained or constrained delegation on a computer requires the SeEnableDelegationPrivilege rights on domain controllers, which is only granted to enterprise and domain admins Resource-based constrained delegation (RBCD) 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 msDS-AllowedToDelegateTo. 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.

RBCD reverses this concept and puts control in the hands of the "backend" service instead, via a new attribute 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.

Requirements

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

Check rights

Get-DomainComputer | Get-ObjectAcl -ResolveGUIDs | Foreach-Object {$_ | Add-Member -NotePropertyName Identity -NotePropertyValue (ConvertFrom-SID $_.SecurityIdentifier.value) -Force; $_} | Foreach-Object {if ($_.Identity -eq $("$env:UserDomain\$env:Username")) {$_}}

AceQualifier           : AccessAllowed
ObjectDN               : CN=DC-2,OU=Domain Controllers,DC=dev,DC=cyberbotic,DC=io
ActiveDirectoryRights  : Self, WriteProperty
*ObjectAceType          : All*
ObjectSID              : S-1-5-21-569305411-121244042-2357301523-1000
InheritanceFlags       : ContainerInherit
BinaryLength           : 56
AceType                : AccessAllowedObject
ObjectAceFlags         : InheritedObjectAceTypePresent
IsCallback             : False
PropagationFlags       : None
SecurityIdentifier     : S-1-5-21-569305411-121244042-2357301523-1107
AccessMask             : 40
AuditFlags             : None
IsInherited            : True
AceFlags               : ContainerInherit, Inherited
InheritedObjectAceType : Computer
OpaqueLength           : 0

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.

Large output from the aforementioned command can be quickly parsed as followed:

Obtain principal with SPN

We'll then use this inside an SDDL to create a security descriptor. The content of msDS-AllowedToActOnBehalfOfOtherIdentity must be in raw binary format.

Create security descriptor

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.

Extract TGT from memory

Perform s4u

Pass the ticket into a logon session for use

To clear up, simply remove the msDS-AllowedToActOnBehalfOfOtherIdentity entry on the target.

powershell Get-DomainComputer -Identity dc-2 | Set-DomainObject -Clear msDS-AllowedToActOnBehalfOfOtherIdentity

If not local admin access to computer -> make own computer object

Create computer

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

The rest of the attack is the same...

For example -> Example attack

Last updated