Kerberoasting explained from the Kerberos protocol up

The click that unlocked 140 hospitals

In February 2024, a contractor working for Ascension, one of the largest hospital systems in the United States, clicked a malicious link that surfaced in a Bing search inside Microsoft Edge. That single click put malware on one laptop. Three months later, ransomware had spread across roughly 140 hospitals, ambulances were being diverted, nurses were charting on paper, and the personal and medical records of 5.6 million patients had been exposed, according to the HIPAA Journal. The step that turned one compromised laptop into a domain-wide catastrophe has a strange name: Kerberoasting. It is not a software bug in the usual sense. Nobody forgot to patch anything. Kerberoasting abuses the Kerberos authentication protocol working exactly as designed, and understanding why it works means starting with how Kerberos itself is supposed to keep you safe.

The guard dog of Hades

Kerberos is named after Cerberus, the three-headed dog of Greek myth that guarded the entrance to the underworld. The name is a joke with a point: the protocol involves three parties, and like the dog, it is supposed to let the right people through and tear everyone else apart. The protocol was built at MIT in the 1980s as part of Project Athena, the same effort that gave us the X Window System. Its modern version, Kerberos 5, is specified in RFC 4120, published by the IETF in 2005. Microsoft adopted it as the default authentication mechanism for Active Directory when that shipped in 1999, and it has been the backbone of corporate logins ever since. When you sign into a Windows work laptop and then reach a file share, a database, and your email without typing your password again, that seamless experience is Kerberos doing its job. The problem Kerberos solves is genuinely hard. In a network with thousands of users and hundreds of services, how do you prove who you are to each service without sending your password across the wire, and without every service needing its own copy of every password? Kerberos answers this with a trusted middleman called the Key Distribution Center, or KDC. In Active Directory, the domain controller plays this role. The KDC has two logical halves: an Authentication Server that verifies your identity once, and a Ticket Granting Server that hands out short-lived permission slips, called tickets, for individual services. Everyone shares one secret with the KDC and no one else, and the KDC vouches for everyone to everyone.

The ticket dance

The elegance of Kerberos is that your password essentially never travels anywhere. Instead, it is used as an encryption key. The exchange happens in three acts. First, when you log in, your machine sends an authentication request to the KDC. The KDC replies with a Ticket Granting Ticket, or TGT, a master credential encrypted so that only the KDC can later read it. Crucially, part of the reply is encrypted with a key derived from your own password. If you typed the right password, your machine can decrypt it; if you did not, you get gibberish. This is how you prove who you are without transmitting the secret itself. Second, when you want to reach a specific service, say a SQL database, your machine presents that TGT back to the Ticket Granting Server and asks for a ticket to that one service. The KDC does not check whether you are allowed to use the database. That is the application's job. It simply confirms your TGT is valid and issues a service ticket. Third, your machine presents the service ticket to the database, which trusts it because it is encrypted with a key only the database and the KDC share. Access granted.

The detail that matters for everything that follows is in that second step. Every service in the domain is identified by a Service Principal Name, or SPN, a string like MSSQLSvc/db01.corp.local:1433. And the service ticket the KDC hands out is encrypted using the long-term key of the account that runs that service. That key is derived directly from the service account's password.

A door left open by design

