Kerberoasting Attack: How It Works and How to Stop It
Attackers exploit standard Active Directory ticket requests to steal service account credentials without triggering immediate privilege alerts.
Kerberoasting is an attack where adversaries request service tickets from Active Directory, extract the encryption keys, and crack them offline. You stop this by using managed service accounts with 128-bit AES encryption. This prevents offline cracking by making the key derivation computationally infeasible for attackers.
What is Kerberoasting?
Kerberoasting is an attack technique that targets service accounts in an Active Directory environment. An attacker requests a service ticket for a service principal name using a standard user account. The domain controller returns the ticket encrypted with the service account’s password hash. The attacker then extracts this ticket from memory and attempts to crack the password offline. This method bypasses many traditional security controls because the initial request appears as legitimate activity.
Why does Kerberoasting work?
The attack exploits the default configuration of older Active Directory environments. Many service accounts are configured to use weaker encryption types, such as RC4-HMAC, for their service tickets. RC4 is a stream cipher that is significantly faster to crack than modern block ciphers. Attackers prioritize these accounts because the computational cost to recover the password is low. The vulnerability exists because the service ticket must be decryptable by the service application, which means the encryption key is derived directly from the service account password.
How do attackers find Kerberoastable accounts?
Attackers use standard Active Directory tools to enumerate service principal names. They look for accounts that have service principal names associated with them but are not built-in system accounts. These accounts often have long, complex passwords that administrators created to satisfy complexity requirements. Long passwords are a double-edged sword in this context. While they resist online brute-force attacks, they do not protect against offline cracking if the encryption type is weak. The attacker simply collects all available tickets and filters for those encrypted with weak algorithms.
What is the difference between Kerberoasting and Golden Ticket attacks?
Kerberoasting targets specific service accounts by requesting legitimate tickets that are then cracked offline. A Golden Ticket attack involves forging a ticket-granting ticket using the KRBTGT account password hash. Kerberoasting does not require domain administrator privileges, whereas creating a Golden Ticket does. This makes Kerberoasting a common lateral movement technique for low-privilege attackers. The Golden Ticket provides broad access across the domain, while Kerberoasting grants access only to the specific service the ticket represents.
How do you detect Kerberoasting in real-time?
Detection relies on monitoring for anomalous ticket request patterns. A single user requesting tickets for multiple service accounts is a strong indicator of enumeration. You should alert on high volumes of Event ID 4769, which logs Kerberos service ticket requests. The alert should trigger when a user requests tickets for many different service principal names in a short period. This behavior differs significantly from normal user activity, where a user typically requests tickets for a few specific services. Integrating this monitoring into your SOC playbooks ensures consistent response to these anomalies.
What is the most effective mitigation strategy?
The most effective mitigation is converting standard service accounts to managed service accounts. Managed service accounts automatically rotate their passwords every 30 days. They also enforce the use of AES encryption for all service tickets. AES encryption is significantly stronger than RC4 and makes offline cracking computationally impractical. This change eliminates the weak encryption vector that Kerberoasting relies on. You do not need to change the underlying service configuration, as the managed account handles the credential management transparently.
Why are long passwords not enough?
Administrators often create very long passwords for service accounts to resist password guessing. This strategy fails against Kerberoasting because the attack is not about guessing the password online. The attacker already has the encrypted ticket and works offline. The length of the password only increases the search space for the cracking tool. If the encryption algorithm is weak, the tool can still test billions of password hashes per second. The encryption strength matters more than the password length in this specific attack scenario.
How does this relate to other attack techniques?
Kerberoasting is often a precursor to further domain compromise. Once an attacker cracks a service account password, they may use those credentials to access sensitive systems. They might then perform defense evasion by clearing logs or creating new accounts. The stolen credentials can also facilitate remote desktop abuse to access administrative consoles. Understanding this attack vector helps you prioritize monitoring for service account activity. It connects the initial access phase with the lateral movement phase of an intrusion.
| Account Type | Encryption Type | Password Rotation | Cracking Difficulty |
|---|---|---|---|
| Standard Service | RC4-HMAC | Manual | Low |
| Managed Service | AES-128/256 | Automatic | High |
| Group Managed | AES-128/256 | Automatic | High |
What is the hidden cost of poor monitoring?
The hidden cost is alert fatigue. If you monitor every Kerberos ticket request without filtering for anomalies, your security team will be overwhelmed by noise. This leads to missed detections because real attacks are buried in legitimate traffic. You must tune your alerts to focus on enumeration patterns, such as a user requesting tickets for many services. Proper tuning requires understanding normal baseline behavior. Without this, you waste resources investigating false positives while real threats go unnoticed.
How do you verify your mitigation is effective?
You verify effectiveness by attempting to Kerberoast a test account in a controlled environment. Create a standard service account with a known password and RC4 encryption. Attempt to extract and crack its ticket. If successful, your environment is vulnerable. Then, convert that account to a managed service account and repeat the test. The cracking attempt should fail or take an impractical amount of time. This validation proves that your encryption settings are correctly applied. Regular verification ensures that configuration drift does not reintroduce vulnerabilities.
Key takeaways
- Service accounts with long passwords are vulnerable to offline brute-force attacks.
- Managed service accounts automatically rotate keys and use strong encryption.
- Detecting high-volume ticket requests helps identify active extraction attempts.
Convert all service accounts to managed service accounts to eliminate weak encryption. Review your Kerberos monitoring alerts to ensure they focus on enumeration patterns rather than all ticket requests.
Frequently asked questions
Does Kerberoasting require domain admin rights?
No, Kerberoasting only requires a standard domain user account. The attacker uses their own credentials to request the service ticket, which the domain controller encrypts with the service account's hash.
Can Kerberoasting be stopped by firewalls?
No, Kerberoasting uses standard Kerberos traffic on UDP port 88. Firewalls allow this traffic because it is necessary for normal domain operations. Detection must happen at the identity or endpoint level.
Is AES encryption completely secure?
AES encryption is considered secure against current cracking capabilities. While no encryption is theoretically unbreakable, the computational cost to crack AES-128 or AES-256 is currently prohibitive for most attackers.
How often should I check for Kerberoastable accounts?
You should check for Kerberoastable accounts regularly, ideally as part of your periodic identity access reviews. Configuration changes can introduce new service accounts with weak settings that need immediate remediation.
How this guide was produced: written by the BlueTeam Insider editorial team with AI assistance, checked against the public references listed below, and reviewed when the facts change. See our editorial policy or report an error.
