Kerberoasting

What It Is and Why Service Accounts Are the Target

Kerberoasting is a credential access technique where an attacker requests Kerberos Ticket Granting Service (TGS) tickets for service accounts, extracts the encrypted portion, and cracks it offline to recover the plaintext password.
MITRE ATT&CK maps this to T1558.003 (Steal or Forge Kerberos Tickets: Kerberoasting).
The attack exploits a fundamental design property of Kerberos: the TGS is encrypted with the service account NTLM hash so the service account can decrypt it. But the requesting user also obtains a copy of the ticket, including the encrypted portion, as part of the standard Kerberos authentication flow.
No special privileges are required — any domain user can request a TGS for any service account that has a Service Principal Name (SPN) registered.
Service accounts are the target because they often have elevated privileges (local admin on servers, domain admin in some cases) and their passwords are frequently weak, shared, or never rotated — making this a common insider threat vector.

How the Attack Works — Step by Step

Step 1: Enumerate Service Accounts with SPNs

The attacker queries Active Directory for user accounts that have Service Principal Names (SPNs) registered. Any user account with an SPN is a service account and is a Kerberoastable target.

Tools: setspn -Q */* (native Windows), PowerView Get-NetUser -SPN, impacket-GetNPUsers (also used in Golden Ticket attacks)

# Using PowerView to enumerate Kerberoastable accounts
Get-NetUser -SPN | select samaccountname, serviceprincipalname

Step 2: Request TGS Tickets

The attacker requests TGS tickets for the identified service accounts. Windows will issue a TGS ticket encrypted with the service account’s NTLM hash.

Tools: Rubeus kerberoast, impacket-GetUserSPNs

Step 3: Extract the Hash and Crack

The TGS ticket includes the session key encrypted with the service account’s password hash. The attacker extracts this encrypted portion and saves it in a format crackable by Hashcat or John the Ripper.

Cracking:

# Crack the extracted Kerberos TGS hash with Hashcat
hashcat -m 13100 -a 0 kerberoast_hashes.txt rockyou.txt

# -m 13100 = Kerberos 5 TGS-REP etype 23 (RC4)
# -m 19600 = Kerberos 5 TGS-REP etype 17/18 (AES-128/AES-256)

Step 4: Use the Recovered Password

Once cracked, the attacker has the service account’s plaintext password. Combined with the account’s domain privileges, lateral movement and privilege escalation follow — often leading to C2 and beaconing activity.

Detection — The Key Signals

Detection 1 — Anomalous TGS Request Volume (Event ID 4769)

Event ID 4769 (Kerberos Service Ticket Operation) is generated when a TGS ticket is requested. Normal users request TGS tickets for the services they use (file server, email, web proxy). Kerberoasting generates a burst of TGS requests from a single user to many different service accounts.

What to look for: A single user account requesting TGS tickets for multiple SPNs in a short window, especially for accounts they would not normally interact with.

SPL query — detect Kerberoasting by TGS request volume:

index=windows sourcetype="WinEventLog:Security" EventCode=4769
| search ServiceName!="krbtgt/*" AND ServiceName!="*$" (exclude machine accounts)
| stats dc(ServiceName) as UniqueServices, count as TotalRequests by ClientAddress, AccountName, TargetUserName
| where UniqueServices > 10 OR TotalRequests > 20
| eval alert = "HIGH — possible Kerberoasting: " . AccountName . " requested " . UniqueServices . " TGS tickets for different service accounts from " . ClientAddress
| sort - UniqueServices
| table _time, ClientAddress, AccountName, UniqueServices, TotalRequests, alert

Detection 2 — RC4 vs AES Encryption Type

Kerberoastable tickets can be encrypted with RC4 (etype 0x17) or AES (etype 0x12 or 0x11). RC4 hashes are significantly easier to crack:

RC4-hmac (etype 23): ~200 billion hashes/second on consumer GPU — weak passwords crack in minutes
AES-128 (etype 17): ~50 million hashes/second — 4000x slower, effectively uncrackable with common wordlists
AES-256 (etype 18): ~10 million hashes/second — even slower

What to look for: If your environment has mostly AES-encrypted service accounts and you see a user requesting RC4-encrypted TGS tickets, this is anomalous.

SPL query — detect RC4 TGS requests in an AES-dominant environment:

index=windows sourcetype="WinEventLog:Security" EventCode=4769
| search TicketEncryptionType="0x17" (RC4)
| stats values(ServiceName) as RC4Services, count as RC4Count by AccountName, ClientAddress
| where RC4Count > 5
| eval alert = "SUSPICIOUS — user " . AccountName . " requested " . RC4Count . " RC4-encrypted TGS tickets"

Detection 3 — Unusual Time of Day

Kerberoasting is commonly performed outside normal business hours. A user who normally authenticates during 9 AM - 5 PM requesting dozens of TGS tickets at 2 AM is anomalous.

What to look for: TGS requests from an account during hours the account is not typically active.

Detection 4 — Inconsistent Target Service Accounts

A marketing department user requesting TGS tickets for SQL Server service accounts (MSSQLSvc/sql01.corp.local), Exchange servers (exchangeMTA/corp.local), and domain controller services (CIFS/dc01.corp.local) is anomalous — a marketing user has no reason to authenticate to these services.

Attack Variant: Kerberoasting with RC4 Downgrade

If your environment supports AES-encrypted service accounts, the attacker may try to downgrade to RC4:

Attacker registers their own SPN on a target service account using RC4 encryption
Requests a TGS ticket for that SPN
The DC issues the ticket encrypted with RC4 (because the SPN was registered with RC4 support)
Attacker cracks the RC4 hash

Detection: Unusual SPN modifications (Event ID 5136 on a service attribute) followed by TGS requests using RC4 encryption.

Response — What to Do When Kerberoasting Is Detected

Action	Detail	Priority
Investigate the source account	Check what else the account has done — logons, resource access, lateral movement	Immediate
Check if any hashes were cracked	Review password changes, suspicious logons, or lateral movement from the source IP	Immediate
Rotate service account passwords	If a service account was targeted, rotate its password. Use a complex 30+ character password.	High
Check for other affected accounts	Kerberoasting often targets multiple accounts in one session	High
Implement detection rules	Add SIEM alerts for anomalous TGS request patterns	Medium
Audit service account passwords	Check password complexity and age for all Kerberoastable accounts	Medium

Prevention

Control	What It Prevents	Implementation
Group Managed Service Accounts (gMSAs)	Prevents Kerberoasting entirely — passwords are 128-bit random, rotated automatically, and never known to any user	Migrate service accounts to gMSAs where the service supports it
Managed Service Accounts (MSAs)	Same as gMSAs but for single servers	Use for services running on a single server
Strong service account passwords	Makes cracking computationally infeasible	Use 30+ character random passwords. Rotate every 90 days.
AES encryption only (disable RC4)	Makes cracking 4000x slower	Enforce AES-only for Kerberos. Disable RC4 in Kerberos policy.
Monitor TGS request patterns	Detects Kerberoasting in progress	SIEM rules for anomalous TGS volume per user — critical across on-prem and cloud hybrid environments
Least-privilege for service accounts	Limits blast radius	Service accounts should not be Domain Admins. Use constrained delegation.
Protected Users group	Prevents NTLM and RC4 Kerberos for highly privileged accounts	Add sensitive accounts to the Protected Users security group

Active Directory Basics — covers the active directory basics concepts
Pass-the-Hash — detection and response for T1550.002 techniques
Credential Theft Incident Response — detection and response for T1558.001, T1003.001, T1134 techniques
Mimikatz — detection and response for T1003 techniques