Kerberoasting Explained: How It Works in an Authorized Lab

Kerberoasting is one of those techniques that, the first time you see it work, feels almost too easy. No exploit, no memory corruption, no fancy zero-day — just a standard Kerberos protocol feature being used exactly as designed, against a service account with a weak password. That simplicity is exactly why it remains one of the most common findings in Active Directory assessments years after it was first documented.

What Is Kerberoasting?

Kerberoasting is an attack technique that targets Active Directory service accounts — specifically, accounts that have a Service Principal Name (SPN) registered. Any authenticated domain user can request a Kerberos service ticket (TGS) for any SPN in the domain, and that ticket is encrypted with a hash derived from the service account’s password. Because any domain user can request this ticket, an attacker can grab it and attempt to crack it offline, without triggering repeated authentication failures against the domain controller.

If the service account has a weak or reused password, cracking the ticket reveals the plaintext password — often for an account with elevated privileges, since service accounts are frequently over-provisioned.

Why Kerberoasting Matters

Kerberoasting matters because it requires no elevated privileges to attempt — just a standard, low-privilege domain user account. It’s also quiet by design: since cracking happens offline, there’s no repeated failed login noise hitting the domain controller. Combined with the fact that service accounts often have old, rarely rotated passwords and elevated permissions, it’s consistently one of the highest-value techniques in an Active Directory attack path (see our broader Active Directory attack paths guide for how this fits into a larger chain).

How Kerberoasting Works: The Technical Breakdown

1. A domain user authenticates and receives a Ticket Granting Ticket (TGT) from the domain controller.
2. The attacker enumerates SPNs in the domain — every account with an SPN is a Kerberoasting target.
3. The attacker requests a TGS (service ticket) for a target SPN, which is standard, expected Kerberos behavior — nothing about this request itself is anomalous by default.
4. The domain controller returns the TGS, encrypted with a key derived from the service account’s password hash.
5. The attacker extracts the encrypted portion of the ticket and takes it offline.
6. The attacker attempts to crack the hash using a password-cracking tool, comparing candidate passwords from a wordlist or brute-force pattern against the ticket’s encryption.
7. If successful, the attacker now has the service account’s plaintext password, which can be used for further lateral movement or privilege escalation.

Step-by-Step Methodology for a Lab Kerberoasting Exercise

1. Set up a lab Active Directory domain with at least one service account that has an SPN registered and a deliberately weak password (for practice purposes).
2. Authenticate as a standard, low-privilege domain user on a lab machine.
3. Enumerate SPN accounts using a tool like Impacket’s GetUserSPNs.py:

GetUserSPNs.py corp.local/labuser:labpassword -dc-ip 10.0.0.10 -request

Purpose of this command: it authenticates to the domain as labuser, queries Active Directory for all accounts with an SPN set, and requests a TGS for each one — the -request flag pulls back the actual crackable ticket data for every discovered service account, all in a single step.

4. Save the output ticket hashes to a file for offline cracking.
5. Crack the hashes using hashcat:

hashcat -m 13100 kerberoast_hashes.txt rockyou.txt

Purpose of this command: -m 13100 tells hashcat to use the Kerberos 5 TGS-REP etype 23 hash mode, matching the format Kerberoasting tickets are typically extracted in, and it attempts to crack the hash file against the supplied wordlist (rockyou.txt is a commonly used lab wordlist). For more on hashcat’s modes and options, see our hashcat guide.

6. Validate the recovered password by authenticating as the service account in your lab.
7. Document the finding, including the account’s actual privileges, since that context is what determines real-world severity.

Practical Example: Using Rubeus (Windows-Based Alternative)

On a Windows-based lab operator host, Rubeus is a common alternative to Impacket for Kerberoasting:

Rubeus.exe kerberoast /outfile:hashes.txt

Purpose of this command: Rubeus automatically enumerates SPN accounts in the current domain context and requests TGS tickets for all of them, writing the crackable hash output to a file — functionally similar to GetUserSPNs.py, but run from a compromised Windows host rather than an external Linux attack box.

