Kerberos
Last updated
Last updated
Made from my notes on tryhackme and Hackthebox Academy
The user makes an AS-REQ to the Key Distribution Centre (KDC) on the DC that includes a timestamp encrypted with the user's NTLM hash. Essentially, this is the request for a Ticket Granting Ticket (TGT). The DC checks the information and sends the TGT to the user. This TGT is signed with the KRBTGT account's password hash that is only stored on the DC. The user can now send this TGT to the DC to request a Ticket Granting Service (TGS) for the resource that the user wants to access. If the TGT checks out, the DC responds to the TGS that is encrypted with the NTLM hash of the service that the user is requesting access for. The user then presents this TGS to the service for access, which can verify the TGS since it knows its own hash and can grant the user access.
Source: TryHackMe - Persisting AD
The Kerberos authentication system is ticket-based. The central idea behind Kerberos is not to give an account password to every service you use. Instead, Kerberos keeps all tickets on your local system and presents each service only the specific ticket for that service, preventing a ticket from being used for another purpose.
The TGT - Ticket Granting Ticket is the first ticket obtained on a Kerberos system. The TGT permits the client to obtain additional Kerberos tickets or TGS.
The TGS - Ticket Granting Service is requested by users who want to use a service. These tickets allow services to verify the user's identity.
Source: HTB Academy
Any valid user gets a ticket with kerberos to access a service (SQL for instance)
Tool: GetUsersSPNS.py - Impacket
Get a hash using the tool
If we get this error [-] Kerberos SessionError: KRB_AP_ERR_SKEW(Clock skew too great) we need to coordinate our time with the server time using ntpdate
sudo apt install ntpdate
sudo ntpdate 10.10.10.100
And then you should be able to rerun and actually get the hash
Finding the proper module in hashcat hashcat --help | grep Kerberos
We need TGS which is 13100
Crack the hash with hachcat (for it to work I needed to have 4gb on my vm)
Crack the hash with john
Alternatively we can use john
We get the password
After getting a password, we could connect to an smbshare or get a shell
or
The practical use of Kerberos Delegation is to enable 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. Without delegation, we would probably use an AD service account and provide it with direct access to the database. When requests are made on the web application, the service account would be used to authenticate to the database and recover information.
However, we can allow this service account to be delegated to the SQL server service. Once a user logs into our 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 permissions for without having to provide any database privileges or permissions to the service account itself.
Source: TryHackMe
Enerumerate available delegations with a privileged user
Import-Module C:\Tools\PowerView.ps1
Get-NetUser -TrustedToAuth
Dump LSASecrets with Mimikatz
mimikatz.exe
token::elevate To dump the secrets from the registry hive, we need to impersonate the SYSTEM user.
lsadump::secrets Mimikatz interacts with the registry hive to pull the clear text credentials.
Perform the kerberos delegation attack with kekeo kekeo.exe
tgt::ask /user:svcIIS /domain:za.tryhackme.loc /password:redacted generate a TGT that can be used to generate tickets for the HTTP and WSMAN services
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.
/user:t1_trevor.jones /service:http/THMSERVER1.za.tryhackme.loc 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 THMSERVER1
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. tgs::s4u /tgt:TGT_svcIIS@ZA.TRYHACKME.LOC_krbtgt~za.tryhackme.loc@ZA.TRYHACKME.LOC.kirbi /user:t1_trevor.jones /service:wsman/THMSERVER1.za.tryhackme.loc
Import the tickets with Mimikatz
You should have a similar output
You can run klist to check that the tickets were imported
We just need to create our session in our target
Get kerbrute here
If you do not have creds yet but see kerberos in the list of ports, it is worth trying to enumerate users with a wordlist using kerbrute
./kerbrute_linux_amd64 userenum -d timelapse.htb --dc 10.10.11.152 /usr/share/wordlists/SecLists/Usernames/xato-net-10-million-usernames.txt
Note: There's a lot of other things you can do with kerberos
Reminder: We need local admin rights. To collect all tickets we need to execute Mimikatz or Rubeus as an administrator.
We need a valid Kerberos ticket to perform a Pass the Ticket (PtT). It can be:
Service Ticket (TGS - Ticket Granting Service) to allow access to a particular resource.
Ticket Granting Ticket (TGT), which we use to request service tickets to access any resource the user has privileges.
The tickets that end with $ correspond to the computer account, which needs a ticket to interact with the Active Directory. User tickets have the user's name, followed by an @ that separates the service name and the domain, for example: [randomvalue]-username@service-domain.local.kirbi.
Note: If you pick a ticket with the service krbtgt, it corresponds to the TGT of that account.
The traditional Pass the Hash (PtH) technique involves reusing an NTLM password hash that doesn't touch Kerberos. The Pass the Key or OverPass the Hash approach converts a hash/key (rc4_hmac, aes256_cts_hmac_sha1, etc.) for a domain-joined user into a full Ticket-Granting-Ticket (TGT). This technique was developed by Benjamin Delpy and Skip Duckwall in their presentation Abusing Microsoft Kerberos - Sorry you guys don't get it. Also Will Schroeder adapted their project to create the Rubeus tool.
To forge our tickets, we need to have the user's hash; we can use Mimikatz to dump all users Kerberos encryption keys using the module sekurlsa::ekeys.
Now that we have access to the AES256_HMAC and RC4_HMAC keys, we can perform the OverPass the Hash or Pass the Key attack using Mimikatz and Rubeus.
This will create a new cmd.exe window that we can use to request access to any service we want in the context of the target user.
To forge a ticket using Rubeus, we can use the module asktgt with the username, domain, and hash which can be /rc4, /aes128, /aes256, or /des. In the following example, we use the aes256 hash from the information we collect using Mimikatz sekurlsa::ekeys.
Note: Mimikatz requires administrative rights to perform the Pass the Key/OverPass the Hash attacks, while Rubeus doesn't.
Now that we have some Kerberos tickets, we can use them to move laterally within an environment.
With Rubeus we performed an OverPass the Hash attack and retrieved the ticket in base64 format. Instead, we could use the flag /ptt to submit the ticket (TGT or TGS) to the current logon session.
Another way is to import the ticket into the current session using the .kirbi file from the disk.
We can also use the base64 output from Rubeus or convert a .kirbi to base64 to perform the Pass the Ticket attack. We can use PowerShell to convert a .kirbi to base64.
Using Rubeus, we can perform a Pass the Ticket providing the base64 string instead of the file name.
Finally, we can also perform the Pass the Ticket attack using the Mimikatz module kerberos::ptt and the .kirbi file that contains the ticket we want to import.
Note: Instead of opening mimikatz.exe with cmd.exe and exiting to get the ticket into the current command prompt, we can use the Mimikatz module misc to launch a new command prompt window with the imported ticket using the misc::cmd command.
To use PowerShell Remoting with Pass the Ticket, we can use Mimikatz to import our ticket and then open a PowerShell console and connect to the target machine. Let's open a new cmd.exe and execute mimikatz.exe, then import the ticket we collected using kerberos::ptt. Once the ticket is imported into our cmd.exe session, we can launch a PowerShell command prompt from the same cmd.exe and use the command Enter-PSSession to connect to the target machine.
Rubeus has the option createnetonly, which creates a sacrificial process/logon session (Logon type 9). The process is hidden by default, but we can specify the flag /show to display the process, and the result is the equivalent of runas /netonly. This prevents the erasure of existing TGTs for the current logon session.
The above command will open a new cmd window. From that window, we can execute Rubeus to request a new TGT with the option /ptt to import the ticket into our current session and connect to the DC using PowerShell Remoting.
Source: HTB Academy
Although not common, Linux computers can connect to Active Directory to provide centralized identity management and integrate with the organization's systems, giving users the ability to have a single identity to authenticate on Linux and Windows computers.
A Linux computer connected to Active Directory commonly uses Kerberos as authentication. Suppose this is the case, and we manage to compromise a Linux machine connected to Active Directory. In that case, we could try to find Kerberos tickets to impersonate other users and gain more access to the network.
A Linux system can be configured in various ways to store Kerberos tickets.
Note: A Linux machine not connected to Active Directory could use Kerberos tickets in scripts or to authenticate to the network. It is not a requirement to be joined to the domain to use Kerberos tickets from a Linux machine.
Windows and Linux use the same process to request a Ticket Granting Ticket (TGT) and Service Ticket (TGS). However, how they store the ticket information may vary depending on the Linux distribution and implementation.
In most cases, Linux machines store Kerberos tickets as ccache files in the /tmp directory. By default, the location of the Kerberos ticket is stored in the environment variable KRB5CCNAME. This variable can identify if Kerberos tickets are being used or if the default location for storing Kerberos tickets is changed. These ccache files are protected by reading and write permissions, but a user with elevated privileges or root privileges could easily gain access to these tickets.
Another everyday use of Kerberos in Linux is with keytab files. A keytab is a file containing pairs of Kerberos principals and encrypted keys (which are derived from the Kerberos password). You can use a keytab file to authenticate to various remote systems using Kerberos without entering a password. However, when you change your password, you must recreate all your keytab files.
Keytab files commonly allow scripts to authenticate automatically using Kerberos without requiring human interaction or access to a password stored in a plain text file. For example, a script can use a keytab file to access files stored in the Windows share folder.
Note: Any computer that has a Kerberos client installed can create keytab files. Keytab files can be created on one computer and copied for use on other computers because they are not restricted to the systems on which they were initially created.
We can identify if the Linux machine is domain joined using realm, a tool used to manage system enrollment in a domain and set which domain users or groups are allowed to access the local system resources.
realm list Check If Linux Machine is Domain Joined
In case realm is not available, we can also look for other tools used to integrate Linux with Active Directory such as sssd or winbind.
ps -ef | grep -i "winbind\|sssd" PS - Check if Linux Machine is Domain Joined
As an attacker, we are always looking for credentials. On Linux domain joined machines, we want to find Kerberos tickets to gain more access. Kerberos tickets can be found in different places depending on the Linux implementation or the administrator changing default settings.
A straightforward approach is to use find to search for files whose name contains the word keytab. When an administrator commonly creates a Kerberos ticket to be used with a script, it sets the extension to .keytab. Although not mandatory, it is a way in which administrators commonly refer to a keytab file.
find / -name *keytab* -ls 2>/dev/null Search for Files with Keytab in the Name
Note: To use a keytab file, we must have read and write (rw) privileges on the file.
crontab -l Identifying Keytab Files in Cronjobs
A credential cache or ccache file holds Kerberos credentials while they remain valid and, generally, while the user's session lasts. Once a user authenticates to the domain, a ccache file is created that stores the ticket information. The path to this file is placed in the KRB5CCNAME environment variable. This variable is used by tools that support Kerberos authentication to find the Kerberos data.
env | grep -i krb5 Reviewing Environment Variables for ccache Files
ls -la /tmp Searching for ccache Files in /tmp
As attackers, we may have several uses for a keytab file. The first thing we can do is impersonate a user using kinit. To use a keytab file, we need to know which user it was created for. klist is another application used to interact with Kerberos on Linux. This application reads information from a keytab file.
klist -k -t Listing keytab File Information
Note: To keep the ticket from the current session, before importing the keytab, save a copy of the ccache file present in the enviroment variable KRB5CCNAME.
The second method we will use to abuse Kerberos on Linux is extracting the secrets from a keytab file. We were able to impersonate Carlos using the account's tickets to read a shared folder in the domain, but if we want to gain access to his account on the Linux machine, we'll need his password.
We can attempt to crack the account's password by extracting the hashes from the keytab file with KeyTabExtract
With the NTLM hash, we can perform a Pass the Hash attack. With the AES256 or AES128 hash, we can forge our tickets using Rubeus or attempt to crack the hashes to obtain the plaintext password.
Note: A keytab file can contain different types of hashes and can be merged to contain multiple credentials even from different users.
The most straightforward hash to crack is the NTLM hash. We can use tools like Hashcat or John the Ripper to crack it. However, a quick way to decrypt passwords is with online repositories such as crackstation, which contains billions of passwords.
