It has now been over ten years since Tim Medin introduced the so-called Kerberoasting attacks. And even today, Kerberoasting remains a reliable attack technique against Microsoft Active Directory, which is often exploited by penetration testers and red teamers. With a valid domain account, the attack can be carried out in an Active Directory environment without extended privileges. Afterwards, an attempt can calmly be made to crack the passwords of service accounts offline.

While there are already a large number of articles and guides on the subject of Kerberoasting, most of them focus on extracting hashes and only touch superficially on how the collected hashes can be effectively cracked. With this article, we would like to precisely fill this gap: The focus will be on intelligent cracking strategies that can be used to crack hashes efficiently.

What is Kerberoasting?

Kerberoasting is an attack technique against Microsoft Active Directory that exploits a vulnerability in the Kerberos authentication protocol. It targets accounts that have been assigned a service principal name (SPN). This means that accounts used to run services such as SQL server, IIS, or other applications are affected. The attack is possible because every authenticated domain user is authorized to request TGS (Ticket Granting Service) tickets for any SPNs. These tickets are encrypted with the NTLM hash of the service account password. And this is precisely the point of vulnerability.

Attackers can extract these tickets and attempt to crack the password offline without any further interaction with the domain controller. Unlike other attack techniques, Kerberoasting does not trigger account locks and generates only minimal event logs. The only requirement is a valid domain account. A standard user without special rights is already sufficient.

Service accounts are of particular interest because they often come with elevated privileges and their passwords are rarely changed. Administrators frequently set passwords that follow certain known patterns and never expire – an ideal combination for successful hash cracking attacks.

Kerberoasting Attacks in Practice

Performing Kerberoasting is very easy and can be done with just a few commands:

On Windows

Rubeus has established itself as the standard tool on Windows systems. The following command can be used to identify all available SPNs and request the corresponding TGS tickets:

.\Rubeus.exe kerberoast /outfile:hashes.txt

Rubeus automatically extracts the tickets and saves them in a Hashcat-compatible format. Optionally, the output can be restricted to specific accounts using the parameter /user:serviceaccount.

On Linux

On Linux systems, Impacket is the first choice. The Python script GetUserSPNs.py enables Kerberoasting from a system that is not connected to the domain, provided that there is network access to the domain controller.

GetUserSPNs.py -request -dc-ip IP domain.local/username:password -outputfile hashes.txt

The parameter -request requests the TGS tickets, while -outputfile stores the hashes directly in the Hashcat format. Alternatively, the NTLM authentication can be used with the parameter -hashes.

The extracted hashes typically have one of the following formats (depending on encryption):

• $krb5tgs$23$*... (RC4-encrypted, Hashcat mode 13100)
• $krb5tgs$17$*... (AES128-encrypted, Hashcat mode 19600)
• $krb5tgs$18$*... (AES256, Hashcat mode 19700)

RC4 hashes are significantly faster to crack and unfortunately they are still the standard in many environments. However, even AES-encrypted hashes can be cracked if a weak password is used. With these hashes at hand, the actual work can now begin: cracking the hashes. To do this, we use the hashcat tool below.

Association Attacks – the Intelligent Hash Cracking Method

Even though it is often started directly with large word lists, a more strategic approach is recommended. As a first step and “Quick Win”, association attacks (Hashcat attack mode -a9) should be used. These often yield initial success before more time-consuming methods are even needed.

Association attacks are among the most efficient strategies for hash cracking. Instead of starting with huge generic word lists containing millions or even billions of entries, highly context-specific candidate lists are created. This method is used when there is already a guess about the password or individual components of the password that correlate with a specific hash.

This means that a word list is created containing a specific word for each hash. The order must be identical to the order in the hash list. The association attack then tests each word in the word list against exactly one hash and not against all of them. This would look as follows:

Hash1 → Word1

Hash2 → Word2

Hash3 → Word3

This means that not all words are tried for each hash, as is the case with a normal dictionary attack (Hashcat attack mode -a0).

