An attacker with a regular domain account requests a service ticket. The domain controller issues it. No vulnerability was exploited. No alarm fires. And if the service account's password is weak enough, the attacker may eventually recover it offline without ever making another authentication request.
This is Kerberoasting: an attack that exploits the gap between how Kerberos was designed to work and how service accounts are often deployed and managed.
The Kerberos Pieces Readers Actually Need
Kerberos is a network authentication protocol designed to let parties prove their identities without sending passwords over the wire. Understanding Kerberoasting requires a working mental model of a few components.
The KDC (Key Distribution Center) is a trusted server, in Windows environments it is a domain controller, that issues cryptographic tickets. The KDC contains two logical parts: an Authentication Server (AS) that handles initial login and a Ticket-Granting Server (TGS) that handles subsequent service access.
Tickets are the central concept. A ticket is a blob of data that proves to a recipient that the holder authenticated successfully. Tickets are issued by the KDC and cannot be forged by ordinary clients.
The TGT (Ticket-Granting Ticket) is issued when a user authenticates. Think of it as a session token that proves identity to the KDC. The client uses it to request access to individual services without re-entering credentials.
Service tickets are issued in response to requests for specific services. They are what the client actually presents to an application server to gain access.
Service Principal Names (SPNs) are identifiers that associate a specific service instance with a specific account. An SPN might look like HTTP/reporting.corp.example.com or MSSQLSvc/dbserver01.corp.example.com:1433. When a client wants to reach a service, it specifies the SPN and the KDC figures out which account is responsible for that service.
Service accounts are domain accounts that run services rather than belonging to human users. A SQL Server instance might run under svc-sql, a reporting tool under svc-reporting. These accounts have SPNs registered against them.
A Normal Kerberos Service-Ticket Request
When a user wants to access an application, here is what happens at the protocol level:
- The client authenticates to the domain and receives a TGT. This involves proving knowledge of the user's password using cryptography.
- The client sends a ticket-granting service request to the KDC, presenting the TGT and specifying the SPN of the service it wants to reach.
- The KDC finds the account associated with that SPN and issues a service ticket. Critically, part of this ticket is encrypted using a key derived from the service account's password. The client receives the ticket but cannot use that encrypted portion as the intended recipient. Only the service itself, which knows its own account password, can decrypt that portion.
- The client presents the service ticket to the application. The application decrypts the relevant portion, verifies it, and grants access. The important detail: the KDC is doing exactly what it is supposed to do. It issued a legitimate ticket. The client made a legitimate request. Nothing abnormal has occurred from the protocol's perspective.
The question is what happens to that ticket afterward.
How Kerberoasting Uses This Against You
An attacker who has already obtained access to a valid domain account, perhaps through phishing, password reuse, or another initial compromise, can enumerate service accounts by querying for accounts with SPNs registered. This is ordinary LDAP directory enumeration, the kind any legitimate administrator might perform.
The attacker then requests service tickets for those SPNs. Again, this is a normal Kerberos operation. Any authenticated domain user can request a service ticket for a service they are nominally allowed to reach. The KDC issues the ticket.
Now the attacker has ticket material that includes a portion encrypted with a key derived from the service account's password. They take this material offline.
Offline means: no more authentication requests. No exposure to lockout policies. No network traffic to the domain controller. The attacker uses a cracking tool to generate password guesses, derives candidate keys from each guess, and tests whether each candidate key correctly produces the expected cryptographic output from the ticket.
If the service account's password is Password123 or ServiceAcct2019, a dictionary-based approach may find it in minutes or hours. If the password is a 32-character random string, testing billions of guesses still will not find it in any practical timeframe.
Account lockout does not help here. Lockout policies protect against online attacks, where each guess requires sending a request to an authentication system that can count failures and lock accounts. Offline cracking makes no such requests.
What Is Actually Being Cracked?
This is worth slowing down on, because "cracking a ticket" sounds more dramatic than what is happening.
The attacker is not breaking the encryption, reading arbitrary data out of the ticket, or extracting a password through some direct operation. They are performing a password guessing attack against cryptographic material.
The relevant portion of the service ticket was encrypted using a key derived from the service account's password through a defined key-derivation function. The attacker's process is:
Guess a password
↓
Derive a candidate key using the same process the KDC uses
↓
Test whether the candidate key produces output consistent with the captured ticket
↓
If yes: password found. If no: try the next guess.
The encryption type matters here. Older Kerberos configurations may still issue tickets using RC4 encryption, where the key is derived directly from the account's NT hash. More modern configurations favor AES-based encryption types that involve a slower key-derivation process. Slower key derivation increases the computational cost of each guess, which matters at scale.
Neither approach makes offline cracking impossible against weak passwords. Both make weak passwords fundamentally risky, and both make strong passwords effectively safe.
The practical consequence: Kerberoasting is an attack against weak passwords protected by ticket-derived keys. It is not an attack against Kerberos itself.
A Concrete Example
Imagine a company called Meridian Analytics. They have an internal reporting application that runs under a service account named svc-reporting. The account has an SPN registered: HTTP/reports.meridian.internal. The password on this account was set three years ago by a sysadmin who followed the then-current policy: eight characters, mixed case, a number. Something like Reports1.
Cassandra, an attacker who has compromised a regular employee's domain credentials through a phishing attack, authenticates to the domain and receives a TGT. She then queries Active Directory for accounts with SPNs registered. svc-reporting appears on the list.
Cassandra sends a TGS request for HTTP/reports.meridian.internal. The domain controller issues a service ticket. From the KDC's perspective, this is unremarkable: authenticated user requested a ticket for a service she may well need to use.
Cassandra extracts the relevant encrypted material from the ticket and runs it through a password-cracking tool with a wordlist and rules. Within a few hours, the tool finds Reports1.
Now Cassandra has the credentials for svc-reporting. The question of what she can do with them depends entirely on what that account can access.
Why the Impact Can Be Serious
In a well-administered environment, svc-reporting would have only the permissions it needs to run the reporting service and access the data it requires. If Cassandra recovers that password, she can impersonate the reporting service.
But real environments are often not well-administered. Service accounts accumulate permissions over time. They get added to groups for "temporary" access that never gets revoked. In some organizations, the same service account is used across multiple services, meaning one recovered password opens multiple doors. Some service accounts have been granted Domain Admin or local administrator rights on many machines.
The attack does not guarantee privilege escalation. The outcome depends entirely on what the compromised account can reach. A service account with minimal, scoped permissions is a much less interesting target than one with broad access.
This also explains why Kerberoasting works as a lateral movement or privilege escalation technique rather than purely as an initial compromise tool. An attacker who already has a foothold, perhaps a regular user account, can use Kerberoasting to look for service accounts with weak passwords and elevated privileges, then move from a limited starting position toward more powerful access.
Detection and Investigation
Defenders have some visibility into Kerberoasting, though not complete visibility into what is happening offline.
Windows Security Event 4769 (A Kerberos service ticket was requested) is generated when the KDC issues a service ticket. A burst of 4769 events for multiple different SPNs from a single account in a short time window is worth investigating. So is an unusual account requesting tickets for services it has never accessed before, or accessing services that are not part of its normal workflow.
The encryption type in these events can also be informative. Kerberoasting tools sometimes request RC4-encrypted tickets even in environments that normally use AES, because RC4 has been more tractable for offline cracking. Observing service-ticket requests with unexpectedly downgraded encryption types can flag activity worth reviewing.
The challenge with detection is false positives. Service-ticket requests are normal. Applications request many tickets. Administrators run scripts that enumerate services. A single unusual request means very little. Detection requires a behavioral baseline: what does normal service-ticket activity look like for this account, from this machine, at this time of day?
Investigation benefits from correlating authentication telemetry with other signals. An account that suddenly begins requesting tickets for many service accounts, from a workstation that has never made such requests, shortly after a known phishing delivery, is a much clearer signal than isolated authentication events.
Defenses That Address the Root Cause
Kerberoasting is a symptom of a broader problem: service accounts with human-guessable passwords and excessive privileges. The defenses follow from that understanding.
Use long, randomly generated service-account passwords. A 64-character random password makes offline cracking economically infeasible. The password does not need to be remembered by a human; it just needs to be stored securely and used programmatically. This is the highest-impact single change.
Prefer group Managed Service Accounts (gMSAs) where supported. gMSAs are a Windows feature where the domain controller manages the service account's password automatically. The password is long, random, and rotated on a schedule without manual intervention. Services using gMSAs are largely immune to Kerberoasting because recovering a 128-character random password offline is not practically feasible.
Apply least privilege to service accounts. A service account should have exactly the permissions it needs and nothing more. This limits the damage if a password is eventually recovered. Review group memberships and permissions regularly.
Audit SPNs and service-account ownership. Know which accounts have SPNs registered, which services they represent, and whether those SPNs are still needed. Orphaned service accounts, ones where the service was decommissioned but the account and its SPN remain, are easy targets.
Review encryption type configurations. Modern environments should prefer AES-based Kerberos encryption. Legacy RC4 support may still be needed for older systems, but its presence where it is not needed unnecessarily increases the tractability of offline cracking.
Monitor and baseline service-ticket activity. Establish what normal looks like, then alert on meaningful deviations. Combine authentication logs with endpoint telemetry to build fuller context around anomalies.
Disabling Kerberos is not a viable mitigation. The protocol is foundational to Windows domain authentication. Blindly blocking all service-ticket requests would break most of the services that depend on authentication. The response to Kerberoasting is not to break the protocol but to remove the weakness it exploits.
The Protocol Did Its Job; The Weakness Is Elsewhere
Kerberos issued a legitimate ticket in response to a legitimate request. From the protocol's perspective, nothing went wrong.
The problem is that this ticket contains material encrypted with a key derived from a password that a human chose. The protocol assumed that the password protecting the key would be strong enough to withstand offline guessing. In many environments, service accounts have weak passwords because no one is guessing them interactively, so the usual heuristics about password strength were not applied.
Kerberoasting works because it turns ticket-derived cryptographic material into an offline oracle: a way to test password guesses without ever returning to the domain. The protocol enables this because service authentication requires the client to receive material that the service will eventually decrypt. The attack grabs that material before the service sees it.
The design assumption that service-account passwords are strong enough to resist this treatment was reasonable in principle. In practice, service-account passwords often were not set with this threat in mind.
That is the lesson Kerberoasting teaches: authentication protocols are designed with assumptions about secrets. When those assumptions about secret quality break down, protocol operations that were intended to be safe can become attack primitives. The weakness is not the cryptography. It is the password standing behind it.
Top comments (1)
tr.ee/dev-to