Kerberoasting still turns AD service accounts into privilege paths

At a glance

What this is: This is an explanation of Kerberoasting and its role in Active Directory compromise, with the key finding that attackers can abuse SPN-enabled service accounts to recover plaintext passwords offline.

Why it matters: It matters because AD service-account governance, SPN hygiene, and detection for abnormal Kerberos ticket requests remain core controls for both NHI and broader identity security programmes.

Context

Kerberoasting is a Kerberos credential abuse technique against Microsoft Active Directory service accounts. A valid domain account can request service tickets for accounts with a registered Service Principal Name, then crack the encrypted tickets offline to recover the underlying password.

The security gap is not exotic exploitation but trust in long-lived service accounts with unnecessary SPNs and weak passwords. That makes this an identity governance problem as much as a detection problem, because the attack starts with normal-looking access and ends with privilege escalation.

Semperis frames the issue alongside recent Five Eyes guidance that urges stronger Active Directory protection. The practical question for IAM and PAM teams is whether service-account ownership, SPN necessity, and password strength are actually under control.

Key questions

Q: What breaks when service accounts keep unnecessary SPNs in Active Directory?

A: Unnecessary SPNs create a Kerberoasting path that lets a valid domain user request tickets for accounts that no longer need them. If those accounts also have weak passwords, the attacker can crack the tickets offline and recover credentials that lead to privilege escalation. The failure is governance first, because the attack surface should not still exist.

Q: Why does Kerberoasting remain risky even without elevated privileges?

A: Because the attacker only needs a normal domain account to request tickets, then works offline to recover the password hash. That makes detection harder and gives defenders less opportunity to block the attack at the moment it starts. The risk rises when service accounts are privileged, long-lived, or poorly reviewed.

Q: What signs indicate Kerberoasting activity in Active Directory?

A: Look for a single account making many Kerberos service ticket requests in a short period, requests for unusual targets, weak-encryption ticket indicators, or activity against a honeytoken service account. These patterns are useful because the attack itself can resemble ordinary directory traffic until the request volume or target choice becomes abnormal.

Q: How should IAM teams prioritise Kerberoasting remediation versus other AD hardening work?

A: Prioritise the service accounts that combine SPNs, weak passwords, and high privilege, especially where the associated server or application has already been retired. That gives the fastest reduction in attacker leverage because it removes both the ticketing path and the offline cracking opportunity from the most exposed accounts.

Technical breakdown

How Kerberoasting turns service tickets into offline password cracking

Kerberoasting abuses the Kerberos service ticket flow. When a domain user asks for a ticket to an SPN-registered service account, Active Directory returns a ticket encrypted with material derived from that service account’s password. The attacker does not need elevated rights to make the request. Once the ticket is captured, the attacker works offline against the hash material until the plaintext password is recovered. The important detail is that the compromise path is indirect: the attacker is not breaking Kerberos itself so much as exploiting weak service-account passwords that can be tested without triggering immediate authentication failures.

Practical implication: Treat every SPN-enabled service account as a password-cracking target, not just an internal application dependency.

Why SPN sprawl creates hidden privilege paths

A Service Principal Name is what makes a service account reachable through Kerberos. In practice, SPNs accumulate on accounts long after the services they once supported have changed or been decommissioned. That creates privilege paths that are easy to overlook because the account can still function while no longer serving a legitimate operational need. If the SPN is unnecessary, the attack surface is unnecessary too. Kerberoasting becomes much easier when high-privilege or stale accounts retain SPNs simply because no one has reviewed whether the binding is still valid.

Practical implication: Inventory SPNs, validate business need, and remove orphaned registrations from service accounts that no longer require them.

How defenders detect Kerberoasting activity in Active Directory

Detection depends on recognising the request pattern rather than the crack itself. A common signal is a single account making a large number of service ticket requests in a short window. Another useful indicator is a honeytoken service account that should never receive legitimate Kerberos requests. Semperis also notes weak-encryption ticket requests as a practical indicator in its monitoring. These signals matter because Kerberoasting often looks like routine directory traffic until the volume or targeting pattern exposes the attacker's intent.

Practical implication: Tune monitoring for anomalous ticket-request bursts, weak-encryption requests, and honeytoken hits tied to Kerberos service accounts.

Threat narrative

Attacker objective: The objective is to recover service-account credentials that unlock broader access and higher privileges inside Active Directory.

1. Entry begins with a valid domain account requesting Kerberos service tickets for SPN-enabled service accounts in Active Directory.
2. Credential access occurs when the attacker extracts the encrypted tickets and cracks them offline to recover plaintext service-account passwords.
3. Privilege escalation follows when the recovered password is reused against higher-value services or accounts, expanding access across the domain.