The idea behind this is simple but effective: passwords are rarely chosen completely at random but follow recognizable patterns that are often directly related to the name of the service account or the associated service. A SQL service account named “svc_mssql” often (or at least more often than one would hope) has a password such as “MSSQL2025!”, “mssql@123”, or “MSSQL_P@ssw0rd”.

The word list should always be combined with rule sets to generate a whole series of variations from a single word, for example by changing upper and lower case letters, replacing letters with numbers and special characters (known as Leetspeak substitution), or adding character strings at the beginning and/or end of the word. We will go into more detail about rule sets later on.

For example, the following command can be used to automatically determine the account names based on the extracted hashes:

cat hashes.txt | cut -d'$' -f4 > usernames.txt

The output can then be used in an association attack to crack passwords that contain the account name:

hashcat -m 19700 hashes.txt -a 9 usernames.txt -r path/to/ruleset.txt

It is often advisable to remove special characters and numbers at the beginning and at the end of user names so that, for example, the user name “SVC_MSSQL037” turns into the character string “SVC_MSSQL”. This can be achieved with the following string:

cat hashes.txt | cut -d'$' -f4 | sed 's/^[^a-zA-Z]*//; s/[^a-zA-Z]*$//' > username-stems.txt

This output can then equally be used in an association attack:

hashcat -m19700 hashes.txt -a9 username-stems.txt -r path/to/ruleset.txt

In our practical experience, the first hashes to be cracked almost always come from association attacks, as administrators tend to choose service account passwords based on such patterns. Often, these passwords are only intended to be a “temporary“ solution during initial account set up. However, nothing is more permanent than a temporary password.

Dictionary Attacks: Effectively Utilizing the Corporate Context

If association attacks are unsuccessful or additional passwords need to be cracked, the next logical step is to use targeted dictionary attacks. These do not involve generic word lists but rather lists of context-specific password candidates tailored to the respective company.

Tools such as Targinator, elpscrk, or CUPP (Common User Passwords Profiler) help to create customized word lists based on specific keywords. The following information can be used, for example:

• Name of the company
• Address of company locations (street name, city, postal code)
• Geographical features (nearby mountains, rivers, lakes, etc.)
• Local soccer club (club name, player names, year founded, etc.)

In order to include industry-specific terms and products used by the company, the company website can be crawled to create a customized glossary. To do so, tools such as CeWL (Custom Word List Generator) or spider can be helpful.

Example using spider:

spider -url ‘https://www.oneconsult.com/’ -crawl 3 -timeout 5 -delay 10 -sort -o wordlist.txt

The resulting word list can then be used in the following dictionary attack:

hashcat -m19700 hashes.txt -a0 wordlist.txt -r path/to/ruleset.txt

However, you should not limit yourself to individual words that appear on the website. Combinations of two, three, or more words, so-called N-grams, that frequently appear on the website can also be used. For this purpose, the spider tool is also helpful:

spider -url «https://www.oneconsult.com/" -ngram 1-4 -crawl 3 -timeout 5 -delay 10 -sort -o wordlist-ngrams.txt

The -ngram parameter can be used to specify which N-grams are to be extracted.

When using N-grams in a dictionary attack, it is recommended to first use a rule set that generates candidates with different separators between individual words as well as with different upper and lower case letters. For example, rulesets of initstring could be used for this purpose:

hashcat -m19700 hashes.txt -a0 wordlist-ngrams.txt -r passphrase-rule1.rule -r passphrase-rule2.rule

Using Password Lists for Generic Dictionary Attacks

Only after context-specific word lists have been exhausted, it is time to resort to proven generic password lists based on real data leaks. These lists contain millions to billions of actual passwords and cover the most common human password patterns.

The rockyou.txt file is often used as a standard password list. However, this list originates from a data leak in 2009 and is nowadays outdated. The newer versions of this list (“RockYou2021” and “RockYou2024”) are not recommended either, as they have been inflated with artificial passwords (i.e., passwords that have not actually been used by anyone).

Instead, we recommend the password lists on HashMob. These are generated automatically on a weekly basis and are based on collected and cracked password hashes. The word lists are available in various sizes and sorted by frequency, with the most frequently observed passwords at the top.

