The kerberos protocol is the preferred authentication protocol for 100s of thousands of enterprise Active Directory environments around the world. The protocol marked the transition from the transaction of NTLM hashes over the wire to an intricate system of tickets and services. However, like any system, it has its flaws, particularly in the service ticket received by the authenticating user.
Kerberoasting is a type of password attack in which an attacker uses their TGT to acquire a service ticket from the TGS based on the provided SPN and then crack the service ticket to obtain the password of the SPNs associated service account.
The attack process is the following:
- Initial access: an attacker gains initial access to a network under the context of a domain user
- Reconnaissance: the attacker enumerates the domain through various tools such as PowerView, Bloodhound, possible anonymous LDAP bind, etc.
- Identification: the attacker identifies a human-managed service account running a service like an SQL database, FTP server, Web server, .etc
- Acquisition: using the TGT of the currently logged in domain user, the attacker requests a service ticket from the identified service through its SPN (Service Principal Name)
- Cracking: going offline, the attacker formats the acquired service ticket into a crackable format and uses tools such as Hashcat or John the ripper to crack the service account's password
Let's take a deeper look into how one completes each stage and eventually executes a successful attack.
Initial Access
Before this attack is even possible one must be under the privileged context of a domain user. It does not necessarily matter the privilege level of the domain user just that the user is of the domain. This is important because we need to request service tickets from the TGS using the SPNs of service accounts we discover and this is not possible if we are not at least within the context of a domain user account.
Reconnaissance
As the name suggests, we start to enumerate the domain specifically for the available SPNs to acquire potential targets for our attack. This is done through tools such as impacket GetUserSPNs.py, PowerView, and Rubeus.
# Rubeus
.\Rubeus.exe kerberoast /stats
# PowerView
Import-Module .\PowerView.ps1
Get-DomainUser * -spn | select samaccountname
# Impacket GetUserSPNs.py
GetUserSPNs.py -dc-ip <DC_IP> <DOMAIN_NAME>/<USER>
How to find all SPNs within a domain with different tools
Each of these commands will provide a list of possible SPNs that one could try to conduct a kerberoasting attack on. Additionally, an attacker could try to filter SPNs with associated service accounts to only accounts that have the admincount=1 attribute value, only returning service account SPNs with membership to highly-privileged groups.
.\Rubeus.exe kerberoast /ldapfilter:'admincount=1' /nowrap
Filters only SPNs that have the admincount=1 attribute value
NOTE: it is possible for an account to have the admincount attribute set to 1 even if the account has been removed from a privileged group and is no longer privileged.
Once a rough list of interesting SPNs has been created, it is time to move on to the next stage.
Identification
We will use the rough list from the previous stage to identify actual worthy targets within our attack. Like in conventional military operations, there are certain objectives that, under further analysis, are deemed much more valuable than others. In this case, the list of SPNs we have collected so far can range from random web server service accounts with nearly no privileges to a very highly privileged FTP server service account that has a direct path to domain admin. The difference between any two accounts can be found out through a series of LDAP queries. However, it is not the obvious differences between them that we judge but their length to a successful exploitation path to domain admin.
Targeting factors
There are many other factors that could affect which specific accounts we choose to target.
Managed Service Accounts: A Managed Service Account is a special type of account in Active Directory that can be used to run services on a computer. More importantly, the account generates a long, complex password every 30 days by default, meaning that it is basically impossible to kerberoast such accounts and, as such, should be ignored when targeting.
Potential for ACE abuse: Certain accounts may be misconfigured to have privileges over other accounts or objects. For instance, if we identify an account that has GenericAll, GenericWrite, WriteDacl, or WriteOwner rights over a GPO (Group Policy Object), we should target this account as it could potentially be useful for lateral movement or even privilege escalation on the network if the GPO affects a privileged group of computers. This same logic extends to accounts that our target account may have privilege over through GenericWrite, GenericAll, etc.
You have WriteSPN privileges over the account: If you have already compromised one account through other means, it would be a good idea to check if your account has WriteSPN privileges over any other account. If so, it would be possible to write an arbitrary SPN to the affected account and potentially compromise it through kerberoasting. If one is to choose this targeting factor, it would be good to maintain proper OPSEC and delete the written SPN of the target account to ensure that defenders don't see a random SPN written on an account that doesn't run a service.
Based on these targeting factors, you should have a complete list of service accounts that are deemed high value targets for your specific environment/circumstances.
Acquisition
Now that we have our definitive list of SPNs that we will target, we can move on to the acquisition of service tickets. A service ticket is used in kerberos to give a securable object (User and Computer) access to a specific resource. The service ticket of a specific service account will be encrypted with the service account’s long-term key. As a result, it is possible for an attacker, like us in this case, to use tools like Hashcat or John the Ripper to crack the password and compromise the account.
To acquire a service ticket, we can use tools like Rubeus (Windows) or GetUserSPNs.py again to request service tickets from our previously created list.
# Linux
GetUserSPNs.py -dc-ip <DC_IP> <DOMAIN_NAME>/<USER> -request-user <SPN_USER>
# Windows
.\Rubeus.exe kerberoast /user:<SPN_USER> /nowrap
Requests a service ticket for a specific service
After requesting the service ticket, the tools will output a hash that can be cracked. It is best to put the hash in a text file for the cracking step.
Cracking
Finally, we can use the hash file to crack the password of the target account.
hashcat -a 0 -m 13100 <HASH_FILE> <WORDLIST>
john --wordlist=<WORDLIST> <HASH_FILE>
Commands used to crack the hash
If the command is successful, we should have the password of the target service account. We can use this password for lateral movement through the network or even privilege escalation if the compromised account is of high privilege.
NOTE: the cracking process will take much longer if the acquired service ticket hash is AES encrypted because of the increased computational load when cracking AES encrypted tickets. As an attacker, you typically want the ticket to be RC4 encrypted as it is much less computationally intensive to crack.
Defensive Considerations
Enable AES encryption for service tickets.
As mentioned before, AES encryption can make the cracking process much more tedious for the attacker because of the encryption scheme's higher amount of permutations on the original input, causing the cracking process to take longer than a less intensive RC4 cipher. To make AES encryption the only encryption scheme available for clients, one should set service accounts' msDS-SupportedEncryptionTypes attribute to 24 (0x18) to allow for only AES128/AES256 encryption on service tickets. This will block any attempt by Rubeus or GetUserSPNs.py to downgrade service tickets to RC4 and will make any such requests extremely anomalous in your environment.
NOTE: As of 2026, the KDC now defaults a blank msDS-SupportedEncryptionTypes to AES-only. The only exposure left is when RC4 is accidentally left as an explicitly configured option or the service account is missing AES keys entirely.
Strong passwords on non-managed service accounts
Any non-managed service account should have a long and complex password to kill any kerberoasting attempt.
Utilize MSAs and gMSAs
Try using Managed Service Accounts (MSA) or Group Managed Service Accounts (gMSA) which use complex passwords and update on a set interval (every 30 days by default)
Monitor service ticket requests
A high volume of service ticket requests from a single account is a high level indicator of kerberoasting. Specifically, monitoring Event ID 4769 across a wide range of services in conjunction with all of them being RC4 (0x17) service tickets for service accounts that support AES should immediately ring alarm bells. The most popular hacking tools for kerberoasting automatically try to downgrade all service ticket requests to RC4 and with such a high volume of requests it is very likely that a threat actor is already in your network. Thus, isolate the affected host immediately and initiate incident response protocol.
Overall, kerberoasting is a powerful technique attackers employ to compromise weak accounts, but it can be mitigated through a mix of proactive monitoring and proper configuration of service accounts across an AD environment.
NOTE: The commands and techniques shown in this blog post should be used in only authorized lab environments/educational contexts. You are responsible for any damages or legal actions taken against you for executing any of the commands shown without proper authorization.