Kerberoasting Explained: Risks, Detection and Defense
Learn how Kerberoasting turns service tickets into offline password tests, how to detect it, and which controls reduce risk. Audit your service accounts today.
Kerberoasting: How Service Tickets Become a Password Risk
If an attacker gets into an employee's account, they may be able to put your service accounts at risk. With normal domain access, they can request Kerberos service tickets, copy the ticket data for offline analysis, and then try password guesses without contacting the domain controller again. Nothing "hacky" has to happen up front - the first ticket request can look like everyday activity.
That technique is called Kerberoasting. It takes advantage of a practical weak point in how many organizations run service accounts: passwords that are easy to guess, rarely changed, or reused across systems. Kerberos is doing its job. The problem is what's inside the ticket - specifically, the part protected by the service account's password, plus whatever permissions that account has if the password ever gets recovered.
This guide walks through the Kerberos concepts you need, how Kerberoasting works, what affects its real-world impact, and how defenders can reduce and detect the risk. The goal is to make better security decisions - not to treat every service-ticket request as an attack.
Kerberos and service tickets, in practical terms
Kerberos is an authentication protocol commonly used in Windows domain environments. It helps users prove who they are without sending their password over the network every time they connect. You don't need to memorize every Kerberos message to understand Kerberoasting - you just need four building blocks: the Key Distribution Center, the ticket-granting ticket, service tickets, and service principal names.
The Key Distribution Center (KDC) is the trusted system that issues Kerberos tickets. In a Windows domain, the domain controller provides that service. The KDC has two logical roles: the Authentication Server (involved in the initial login) and the Ticket-Granting Server (which hands out tickets for services).
After authentication, the user gets a ticket-granting ticket (TGT). The client uses that TGT to request tickets for specific services, instead of entering the user's password again for every connection. A service ticket is what the client presents to a particular application or server.
Services are identified using Service Principal Names (SPNs). An SPN links a service instance to the domain account that runs it. For example, an organization might register an SPN for a web application or a SQL Server instance. Often, the service runs under a dedicated domain account (a service account) rather than a person's account.
Why the service account's key matters
When the KDC issues a service ticket, part of that ticket is encrypted with a key derived from the service account password tied to the SPN. The intended service can decrypt that part using the matching account credentials. The requesting client is not meant to decrypt the protected service data.
That design is necessary for Kerberos service authentication. It also enables Kerberoasting: an authenticated domain user can request a service ticket, and the ticket includes material an attacker can test against password guesses offline.
Importantly, a ticket request by itself doesn't prove wrongdoing. Clients need service tickets for normal access, and administrators can query Active Directory to review SPNs. The protocol also can't tell whether a request is routine work or early reconnaissance. For more background on account controls, see our guide to service account management.
How Kerberoasting works - and what the attacker cracks
Kerberoasting usually starts after an attacker already has a valid domain account. That access might come from phishing, credential reuse, or some other compromise. The attacker doesn't always need admin rights to request service tickets. In many setups, a normal authenticated domain user can request tickets for accounts that have registered SPNs.
You can think of the attack as a short sequence:
- Find accounts with SPNs. The attacker identifies service accounts associated with services stored in the directory.
- Request service tickets. The attacker asks the KDC for tickets tied to selected SPNs. These are legitimate Kerberos requests, not malformed packets that exploit a software bug.
- Capture ticket material. The response includes an encrypted component tied to the service account's key.
- Test password guesses offline. The attacker generates candidate passwords, derives candidate keys, and checks whether they match what's in the captured ticket material.
- Use the recovered password. If the password is weak enough to find, the attacker may be able to authenticate as that service account, depending on its permissions and the environment's controls.
Offline guessing is the important distinction
Once the attacker has captured the relevant ticket material, they can test guesses locally, without repeatedly contacting the domain controller. That's what offline means here. There's no login system receiving each guess, no "failed logins" counter being incremented, and no lockout rule being enforced for those attempts.
Account lockout can still help against online password guessing, but it doesn't stop offline testing of captured ticket data. So lockout policies aren't a substitute for strong service-account passwords.
Also, the attacker isn't "decrypting the ticket" in the normal sense or breaking Kerberos encryption. This is still a password-guessing attack against cryptographic material. For each candidate, the cracking process derives a key using the Kerberos method in use and checks whether it lines up with the captured data. A weak, guessable password may fall quickly; a long, random password won't be realistically guessable with typical resources.
Encryption type changes the effort, not the underlying risk
Kerberos environments can use different encryption types. Older setups may include RC4, where the key is closely tied to the account's NT hash. AES-based Kerberos encryption uses a key-derivation process that makes each password guess more computationally expensive. In practice, encryption type changes the cost of testing, but it doesn't magically make a weak password safe.
So the takeaway is pretty direct: Kerberoasting is mainly a risk when service-account passwords are weak - not proof that Kerberos encryption is broken. Strong, random secrets make offline guessing impractical; weak human-made passwords reduce the search space to something an attacker can work through.
Impact, detection, and investigation
Recovering a service-account password doesn't automatically mean the attacker owns the domain. What happens next depends on that account's permissions, where its credentials work, and what systems it can reach. A narrowly scoped account used by one application creates a different risk than a shared account with local administrator rights across lots of servers.
In real environments, permissions often drift. Service accounts can accumulate access as systems are added. Temporary group memberships may never get removed. One account might run multiple services, or still have permissions long after an application is retired. Those "over time" patterns can turn a recovered password into a path for lateral movement or privilege escalation.
What defenders can see
Windows Security Event 4769 records that a Kerberos service ticket was requested. One event is usually normal and won't prove malicious activity. More useful signals include a sudden increase in requests, one account requesting tickets for many unrelated SPNs, or tickets for services the account has never used before.
Encryption type is another clue. A request for RC4 in an environment that normally uses AES may be worth a look, especially if it coincides with unusual ticket-request volume. But it's not definitive. Legacy apps and configuration differences can create legitimate exceptions.
The bigger detection problem is context: separating unusual from merely "busy." Some applications request lots of tickets as part of normal operation, and admins might run directory audits. If a rule alerts on every burst, it turns into noise - and teams stop trusting noisy alerts.
Investigate behavior in context
Start by building a baseline around the account, the machine, the time window, and the services involved. Ask whether the requesting user normally accesses those SPNs, whether the requests came from a familiar workstation, and whether the volume matches the user's typical pattern. Then connect ticket activity with endpoint and identity telemetry, recent phishing reports, unusual sign-ins, and other signs of compromise.
A workstation that suddenly requests tickets for many service accounts right after suspected credential theft is more meaningful than an isolated 4769 event. And investigation should determine whether any service-account credentials were actually exposed and what those service accounts can access.
For broader context on protecting domain identities, see our guide to Active Directory security. The goal is to identify patterns - not to label every legitimate Kerberos operation as an attack.
How to reduce Kerberoasting risk
Good defenses target the conditions that make ticket material valuable for guessing: weak service-account passwords, excessive permissions, unmanaged SPNs, and poor visibility. Disabling Kerberos isn't a realistic fix. Kerberos is core to many Windows domain services. Blocking normal ticket requests would break legitimate authentication without addressing the actual password problem.
1. Use long, randomly generated passwords
Service-account passwords shouldn't rely on anyone remembering them. Use a long, random password and store and deploy it through an approved secrets-management process. This is the most direct control, because offline guessing depends on passwords being predictable enough to test.
Avoid passwords built from a service name, company name, season, year, or other patterns that are likely to show up in a wordlist. Changing a weak password "every so often" doesn't solve the issue if each replacement is still guessable. What you want is enough randomness to make guessing infeasible, not just a newer date on the calendar.
2. Prefer group Managed Service Accounts where supported
Group Managed Service Accounts (gMSAs) let Active Directory manage service-account passwords automatically. Instead of humans picking and updating credentials, the domain holds a long random password and rotates it based on configuration.
gMSAs are a strong option for compatible services, but migration needs testing. Confirm the application and hosts support gMSAs, identify which systems are allowed to retrieve the managed password, and plan the change so the service doesn't fail during deployment. A managed account doesn't mean you can ignore permissions or monitoring.
3. Enforce least privilege and reduce reuse
Only grant a service account the access it actually needs. Avoid broad admin memberships, unnecessary interactive logon rights, and using one account across unrelated applications. Splitting accounts may cost a bit more effort operationally, but it limits the blast radius if a credential is compromised.
Review permissions as systems and ownership change. Access granted for a migration or temporary troubleshooting task should have an owner and an expiry (or at least a scheduled review). Without that discipline, permissions tend to grow rather than shrink.
4. Audit SPNs and encryption settings
Maintain an inventory of SPNs, which accounts they map to, what services they represent, and who owns them. Remove SPN registrations you no longer need after verifying the service has actually been retired. Orphaned accounts and stale SPNs add exposure and make monitoring harder.
Prefer modern AES-based Kerberos encryption wherever systems support it. If you keep exceptions for legacy apps, make those exceptions explicit, documented, and reviewed. Changing encryption settings without checking compatibility can break production services, while leaving legacy settings enabled everywhere by default can also raise risk. The right approach is to identify dependencies and reduce exceptions deliberately.
5. Monitor service-ticket behavior
Collect and retain relevant Kerberos events, then establish what "normal" looks like for users, service accounts, and endpoints. Alert on meaningful deviations, not every ticket request. Combine identity events with endpoint telemetry so an analyst can tell the difference between a typical application and a workstation acting oddly.
A practical priority order is: replace weak service-account passwords, move compatible services to gMSAs, reduce account privileges, clean up SPNs, and improve detection coverage. This sequence addresses the underlying exposure first, instead of hoping alerts catch everything after the fact. For related guidance, see Kerberos authentication fundamentals.
Conclusion
Kerberoasting works because a normal Kerberos operation exposes ticket material that can be tested against password guesses offline. Kerberos itself isn't being "broken" - the weak link is usually a human-chosen service-account password and the permissions that account has accumulated.
Start with an inventory of SPNs and service accounts. Replace predictable passwords, move compatible services to gMSAs, remove unnecessary privileges, and baseline Event 4769 activity before building alerts. If you manage Windows domains, audit those accounts now - because treating every service-ticket request as suspicious is usually the wrong (and less effective) approach.