What Is Kerberoasting? The Attack That Exploits Active Directory Service Accounts

Imagine a new employee with basic domain access being able to extract the database server password without triggering a single alert — using nothing but native Windows tooling. That's exactly what Kerberoasting makes possible. It's not a sophisticated zero-day: it's a feature of the Kerberos protocol itself, and any domain account can start the attack.

How Kerberos Works (in 60 Seconds)

Kerberos is the standard authentication protocol in Windows environments with Active Directory. The basic flow has three steps:

1. The user authenticates to the Key Distribution Center (KDC) and receives a Ticket Granting Ticket (TGT).
2. When the user wants to access a service, they present the TGT to the KDC and request a Ticket Granting Service (TGS) ticket.
3. The TGS ticket is returned encrypted with a key derived from the service account's password hash.

Step 3 is where Kerberoasting enters. The KDC does not validate whether the requesting user actually has permission to use the service — it simply hands over the ticket. Cracking it offline is the attacker's problem, not AD's.

What Are SPNs and Why They Matter

A Service Principal Name (SPN) is the unique identifier for a service instance in Active Directory. When you configure SQL Server, IIS, SharePoint, or any Windows service, an SPN is registered in AD tying that service to a specific account.

Any authenticated domain user can enumerate all registered SPNs — no special privilege required. And for each listed SPN, they can request a TGS ticket. The result: a hash file ready to be cracked offline with hashcat or John the Ripper.

The Attack Step by Step

1. Enumeration: the attacker lists SPNs with Get-ADUser -Filter {ServicePrincipalName -ne "$null"} or tools like Impacket.
2. Ticket requests: for each SPN, the attacker requests a TGS from the KDC. A completely legitimate operation — no alert.
3. Extraction: tickets are pulled from memory (Mimikatz, Rubeus) or captured directly from network traffic.
4. Offline cracking: hashcat runs in mode -m 13100 (RC4) or -m 19600 (AES) against wordlists and rules.
5. Lateral movement: with the service account password in hand, the attacker accesses the target server — often with elevated privileges or access to sensitive data.

What is Kerberoasting?

Kerberoasting is an attack that exploits the Kerberos protocol to extract service tickets from Active Directory and crack them offline, recovering the plaintext password of the service account — no administrative privileges required.

The name combines "Kerberos" with "roasting" — a reference to the process of heating up the hash until the password is revealed. The attack was formally documented by Tim Medin in 2014, but remains highly relevant because it targets the protocol's design, not a specific vulnerability.

RC4 vs AES: Why the Algorithm Changes Everything

Kerberos tickets can be encrypted with RC4 (NTLM) or AES-128/256. The practical difference for an attacker cracking the ticket:

• RC4: derived directly from the NTLM hash of the password, with no salt and no iteration. Modern GPUs can test billions of candidates per second. An 8-character password falls in hours.
• AES: uses PBKDF2 with a salt and 4,096 iterations. Much slower to crack — but not impossible with a weak password.

Microsoft is rolling out AES-only Kerberos defaults throughout 2026, making Kerberoasting harder. Weak passwords still fall even with AES, so the algorithm change doesn't replace a strong password policy.

Most Targeted Accounts: Which SPNs Are in Your Domain?

Any service account with an SPN is a potential target. The most common ones:

• SQL Server service accounts (MSSQL/server.domain.local)
• SharePoint, Exchange, and IIS service accounts
• Legacy application service accounts whose passwords have never been rotated

The classic problem: these accounts often have old passwords, set before modern policies existed, and never rotated because "the service goes down if you change the password."

How to Defend Against Kerberoasting

1. Use Group Managed Service Accounts (gMSA)

gMSAs are service accounts managed by AD itself, with 120-character random passwords that rotate automatically. No human ever knows the password — practically impossible to crack. If the service supports gMSA, migrate now.

2. Long Passwords for Service Accounts with SPNs

If gMSA isn't an option, use passphrases of at least 25 characters. With AES and a long passphrase, cracking becomes computationally infeasible.

3. Enable AES-Only for Service Accounts

In the account's AD properties: check "This account supports Kerberos AES 128/256 bit encryption" and uncheck RC4. This removes the fastest cracking path.

4. Monitor High-Volume TGS Requests

A user requesting TGS tickets for dozens of SPNs in seconds is a clear anomaly. In Windows Event Log, event 4769 (Kerberos Service Ticket Operation) with result code 0x0 across multiple services is a sign of active enumeration. Set up SIEM alerts for this pattern.

5. Least Privilege for Service Accounts

Service accounts should not have Domain Admin privileges or unrestricted access. Limit them to the minimum required — if an account is compromised, the blast radius needs to be contained.

Kerberoasting in the Context of a Real Attack

Kerberoasting is rarely the first step. It typically follows initial access — a successful phishing email, LLMNR poisoning that delivered domain credentials, or Pass-the-Hash that escalated lateral access. With a domain account in hand, the attacker uses Kerberoasting to reach a service account with access to sensitive data or the Domain Controller itself.

To strengthen the remote access layer while you review internal accounts, see also how to protect RDP against brute force and password attacks — another classic entry vector in Windows environments.

The attack is classified in MITRE ATT&CK as T1558.003 and appears regularly in ransomware incident reports as a privilege escalation technique before the final payload. The combination of gMSA, AES-only tickets, long passwords, and event 4769 monitoring makes Kerberoasting impractical — even if an attacker already has a foothold in the domain.