What breaks when a low-privilege user can Kerberoast service accounts?

How Kerberoasting Changes the Trust Model for Service Accounts

Kerberoasting succeeds because the directory will hand a low-privilege principal a service ticket for a service account when that account has a service principal name. The practical break is that service identity is no longer protected by “who can log on” alone. A user who cannot administer the domain can still obtain material that is worth cracking offline, which collapses the separation between ordinary access and privileged service credentials.

That matters because service accounts are often treated as infrastructure plumbing, not as high-value identities. When ticket material can be collected by any authenticated user, the real control objective shifts from preventing direct logon to preventing exposure of crackable credential material and reducing what those credentials can unlock if recovered.

For the identity model behind that exposure, see Service Account Security Guide and Ultimate Guide to NHIs — What are Non-Human Identities, which place service accounts in the broader non-human identity lifecycle.

What Actually Breaks After Ticket Material Is Harvested

The first thing that breaks is the assumption that credential secrecy begins at the account boundary. Kerberoasting turns Kerberos ticket issuance into a data exposure path, so the attacker no longer needs repeated online interaction once the ticket is captured. If the service account password is weak, old, reused, or governed loosely, the attacker can recover it outside the domain and then use it like any other credential.

The second break is blast radius. Service accounts frequently have standing access to applications, databases, integration paths, or delegated admin functions. Once the password is recovered, the attacker may gain a foothold that is functionally far more powerful than the low-privilege user who started the attack. That is why weak service-account hygiene is not just an authentication problem, but an authorization and privilege problem as well.

For broader coverage of the control failures that make this possible, Ultimate Guide to NHIs, Key Challenges and Risks and NHI Authentication Guide both map the exposure back to long-lived secrets, weak authentication design, and overprivilege.

Why Kerberoast Exposure Becomes a Governance Problem

Kerberoastable service accounts are a governance failure when teams treat them as exceptions rather than managed identities. If owners cannot name every service account, explain why it exists, and justify its privilege set, then the organisation cannot reliably decide whether a ticket leak is acceptable exposure or a reportable control gap. In practice, the issue is not the request for a ticket. The issue is the presence of a recoverable secret behind a broadly reachable authentication flow.

This is also where lifecycle discipline matters. Service accounts with long-lived passwords, unnecessary SPNs, human use, or broad reuse across environments turn a single roastable account into a repeatable compromise path. Strong service-account governance narrows the window for offline cracking and limits what the recovered secret can do if the password falls.

Relevant control patterns are described in Top 10 NHI Issues and NHI Ownership and Accountability Guide, which emphasise ownership, lifecycle control, and reduction of shared or orphaned identities.

Risk and Threat Considerations

Kerberoast exposure is attractive because it gives an attacker an offline cracking opportunity without needing repeated access to the domain controller. That reduces detection opportunities and makes weak, reused, or non-expiring service-account passwords a high-value target. The threat is not limited to credential theft, it is credential recovery followed by lateral movement or privilege abuse through whatever the recovered account can reach.

Failure mechanism: A low-privilege account requests ticket material for a service principal, the attacker extracts the encrypted payload, and weak service-account credentials are cracked offline after the initial request.

Impact: The attacker can move from ordinary user access to high-value service access, often with better privileges than the original account and with much lower chance of immediate detection.

Practitioner Guidance

What to verify: Confirm which service accounts have SPNs, whether they still need them, and whether their passwords are long-lived, reused, or human-managed. Any account that can be roasted should be treated as an exposure candidate until its privilege and secret model is proven acceptable.

Decision rule: If a service account can authenticate to production systems and its password is not clearly high-entropy, rotated, and owner-assigned, prioritise credential hardening and privilege reduction before relying on detective controls alone. Once the secret is recoverable offline, visibility after the fact is too late to be the primary defence.

Practitioner takeaway: Kerberoasting breaks the idea that low-privilege access is harmless, because it converts ordinary directory visibility into a path for recovering privileged service credentials.

Related resources from NHI Mgmt Group

• What are common vulnerabilities associated with service accounts in AI deployments?
• What breaks when a Linux kernel vulnerability lets a low-privilege user gain root?
• What breaks when privileged service accounts are treated like user admin accounts?
• What breaks when service accounts are treated like low-priority identities?