Here is the design decision that opened the door. When you ask the KDC for a service ticket, it does not ask why. Any authenticated user, the lowest-privileged intern with a valid TGT, can request a service ticket for any SPN in the entire domain. The KDC issues it without checking whether you have any business talking to that service, as Sean Metcalf of TrustedSec documented in his foundational write-up on the attack. Ordinarily that would be harmless. The ticket is encrypted, and you cannot read the parts meant for the service. But you now hold something valuable: a chunk of ciphertext that was encrypted with a key derived from the service account's password. You can take that ciphertext home and try to guess the password offline, at your leisure, checking each guess by seeing whether it decrypts the ticket cleanly. The cryptographer Matthew Green put the design flaw bluntly in a September 2025 essay: "we should not build systems where any random attacker who compromises a single employee laptop can ask for a message encrypted under a critical password." That is Kerberoasting in one sentence. You are not attacking the service. You are not even touching it. You are asking the trusted middleman to hand you an encrypted sample of a password, and then attacking that sample where no one can see you. This is where a common misconception needs correcting. Kerberoasting is often described as an "escalation exploit," as though obtaining the ticket is the compromise. It is not. Requesting the ticket is trivial and always succeeds. The attack only pays off if the service account's password is weak enough to guess. A service account with a strong, random password is roasted every day and never cracks. The vulnerability lives in the password, not the protocol request. What the protocol does is guarantee the attacker an unlimited number of guesses in perfect privacy.

Why RC4 is the accelerant

Not all encrypted tickets are equally easy to crack, and this is where a 1980s cipher becomes the villain of the story. Kerberos can encrypt tickets with different algorithms, identified by numbers called encryption types, or etypes. Modern Active Directory supports AES (etypes 17 and 18). But it also still supports RC4-HMAC-MD5 (etype 23), a mode built around RC4, a stream cipher designed by Ron Rivest in 1987 that the wider security world abandoned years ago. The two modes are not close. With AES, the encryption key is derived from the password through a deliberately slow process: 4,096 iterations of a key-derivation function, salted with the account and realm names so that identical passwords produce different keys. With RC4, the key is the account's NT hash, which is nothing more than a single unsalted MD4 hash of the password. No iterations. No salt. One fast hash. The speed difference is enormous. Green benchmarked both on a single Nvidia RTX 5090 graphics card. Against AES tickets, the card managed about 6.8 million password guesses per second. Against RC4 tickets, the same card ran at 4.18 billion guesses per second, roughly a thousand times faster. A password that would take years to crack in AES falls in hours or minutes in RC4.

The maddening part is that the attacker gets to choose. When requesting a service ticket, the client states which encryption types it supports, and most Kerberoasting tools deliberately advertise only RC4 so the KDC obligingly downgrades to the weaker cipher. Unless an administrator has explicitly configured accounts for AES only, the domain controller hands over the easy-to-crack version. This is why US Senator Ron Wyden, in September 2025, called on the Federal Trade Commission to investigate Microsoft for what he termed "gross cybersecurity negligence," singling out RC4 support as a default that "needlessly exposes its customers to ransomware." Microsoft responded that disabling RC4 outright "would break many customer systems," and said it plans to disable it by default in Active Directory starting in the first quarter of 2026.

Cracking in the dark

The reason Kerberoasting is so beloved by attackers is not just speed. It is silence. Once the attacker has the ticket, the cracking happens entirely offline, on their own hardware, disconnected from the target network. There are no failed login attempts, no lockouts, no network traffic reaching the service, and no log entries generated by the guessing. Tools like Hashcat (which processes RC4 Kerberos tickets in its mode 13100) or John the Ripper churn through wordlists of millions of common passwords with no one watching. The defender's usual tripwires, account lockout after five bad passwords, alerts on brute-force login storms, are all blind to an attack that never tries to log in. Extracting the tickets in the first place is equally undramatic. A handful of freely available tools automate the whole thing: Impacket's GetUserSPNs, the PowerShell Invoke-Kerberoast function from PowerSploit, and Rubeus among them. None of them requires administrator rights. Any domain user account will do, which is exactly what an attacker has after phishing one employee. Which accounts are worth roasting? Not all of them. Kerberos is used by computer accounts too, but those have passwords automatically generated by the domain: long, random, and rotated roughly every 30 days. Cracking one is hopeless. The soft targets are user accounts that have been assigned an SPN so they can run a service, typically for databases, web applications, or scheduled tasks. These passwords are set by humans, often years ago, frequently reused, and rarely changed because rotating them risks breaking the service that depends on them. Worse, service accounts are commonly over-privileged, sometimes sitting in Domain Admins, so cracking one weak password can hand an attacker the keys to the entire directory.

