What Is Kerberoasting? How Attackers Steal Active Directory Credentials
Kerberoasting is a credential theft technique where any authenticated domain user, even one with zero special privileges, requests a service ticket from Active Directory and cracks it offline for a password, with no failed login attempt and no account lockout ever triggered.
That’s the detail that catches most IT teams off guard. This attack doesn’t need admin rights, a phishing click, or a single visible failure. It only needs one valid, ordinary login.
What Is Kerberoasting?
Kerberoasting exploits how Kerberos, the authentication protocol behind Active Directory, issues service tickets. Any authenticated user can request a ticket for any service account tied to a Service Principal Name, and that ticket comes back encrypted with the service account’s own password hash.
The attacker doesn’t need to break into anything to get that ticket. Requesting it is a completely normal, expected part of how Kerberos works. The attack happens afterward, offline, away from any system that could notice or block it.
Why does any low-privilege domain user get to start this? Because Kerberos was designed around a reasonable assumption: requesting a service ticket is routine, everyday behavior, not something worth restricting. That design choice, made decades ago for usability, is exactly what makes Kerberoasting possible today.
What Is Enumeration, and How Does It Lead to Kerberoasting?
Enumeration means systematically querying a system, in this case Active Directory, to extract specific, useful detail: usernames, group memberships, and critically, which accounts carry a Service Principal Name.
Before an attacker can Kerberoast anything, they need to know which accounts are worth targeting. Enumeration answers that question directly. Tools built for this purpose query Active Directory’s own directory service, listing every account with an SPN attached, since SPN accounts are almost always service accounts, and service accounts frequently carry weaker, older, less-monitored passwords than human user accounts do.
This is the quiet setup phase most victims never notice. Enumeration queries look identical to hundreds of legitimate administrative lookups happening across a normal domain every day.
The Attack Chain: From SPN Request to Cracked Password Offline
Kerberoasting Attack Chain
| Stage | What Happens |
| Enumeration | Attacker identifies accounts carrying a Service Principal Name |
| Ticket request | Attacker requests a service ticket for a targeted SPN account |
| Ticket issued | Domain controller returns a ticket encrypted with the account’s password hash |
| Offline cracking | Attacker cracks the hash away from any monitored system |
| Credential use | Cracked password grants direct access as that service account |
Tools like Rubeus and Impacket automate this entire sequence, requesting tickets for every SPN account discovered during enumeration in a single pass. Neither tool needs to touch the domain controller again once the tickets are collected. Everything from that point runs entirely offline, on hardware the attacker fully controls.
Why RC4 Encryption Makes This So Much Easier for Attackers
Here’s the specific detail that separates a genuinely dangerous Kerberoasting attempt from a slow, mostly futile one. RC4 encryption, still the default fallback on many older Active Directory configurations, is dramatically weaker and faster to crack than AES.
A password cracking rig can attempt billions of RC4 guesses per second against a stolen ticket. The same hardware working against an AES-encrypted ticket runs orders of magnitude slower. This single difference decides whether an eight-character service account password falls in minutes or remains practically uncrackable within any realistic timeframe.
Most environments never deliberately chose RC4. It survived for decades purely as a compatibility fallback, quietly supporting older devices, legacy applications, and third-party appliances that never got upgraded to support anything stronger. Nobody set out to weaken their domain. RC4 just never got removed, because removing it risked breaking something nobody had fully mapped.
What Is Lateral Movement, and How Does Kerberoasting Enable It?
Lateral movement means using one compromised credential or system to reach additional systems across a network, expanding an attacker’s foothold step by step rather than stopping at the first point of entry.
A cracked service account password rarely ends the attack. Service accounts frequently carry access to databases, file shares, or applications far beyond what any single compromised user account would normally reach. That expanded access is precisely what turns one successful Kerberoasting attempt into a genuine, spreading compromise across systems the original low-privilege login could never have touched directly.
Detecting Kerberoasting: Event ID 4769 and Abnormal Ticket Requests
Event ID 4769 logs every Kerberos service ticket request on a domain controller, the specific event genuine detection strategy is built around.
A single 4769 event means nothing on its own; ticket requests happen constantly across any normal domain. What matters is the pattern: one account requesting tickets for an unusually large number of SPN accounts in a short window, or requesting tickets using RC4 encryption specifically when AES is available and expected. Both patterns diverge sharply from normal, single-service login behavior and are exactly what a properly tuned SIEM rule should flag.
Defense That Actually Works: gMSA, AES-Only, and Password Length
Group Managed Service Accounts, gMSA, remove the weakest link in this entire attack chain: a human-chosen password. gMSA-managed accounts get long, randomly generated passwords that rotate automatically, making offline cracking practically pointless regardless of encryption type.
Enforcing AES-only Kerberos encryption removes RC4’s speed advantage entirely, forcing any offline cracking attempt back down to a timeframe measured in years rather than minutes.
Where gMSA genuinely isn’t feasible, for legacy applications that require a standard password, length matters more than complexity. A genuinely long, random passphrase resists offline cracking meaningfully better than a shorter password loaded with forced special characters ever will.
Does Microsoft’s AES-Only Rollout Solve This?
Here’s an honest answer worth understanding directly, since it’s genuinely current and easy to get wrong in either direction. Microsoft began a staged rollout tied to CVE-2026-20833, moving Windows domain controllers toward AES-only Kerberos by default. January 2026 introduced audit-only logging. April 2026 shifted the default for accounts with no explicit encryption setting to AES-SHA1. July 2026 removes the rollback option entirely, making AES-SHA1 the sole supported behavior for those accounts.
This closes a real, significant piece of the problem. Once fully enforced, any account without an explicit RC4 exception configured stops offering attackers that fast, cheap cracking path entirely. That’s a genuine, structural improvement Microsoft has been slow to make for two decades.
But it doesn’t solve Kerberoasting completely, and this distinction matters. The rollout only forces AES defaults for accounts where encryption settings were never explicitly configured. Any account with msDS-SupportedEncryptionTypes explicitly set to allow RC4, common for legacy devices and older applications nobody’s touched in years, keeps using RC4 regardless of Microsoft’s new default. And even with AES enforced everywhere, a weak, human-chosen service account password remains crackable, just considerably slower than it was under RC4. AES-only closes the fast lane. It doesn’t close the road. Businesses still need gMSA adoption and genuine password hygiene on top of whatever Microsoft enforces by default, not instead of it.
What Is Reconnaissance, and How Does It Fit Before This Attack Begins?
Reconnaissance is the broader information-gathering phase that happens before enumeration, researching a target organization’s structure, technology, and employees, often entirely from outside the network, before any login credential is ever used.
Kerberoasting itself sits downstream of reconnaissance, not inside it. An attacker typically needs a foothold, one valid domain login, before enumeration and Kerberoasting become possible at all. Reconnaissance is how attackers commonly identify which employee to target for that initial credential in the first place, making it the quiet first link in a chain that ends with a cracked service account password.
Conclusion
Kerberoasting has stayed effective for years precisely because it never trips an alarm most teams are actually watching. Check whether your own domain still allows RC4 by default, and whether your service accounts are still running on passwords a person chose years ago. Cyber Security Solutions Ltd can help you find out before someone else does.
FAQs
Kerberoasting is a credential theft technique where an authenticated domain user requests a Kerberos service ticket for a Service Principal Name account, then cracks that ticket’s encrypted password hash offline, with no lockout or failed login triggered.
No. Any authenticated, low-privilege domain user can request a service ticket for any SPN account. Requesting the ticket is standard, expected Kerberos behavior, not a privileged action requiring elevated access.
RC4-encrypted tickets crack far faster than AES-encrypted ones, often billions of attempts per second versus a small fraction of that against AES. RC4 remains a common legacy fallback across many Active Directory environments.
Monitor Event ID 4769 for abnormal patterns: one account requesting tickets for unusually many SPN accounts quickly, or requesting RC4 encryption specifically when AES is available, both diverging sharply from normal login behavior.
Partially. It removes RC4’s speed advantage for accounts with no explicit encryption override, a genuine improvement. But explicitly configured RC4 exceptions and weak service account passwords remain exploitable even under full AES enforcement.
Group Managed Service Accounts, gMSA, remove human-chosen passwords entirely through automatic rotation. Where gMSA isn’t feasible, enforce AES-only encryption and require genuinely long, random passwords on every service account.