Useful Tools and Technologies

Common Mistakes and Troubleshooting Tips

• Targeting every SPN indiscriminately. In a real engagement, requesting tickets for hundreds of accounts at once is noisy and unnecessary — prioritize accounts likely to have real privilege (checked via BloodHound).
• Weak wordlists producing no cracks. rockyou.txt is a fine lab starting point, but real assessments often need custom wordlists based on company naming conventions, or rule-based mutations in hashcat.
• Confusing hash modes. Kerberoasting hashes typically use etype 23 (RC4) or, in more modern environments, AES-based tickets, which require different hashcat modes (13100 vs 19600/19700) — using the wrong mode produces silent failures.
• Ignoring account lockout policy. Even though Kerberoasting doesn’t cause failed authentication in the way password spraying does, always double check RoE for any live-authentication steps involved in validation.
• Not checking if pre-authentication is required. If it’s disabled, the account is actually vulnerable to AS-REP Roasting instead, a related but distinct technique with a different request flow.

Security Risks and Defensive Recommendations

• Use long, random, unique passwords for service accounts. This is the single most effective mitigation — a sufficiently long, random password makes offline cracking computationally infeasible.
• Use Group Managed Service Accounts (gMSAs) where possible, since Windows automatically manages and rotates these passwords with high entropy.
• Monitor for abnormal TGS request volume. A single account requesting service tickets for many different SPNs in a short window is a strong indicator of Kerberoasting activity.
• Watch for RC4 encryption type usage in Kerberos ticket requests (commonly surfaced via Windows Event ID 4769) — many modern environments should predominantly use AES, so RC4 requests can indicate either legacy systems or an active roasting attempt.
• Limit and audit SPN assignments. Fewer, tightly scoped service accounts with SPNs reduce the overall attack surface.
• Reduce service account privileges to only what’s strictly necessary — even if an account is roasted, limiting its blast radius matters.

Frequently Asked Questions

Q1: Does Kerberoasting require administrative privileges? No — any authenticated, standard domain user can request service tickets, which is exactly what makes this technique so widely applicable and dangerous.

Q2: Is Kerberoasting detectable? Yes, with proper logging — Event ID 4769 combined with abnormal request volume or RC4 encryption usage is a common detection pattern, though it requires deliberate monitoring configuration.

Q3: What’s the difference between Kerberoasting and AS-REP Roasting? Kerberoasting targets SPN-registered service accounts via TGS requests; AS-REP Roasting targets accounts with Kerberos pre-authentication disabled, using a different request flow (AS-REQ/AS-REP) that doesn’t require any valid credentials at all.

Q4: Why do service accounts get targeted so often? They’re frequently created once, given broad privileges for convenience, and then never revisited — meaning old, weak, or reused passwords are common.

Q5: Can gMSAs be Kerberoasted? Technically their tickets can still be requested, but because gMSA passwords are long, random, and automatically rotated, cracking them offline is computationally infeasible in practice.

Q6: What wordlists work best for cracking Kerberoast hashes? It depends on the target organization — generic wordlists like rockyou.txt work for weak/common passwords, but custom wordlists built from company naming patterns and hashcat rule-based mutations are far more effective in real engagements.

Q7: Is Kerberoasting still relevant in modern, well-patched environments? Yes — it’s a protocol-level technique, not a software vulnerability, so patching doesn’t mitigate it. Only strong password practices and gMSA adoption meaningfully reduce the risk.

Conclusion

Kerberoasting endures as one of the most reliable Active Directory attack techniques precisely because it exploits normal, expected protocol behavior rather than a bug. Understanding how it works — from SPN enumeration through offline cracking — gives you a technique that’s both easy to practice safely in a lab and consistently relevant in real assessments. The defensive fix is refreshingly simple in concept (strong, unique service account passwords and gMSA adoption) even if rolling it out across a legacy environment takes real effort.

References: MITRE ATT&CK T1558.003 (attack.mitre.org), Impacket documentation, Microsoft Kerberos protocol documentation, hashcat documentation.