Breaches seen in the wild

• Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
• CISA Private-CISA GitHub leak 2026: A CISA contractor's public GitHub repo exposed AWS GovCloud admin keys, Artifactory credentials and plaintext passwords for six months.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Kerberoasting is really an SPN governance failure before it is a cracking technique. The attack works because service accounts are left with reachable SPNs and passwords that are weak enough to crack offline. That means the real control boundary is service-account lifecycle discipline, not only detective tooling. The practitioner conclusion is that every surviving SPN must justify its existence.

Standing service-account trust creates a privilege path that attackers can activate without elevated access. A valid domain user can initiate the attack, which means the organisation has effectively published a credential-abuse path inside its own identity fabric. This is why service-account ownership, password strength, and account purpose cannot be reviewed as separate topics. The practitioner conclusion is that blast radius starts at account design, not at incident response.

Kerberoasting illustrates why AD hygiene and PAM governance cannot be split. Service accounts often sit outside the same scrutiny applied to human privileged users, yet they can deliver equal or greater access. When those accounts retain SPNs unnecessarily, the attack surface expands quietly. The practitioner conclusion is to govern service accounts with the same lifecycle and privilege standards as any other high-risk identity.

Kerberoasting remains attractive because the control gap is operational, not theoretical. The article points to decommissioned servers, unnecessary SPNs, and weak-password service accounts as recurring conditions. That combination shows a category of identity debt that keeps producing the same exploit path. The practitioner conclusion is to treat stale SPNs and password weakness as a measurable governance defect.

Identity attack detection has to look for behavioural patterns, not just compromise artefacts. Kerberoasting often produces normal-looking Kerberos traffic until volume and targeting patterns become suspicious. That is why anomaly detection, honeytokens, and account-usage validation matter together. The practitioner conclusion is to make ticket-request monitoring part of the core identity control set.

What this signals

SPN hygiene is the hidden control plane for Kerberoasting risk. If an SPN no longer maps to an active business service, it should not remain attached to a live account. The governance lesson is that attack reduction starts with removing needless Kerberos reachability, not only watching for abuse after the fact.

Service-account lifecycle management matters as much as password policy. Weak passwords are exploitable, but stale ownership and decommissioned dependencies are what let those weak passwords persist. Teams that only harden credentials without reviewing the account’s purpose keep the same attack path in place.

For practitioners

• Audit SPN registrations across service accounts Verify whether each SPN still maps to a live, required service. Remove stale registrations from decommissioned systems and document the owner for every remaining account.
• Reset weak service-account passwords Move high-risk service accounts to strong, unique passwords and shorten the time they remain unchanged when the account supports Kerberos authentication.
• Monitor for abnormal Kerberos ticket volume Alert on one account requesting many service tickets in a short period, especially when the target is a privileged service account or an account with weak encryption indicators.
• Use honeytoken service accounts Create unused service accounts that should never receive legitimate ticket requests, then treat any Kerberos request for them as a high-confidence signal.
• Review decommissioned servers linked to SPNs Confirm that server names embedded in SPNs still resolve to active computer objects and are still responsive before leaving the account in service.

Key takeaways

• Kerberoasting exploits ordinary Kerberos behaviour to turn service accounts into offline password-cracking targets.
• The article ties the technique to repeated real-world use by groups including BlackSuit, APT40, and Akira, which shows the pattern is still operationally relevant.
• The most effective reduction comes from SPN removal, service-account review, and monitoring for abnormal ticket-request behaviour.

Key terms

• Kerberoasting: Kerberoasting is an Active Directory attack that targets service accounts by requesting Kerberos tickets and attempting to crack the underlying password offline. It is dangerous because weak service account passwords and excessive permissions can turn one ticket into elevated access across critical systems.
• ServicePrincipalName: ServicePrincipalName is an Active Directory attribute that identifies the service or application associated with an account. In practice, it helps security teams locate service accounts during discovery and validate whether an account is still tied to a legitimate workload, which supports inventory and governance efforts.
• Service Account: A special-purpose account used by applications, automated tools, or services rather than a human user to interact with systems, APIs, and infrastructure. Service accounts are a primary category of NHI and one of the most frequently exploited attack vectors.
• Kerberos Ticket-Granting Ticket: A Kerberos credential that proves the user has already authenticated and can request service tickets without re-entering credentials. In delegation scenarios, it becomes valuable because a service may store it in memory, making it a target for attackers who compromise the host.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.