From a research talk to the ransomware economy

Kerberoasting entered the public record at the DerbyCon security conference in 2014, when researcher Tim Medin presented a talk titled "Attacking Microsoft Kerberos: Kicking the Guard Dog of Hades" and released a Python tool to crack the tickets. It was a clever piece of research about a design quirk. It did not stay academic for long. Today Kerberoasting is catalogued by MITRE as technique T1558.003, and MITRE's own list of groups observed using it reads like a who's who of state-sponsored and criminal operations: the financially motivated FIN7, the Russian intelligence group APT29 during the SolarWinds compromise, the ransomware crew Wizard Spider behind Ryuk and Conti, and the Chinese group APT40. The technique sits in a well-worn spot in the intrusion playbook. Phish an employee, land on one machine, roast the service accounts, crack a weak one offline, and use its privileges to move laterally and deploy ransomware. That is, in outline, precisely the path attackers took through Ascension in 2024, according to reporting by The Record. Detection is possible but awkward, because the only network-visible moment is the ticket request itself. Defenders watch Windows Event ID 4769, which logs every service ticket the KDC issues, and look for two patterns: a single account requesting tickets for an unusually large number of different SPNs in a short window, and requests specifying RC4 encryption in an environment that should be using AES. Both are signals, not certainties, and both can be evaded by an attacker who roasts slowly and selectively.

What to watch

The honest lesson of Kerberoasting is that a protocol can be cryptographically sound and still fail in practice, because it quietly outsources its security to whatever password a busy administrator typed into a service account in 2016. The fix that actually works is to remove the human from that loop. Group Managed Service Accounts, and the newer delegated variants in Windows Server 2025, let the domain generate passwords hundreds of characters long, entirely random, rotated automatically, and impossible to crack no matter how many tickets an attacker roasts. The account can still be roasted; the ciphertext is simply worthless. The near-term thing to watch is whether Microsoft actually follows through on disabling RC4 by default in early 2026, more than a year after it first promised action and after a senator and a five-million-record breach forced the issue into public view. Turning off a cipher from 1987 sounds trivial. That it has taken this long, and this much pressure, says something uncomfortable about how much of the modern enterprise is quietly held together by defaults nobody wants to be the one to change. The deeper question Matthew Green raises outlives any single patch. We have built the authentication systems that guard hospitals, banks, and governments on the assumption that an attacker who gets a foothold cannot simply ask the system for encrypted copies of its most important passwords. Kerberoasting is a reminder that we built exactly such a system, shipped it to nearly every large organization on earth, and are only now, thirty years later, getting around to closing the door.

Sources

1. IETF / RFC Editor, RFC 4120: The Kerberos Network Authentication Service (V5), 2005
2. Matthew Green, A Few Thoughts on Cryptographic Engineering, Kerberoasting, 2025
3. Sean Metcalf, ADSecurity, Cracking Kerberos TGS Tickets Using Kerberoast, 2015
4. MITRE ATT&CK, Steal or Forge Kerberos Tickets: Kerberoasting (T1558.003), accessed 2026
5. CyberScoop, Wyden calls on FTC to investigate Microsoft for 'gross cybersecurity negligence', 2025
6. The Record (Recorded Future News), FTC should investigate Microsoft after Ascension ransomware attack, senator says, 2025
7. HIPAA Journal, Ascension Ransomware Attack Affects 5.6 Million Patients, 2024
8. Office of Senator Ron Wyden, Wyden Calls for FTC Investigation of Microsoft, 2025
9. Picus Security, What Is a Kerberoasting Attack? (MITRE ATT&CK T1558.003), accessed 2026
10. Ultimate Windows Security, Event ID 4769: A Kerberos service ticket was requested, accessed 2026
11. Wikipedia, Kerberos (protocol), accessed 2026
12. Trimarc Security, Detecting Kerberoasting Activity, accessed 2026