TL;DR: Kerberoasting lets a valid domain account request Kerberos service tickets for SPN-enabled service accounts, then crack the encrypted tickets offline to recover plaintext passwords and escalate privileges, according to Semperis. The attack remains relevant because weak service-account hygiene and SPN sprawl still leave Active Directory exposed to low-noise credential abuse.
At a glance
What this is: This is an analysis of Kerberoasting, an Active Directory attack that targets SPN-backed service accounts and can convert ordinary domain access into privilege escalation.
Why it matters: It matters because IAM teams often inherit service accounts with weak ownership, unclear necessity, and long-lived credentials that make offline password cracking viable.
By the numbers:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
👉 Read Semperis's Kerberoasting guide for Active Directory defenders
Context
Kerberoasting is an Active Directory credential attack that abuses how service tickets are issued to accounts with Service Principal Names, or SPNs. A valid domain user can request those tickets without elevated privileges, then crack the encrypted material offline and recover a service account password if it is weak enough.
For IAM and NHI practitioners, the governance gap is not the Kerberos protocol itself but the unmanaged service-account layer around it. Expired services, orphaned SPNs, weak passwords, and incomplete offboarding all widen attack paths that traditional identity reviews often miss.
Key questions
Q: How should security teams reduce Kerberoasting risk in Active Directory?
A: Reduce Kerberoasting risk by shrinking the number of SPN-backed accounts, removing SPNs that no longer support live workloads, and enforcing strong passwords with regular rotation. Then add monitoring for unusual ticket-request patterns so you can spot abuse quickly. The most effective defence is identity hygiene first, detection second.
Q: Why do service accounts create such a large Kerberoasting exposure?
A: Service accounts create exposure because they are often long-lived, lightly reviewed, and tied to SPNs that allow ticket requests from any valid domain user. If the password is weak enough, the attacker can crack the ticket offline without touching the service. That turns neglected account lifecycle into an escalation path.
Q: What is the difference between Kerberoasting and normal credential theft?
A: Kerberoasting targets encrypted Kerberos service tickets and tries to recover the underlying password offline, while normal credential theft usually captures passwords, hashes, or tokens directly from a system or user session. That distinction matters because the attack can stay quieter and avoid many endpoint-only defences.
Q: When does Kerberoasting become a high-priority IAM risk?
A: Kerberoasting becomes high priority when SPNs are attached to privileged accounts, service ownership is unclear, or password rotation is inconsistent. Those conditions expand the blast radius of a successful crack and make escalation more likely. If your inventory cannot explain why an SPN exists, treat it as a security issue.
Technical breakdown
How Kerberoasting turns SPNs into offline cracking targets
Kerberos service tickets for SPN-linked accounts are encrypted with material derived from the service account password. An attacker who already has a valid domain identity can request many tickets, extract them, and crack them outside the network until one password yields. The protocol does not require the attacker to touch the service itself, which makes the activity quieter than interactive credential theft. The real weakness is not Kerberos authentication, but the combination of service accounts, weak passwords, and broad ticket exposure.
Practical implication: reduce the number of SPN-backed accounts and enforce strong, rotated service-account credentials.
Why SPN sprawl creates identity blast radius
SPNs often linger long after the application, server, or integration that created them has changed. That means an account can remain valid, privileged, and discoverable even when the underlying workload is no longer active. In practice, this turns identity inventory into a security control: if teams cannot explain why an SPN exists, they cannot defend it. Kerberoasting succeeds fastest where ownership is unclear and service accounts are treated as infrastructure leftovers instead of governed identities.
Practical implication: treat every SPN as an owned identity with a business justification, review date, and removal path.
Detecting Kerberoasting through ticket volume and weak encryption signals
Defenders usually look for abnormal ticket request volume from a single account, especially when the requests are concentrated in a short window. Honey or honeytoken service accounts can also expose automated ticket harvesting because any request against them is suspicious by design. In monitored environments, weak encryption on service ticket requests can add another signal, but detection works best when paired with SPN hygiene and baselining. Without clean inventory, even good telemetry becomes noisy and incomplete.
Practical implication: combine behavioural detection with inventory cleanup so alerts point to real abuse rather than stale accounts.
Threat narrative
Attacker objective: The attacker aims to turn ordinary domain access into higher-privilege credentials that unlock broader control of Active Directory.
- Entry occurs when a threat actor uses a valid domain account to request Kerberos service tickets for an SPN-enabled service account.
- Escalation follows when the attacker cracks the encrypted ticket offline and recovers the plaintext service-account password.
- Impact occurs when the recovered credentials are reused to escalate privileges, move laterally, or launch ransomware inside the Windows domain.
Breaches seen in the wild
- Cisco Active Directory credentials breach — Kraken ransomware group leaked Cisco Active Directory credentials.
- MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Kerberoasting is a service-account governance problem, not just a password problem. The attack works because an identity exists, remains reachable, and still has an SPN that can be queried by a valid domain user. That means the control gap begins at inventory, ownership, and lifecycle management, not only at password strength. Practitioners should treat every SPN as a governed non-human identity with an explicit business purpose.
SPN cleanup is one of the highest-return identity hardening actions in Active Directory. Decommissioned servers, orphaned integrations, and inherited service accounts frequently leave behind attackable identity surfaces. When an SPN no longer supports a live workload, keeping it in place preserves an offline cracking target for no operational benefit. Teams should remove unused SPNs before they spend time on more complex compensating controls.
Kerberoasting validates the NHI blast-radius model. A single exposed service account can become an escalation path that reaches beyond its original function, especially where privileges were granted for convenience and never revisited. That is why service-account governance has to include privilege review, rotation discipline, and offboarding, not just monitoring. The practical conclusion is simple: reduce the blast radius of every non-human identity before attackers do it for you.
Detection without governance will always lag the attack. Ticket-volume analytics and honeyaccounts are useful, but they are only credible when paired with clean SPN inventories and strong account ownership. Otherwise, alerts point to legacy noise instead of active abuse. Practitioners should build detection on top of identity hygiene, not as a substitute for it.
From our research:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which explains why SPN sprawl so often survives security reviews.
- For a broader identity baseline, review 52 NHI Breaches Analysis for recurring patterns in service-account compromise and escalation.
What this signals
Kerberoasting is a reminder that Active Directory risk is increasingly an NHI governance problem, not just an authentication problem. Where SPNs are not actively owned and reviewed, attackers inherit a catalogue of stale access paths that conventional IAM processes often leave untouched.
Identity blast radius: service-account exposure becomes materially worse when a single account can be reused across systems, tickets, or tiers. Teams should map which identities can still be queried, cracked, or reused, then reduce those paths before they become incident response work.
The operational signal for security leaders is to treat SPN cleanup and service-account rotation as programme work, not one-time hardening. Teams that can answer who owns each account, why it exists, and when it is reviewed are in a much stronger position than those relying only on detection.
For practitioners
- Inventory every SPN-backed service account Identify which accounts still have SPNs, who owns them, which applications depend on them, and whether each one is still actively used. Remove the SPN if the workload is gone or the account no longer serves a real function.
- Remove unnecessary SPNs before tuning detection Prioritise cleanup of orphaned, duplicated, or inherited SPNs because each unnecessary entry is an offline cracking target. Pair removal with change control so application owners can validate live dependencies.
- Enforce strong service-account password and rotation policy Require long, unique, and rotated credentials for remaining service accounts, and do not allow exceptions without documented risk acceptance. Where possible, replace password-based service accounts with managed or non-password alternatives.
- Monitor for abnormal Kerberos ticket request patterns Alert on high-volume ticket requests from a single identity, short-burst request activity, and requests against honeytoken service accounts. Use the detection to confirm whether the source identity maps to an expected administrative or application pattern.
Key takeaways
- Kerberoasting succeeds when service accounts are left with unnecessary SPNs, weak passwords, and unclear ownership.
- The attack is still effective because offline cracking turns a valid domain account into a privilege-escalation path without touching the service.
- Teams should prioritise SPN inventory, service-account rotation, and removal of dead identities before relying on detection alone.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Kerberoasting exploits weak service-account governance and password hygiene. |
| NIST CSF 2.0 | PR.AC-1 | Kerberoasting turns excessive identity reach into privilege escalation. |
| NIST Zero Trust (SP 800-207) | PR.AC-4 | Zero trust requires continuous validation of non-human identities and their access paths. |
Review SPN-backed accounts for weak credentials and remove unnecessary service identities.
Key terms
- Kerberoasting: Kerberoasting is an Active Directory attack where a valid domain user requests Kerberos service tickets for accounts with SPNs and then cracks the encrypted tickets offline. The goal is to recover service-account credentials that can be reused for escalation or lateral movement.
- Service Principal Name: A Service Principal Name is an Active Directory identifier that links a service instance to a service account so Kerberos can issue tickets for it. SPNs are operationally necessary, but when they are left on unused or over-privileged accounts they become attackable identity surfaces.
- Offline Ticket Cracking: Offline ticket cracking is the process of extracting encrypted Kerberos ticket material and testing password guesses outside the target environment. Because the guessing happens away from the live service, defenders may see little interactive activity before credentials are recovered.
- Identity Blast Radius: Identity blast radius is the amount of damage that can occur if one non-human identity is abused or compromised. In practice, it reflects how far an account's privileges, reuse, and trust relationships can carry an attacker before containment occurs.
Deepen your knowledge
Kerberoasting, service-account governance, and Active Directory hardening are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a control baseline for Windows identities, it is worth exploring.
This post draws on content published by Semperis: Kerberoasting Explained. Read the original.
Published by the NHIMG editorial team on 2024-08-26.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org