TL;DR Unconstrained delegation is not a default setting on Windows domain computers, but it is something to be aware of. It can allow an attacker to PTT if they gain local admin rights and lead to complete domain compromise.
Introduction
Unconstrained delegation is not new, but it was new to me. I have not heard too many “vendor neutral” courses/certs cover it, much less demonstrate it, so I figured it was worth writing a howto on. Pentester Academy’s Attacking and Defending Active Directory course and lab by Nikhil Mittal did cover how to abuse this feature and Pass The Ticket (PTT) in order to escalate privileges. His course & lab were excellent. I highly recommend it if your workplace utilizes a Windows domain! (Review located here)
Essentially Unconstrained Delegation is a feature that can be enabled on a Windows domain system. It allows that system to impersonate users who are logged into it. This may be useful for some legacy services. By default only Domain Controllers (DCs) have unconstrained delegation enabled. This is not really a security concern as only sysadmins should be allowed to login to DCs. Furthermore if an attacker gains access to a DC then it is already game over. Sean Metcalf has a great guide on DC hardening, it is highly recommended reading.
It should be noted that by default Active Directory (AD) accounts are not marked as ‘sensitive and cannot be delegated’. This means that if that account logs into a system that has unconstrained delegation enabled then the account’s Kerberos tickets can be abused, aka used in a PTT attack.
Lab Setup
Running this exercise in the lab involves a few things. A minimum of three systems are required; a DC, a member server with unconstrained delegation enabled, and a workstation that is used as the attacker. A Domain Admin account should be logged into the member server. We are assuming that the attacker has managed to gain local admin access to the member server. The attack can be performed remotely from PowerShell on the attacker’s system.
We start by enabling unconstrained delegation on our member server:
Set-ADComputer -Identity TestIPAM -TrustedForDelegation $trueWe create a new account named Frisky McRisky, add them to Domain Admins & the Protected Users Group, and log them into the member server.
The Protected Users group forces Kerberos authentication, prevents caching credentials, and goes a long way towards mitigating Pass The Hash (PTH). It does not prevent PTT.
We then confirm unconstrained delegation exists by:
Get-ADComputer -Filter {TrustedForDelegation -eq $true -and primarygroupid -eq 515} -Properties * | Select-Object CN
Specifying we only want the well known group SID 515 in the query results screens out the DCs from the results and returns only Domain Computers.
The Attack
Given the above conditions the attack is pretty straightforward to execute. Benjamin Delpy’s tool Mimikatz takes care of the heavy lifting.
The attacker
- Disables Windows Defender on the remote server with unconstrained delegation (enumerated earlier)
- Loads Mimikatz on the remote server
- Creates a subfolder to put tickets in
- Uses Mimikatz to dump the tickets
- Lists the tickets
- Selects the one they wish to abuse to move laterally and/or escalate privileges
- Executes PTT
- Confirms that privileges were escalated
Now that the attacker has compromised Frisky McRisky’s account via PTT they can abuse the newly gained Domain Admin privileges. One of the quickest ways to do this is to simply execute DCSync immediately following PTT and grab the krbtgt hash for the domain.
Once an attacker has the krbtgt hash it is game over. You are rebuilding the entire Forest in order to be sure that you have eradicated them from your environment. This is because they can simply forge Kerberos tickets and impersonate any user they want to. They can also do this across any domain trusts that exist. We covered creating Golden Tickets in a prior article.
Mitigation
The unconstrained delegation that enables PTT is not a Windows default. Therefore mitigation is rather straightforward; simply audit for any servers in your environment that have it enabled. If there is a business case and an approved exemption for one then put extra monitoring on it and ensure any access to it as local admin is treated as the potential compromise of the entire domain that it is. If any Domain Admins, or anyone that has the privileges to execute DCSync, needs to access that server then ensure that their AD account is set to ‘sensitive and cannot be delegated’.
Sidenote on auditing for DCSync privileges
We covered how to audit for exactly who has the privileges required to execute DCSync here using Paramount Defenses pre-populated AD, but to recap:
PS C:\> Import-Module ActiveDirectoryPS C:\> Set-Location AD:PS AD:\> (Get-ACL ‘dc=corp,dc=local’).Access | Where {$_.ObjectType -Like “1131f6aa-9c07–11d1-f79f-00c04fc2dcd2” -and “1131f6ad-9c07–11d1-f79f-00c04fc2dcd2”}
Then list all members of these groups via
Get-ADGroupMember “CN=Administrators,CN=Builtin,DC=corp,DC=local” -Recursive | Select-Object Name
Summary
I always try to stress a simple truth in Windows domain security; don’t focus on the specific attacker tool. Focus on the misconfiguration, excessive privileges, or failure to follow best practices that allowed that tool to work in your environment.
Most of these tools are free and open source. They exist on both Windows and Linux. Many are included in Kali, for example, ‘out of the box’ or are easy to install by loading the Impacket Framework. Don’t count on your antimalware to block the tool as even intermediate attackers may modify it to evade blacklists and signature based defenses.
Block the privileges, block the attack. Fix the misconfigurations, fix the attack. How do we check for these? Effective auditing of course, which is fundamentally the same tactic that attackers use to enumerate a targeted environment to find weaknesses. Find your issues before they do!
References:
https://www.pentesteracademy.com/course?id=47
https://adsecurity.org/?p=3377
https://adsecurity.org/?p=2207
https://stealthbits.com/blog/what-is-dcsync-an-introduction/
