Abusing resource-based constrained delegation

Some notes on performing a DHCPv6 hijack & abusing resource-based constrained delegation to impersonate administrators.

Lab Scenario

The infrastructure of this lab looks like the following:

DC01 - Windows Server 2012R2 with default ADDS, domain = testlab.local

DESKTOP-7J1BE72 - Victim machine, Windows 10 Pro, domain joined

Relaying NTLM to configure delegation

In this lab scenario, the attacker doesn't have access to any Active Directory credentials. Since the attacker is on the local network, a DHCPv6 man in the middle attack can be conducted. This attack exploits the IPV6 preference on Windows. We can create a rogue DHCPv6 server, which will allow us to control the DNS servers on the workstation.

*.testlab.local DNS records are now being spoofed to our attacker machine. From here, we can abuse the WPAD dns request as seen above. We can host a custom wpad file which the victim workstation will then request over HTTPS, when this request is made, it will also submit the NTLM hash of the associated computer account. From here, we can relay the NTLM hash to the Domain Controller and abuse existing permissions which the computer account has. By default, any Active Directory account has privileges to create up to 10 computer objects on the domain, User Objects & Computer Objects have this permission. Once we've relayed the NTLM hash to the domain controller, we can add a new computer to the domain, and also edit our own object. The attribute which we will modify is the "msDS-AllowedToActOnBehalfOfOtherIdentity", this attribute controls who can authenticate to the computer by any account via impersonation - this is resource-based constrained delegation and it is possible to maliciously craft the scenario above from 0 privileges within an enterprise environment.

Let's spin up ntlmrelayx:

(hax) ➜ tools git:(master) ✗ ntlmrelayx.py -t ldaps://dc01.testlab.local -wh attacker-wpad --add-computer --delegate-access --no-validate-privs --no-dump --no-da --no-acl

[*] Authenticating against ldaps://dc01.testlab.local as TESTLAB\DESKTOP-7J1BE72$ SUCCEED
[*] Assuming relayed user has privileges to escalate a user via ACL attack
[*] Attempting to create computer in: CN=Computers,DC=testlab,DC=local
[*] Adding new computer with username: MTSOVGQC$ and password: <$v]"%B)f{qppKt result: OK
[*] Delegation rights modified succesfully!
[*] MTSOVGQC$ can now impersonate users on DESKTOP-7J1BE72$ via S4U2Proxy

Kerberos Abuse

ntlmrelayx.py successfully relay's the credentials of the computer account to the domain controller. From here we create a new computer object & configure delegation on the authenticating computer account.

In order to confirm the success, let's authenticate to the domain controller using the newly created computer account & get a list of domain users.

Great, we can successfully authenticate to the domain using the computer account, not only that, we can impersonate any user in the environment to our victim machine. Let's impersonate "testuser-admin" (Sounds like this user might have privs?) on the machine.

In order to execute this attack, we have to request a service ticket for the machine, and impersonate the user of our choice. getST.py has been updated with the functionality to exploit resource based / unconstrained delegation by utilising s4u2self/s4uproxy. I highly recommend reading Dirk-jan Mollema's research on this subject.

This then provides us with a kerberos service ticket in which we can pass to the victim machine:

The screenshot below confirms that the user "testuser-admin" was a local administrator on the victim machine, a service was then created and started as SYSTEM:

From the research I'm reading this technique is highly effective in most environments due to the lack of controls around IPv6 and kerberos delegation.

Thanks for reading.