Kerberos Resource-based Constrained Delegation: Computer Object Takeover
Last updated
Last updated
It's possible to gain code execution with elevated privileges on a remote computer if you have WRITE privilege on that computer's AD object.
This lab is based on a video presented by -
High level overview of the attack as performed in the lab:
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);
User sandy
leverages the WRITE
privilege on the WS01
computer object and updates its 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 that the target computer WS01
is happy for the computer FAKE01
to impersonate any domain user and give them any access (even Domain Admin privileges) to 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 - we can now access the c$
share of ws01
from the computer ws02
.
In unconstrained and constrained Kerberos delegation, a computer/user is told what resources it can delegate authentications to;
In resource based Kerberos delegation, computers (resources) specify who they trust and who can delegate authentications to them.
Target computer
WS01
Admins on target computer
spotless@offense.local
Fake computer name
FAKE01
Fake computer SID
To be retrieved during attack
Fake computer password
123456
Windows 2012 Domain Controller
DC01
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
The attack also requires the DC to be running at least Windows 2012, so let's check if we're in the right environment:
Last thing to check - the target computer WS01
object must not have the attribute msds-allowedtoactonbehalfofotheridentity
set:
This is the attribute the above command is referring to:
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 WS01
later on:
Checking if the computer got created and noting its SID:
Create a new raw security descriptor for the FAKE01
computer principal:
Applying the security descriptor bytes to the target WS01
machine:
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:
We can test if the security descriptor assigned to computer ws01
in msds-allowedtoactonbehalfofotheridentity
attribute refers to the fake01$
machine:
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:
Let's generate the RC4 hash of the password we set for the FAKE01
computer:
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:
Unfortunately, in my labs, I was not able to replicate the attack at first, even though according to 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 TGS ticket for spotless
for the CIFS service at ws01.offense.local
, but the attack still did not work:
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
:
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:
Note that the offense\spotless
rights are effective only on the target system - i.e. on the system that delegated (WS01
) another computer resource (FAKE01
) to act on the target's (WS01
) behalf and allow to impersonate any domain user.
In other words, an attack can execute code/commands as offense\spotless
only on the WS01
machine and not on any other machine in the domain.