These password lists should also always be combined with rule sets that perform systematic mutations on each individual password. Hashcat already provides several rule sets in the rules/ folder, e.g., best66.rule or dive.rule.

A more extensive collection of rule sets can be found in the GitHub repository of caeksec. When selecting the appropriate set of rules, the Google sheet by PenguinKeeper helps to compare and evaluate different rule sets (and word lists). However, it should be noted that not all rule sets are publicly available.

Example of a dictionary attack:

hashcat -m19700 hashes.txt -a0 hashmob.net_2025-11-23.small.found -r Fordyv4b.rule

The choice of password list and rule set must always be adapted to the available hardware resources and time by trying different combinations. Hopefully, this will allow one or two more passwords to be cracked.

What Defensive Measures Protect Against Kerberoasting?

Even though Kerberoasting is deeply rooted in the architecture of Active Directory and cannot be easily remedied, there are effective measures that can be taken to reduce the risk or at least make an attack considerably more difficult.

Long, Complex Passwords and Managed Service Accounts

The most effective way of defense against Kerberoasting is simple: using long and complex passwords for service accounts with SPNs that do not appear in common word lists or are based on known patterns. Passwords should be at least 20 characters long and generated completely randomly from upper and lower case letters, numbers, and special characters. This makes hash cracking impossible.

Group Managed Service Accounts (gMSAs) are even better. This solution, introduced by Microsoft, automatically generates complex, long passwords and rotates them regularly – with no administrative effort. gMSAs virtually eliminate the risk of Kerberoasting, as the passwords are too complex and too short-lived to be cracked.

AES Encryption Instead of RC4

By default, many Active Directory environments still use RC4 encryption for Kerberos tickets. This is significantly faster to be calculated than AES. AES256 encryption is considerably slower and should therefore be preferred. This does not prevent Kerberoasting entirely, but it makes hash cracking considerably more complex and time-consuming.

The preferred encryption types can be set via group policies at the domain level. In the Group Policy Management Console (gpmc.msc), the setting Network security: Configure encryption types allowed for Kerberos can be edited under Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options. There, the options AES128_HMAC_SHA1, AES256_HMAC_SHA1, and Future encryption types should be enabled and the option RC4_HMAC_MD5 should be disabled.

The switch to AES should be tested carefully, as older systems or applications may only support RC4.

Monitoring and Detection

Kerberoasting is difficult to detect because requesting TGS tickets is legitimate behavior. However, there are event IDs that should raise an alert when unusual patterns are detected:

• Event ID 4769: «A Kerberos service ticket was requested» – particularly suspicious if there are many ticket requests in a short period of time from a single account.
• Event-ID 4768: «A Kerberos authentication ticket (TGT) was requested» – may indicate an initial compromise.

Detection first requires a baseline of normal ticket request patterns per user. Based on this, anomaly detection can be implemented to raise an alert in the event of unusual patterns, for example, if an account suddenly requests dozens of TGS tickets within a few minutes. Honeypot accounts can also be helpful. These dummy service accounts with SPNs should never be legitimately requested and therefore allow any ticket request to be immediately classified as suspicious.

Conclusion: Efficient Hash Cracking Thanks to a Systematic Approach

Even more than ten years after its discovery, Kerberoasting remains a popular attack technique against Active Directory environments. The low barrier to entry (a simple domain user is sufficient) and the ability to carry out the attack largely offline make this technique particularly dangerous.

As this article shows, a methodical approach is crucial when cracking passwords – from association attacks as a “Quick Win” to context-specific word lists from company-specific terms and generic dictionary attacks with password lists from known data leaks. Such a staggered approach maximizes the success rate when cracking hashes.

It is essential for companies to understand the vulnerability of their Active Directory environment to such attacks. Oneconsult can help you with this:

• Our Active Directory Security Assessment reveals vulnerabilities such as vulnerable service accounts, outdated encryption methods, and missing hardening measures in Active Directory.
• In addition, our Password Audit shows how many of your company passwords would withstand modern cracking techniques.