Kerberoasting protection exposes the weak link in Active Directory

At a glance

What this is: This is an analysis of Kerberoasting in Active Directory and why weak service account passwords remain the core failure mode behind the attack.

Why it matters: It matters because IAM and PAM teams still inherit service account risk when Kerberos authentication is normalised but credential strength and lifecycle controls are not.

Context

Kerberoasting is a Kerberos abuse pattern in which a user with ordinary domain access requests a service ticket for an SPN, then cracks the encrypted material offline to recover the service account password. The attack succeeds because the ticketing process is legitimate, while the credential inside the ticket is often weak enough to guess.

In Active Directory environments, that turns service account hygiene into an access control problem, not just a password policy problem. If a service account password can be recovered offline, the attacker inherits whatever privileges the account holds, including lateral movement and service-level control.

Key questions

Q: What breaks when Active Directory passwords are exposed outside the environment?

A: Native password policy breaks down because it can only judge whether a credential matches local rules, not whether attackers already know it. Once a password appears in breach lists, malware logs, or reuse ecosystems, the directory may still accept it as valid. That means attack success can come from legitimate authentication, not from weak-password guessing.

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: How can security teams tell if Kerberoasting risk is increasing?

A: Look for more SPN-bearing accounts than you can justify, older service-account passwords, use of weak encryption such as RC4_HMAC, and LDAP activity that enumerates directory metadata. If service identities have no owner, no rotation discipline, or broad privilege across multiple applications, the environment is moving toward higher Kerberoasting exposure.

Q: How should teams respond when a service account is suspected to be crackable?

A: Contain the account first by resetting the password, reducing its permissions, and reviewing where it is used before assuming the risk is limited to one system. Then check for reuse, compromise indicators, and any lateral movement tied to that identity. The goal is to break reuse and remove standing leverage before the account is abused.

Technical breakdown

How Kerberoasting uses normal Kerberos ticketing

Kerberoasting starts with SPN enumeration, where an attacker identifies service accounts registered to provide Kerberos-authenticated services. The attacker then sends a standard TGS-REQ to the KDC and receives a TGS-REP containing a service ticket encrypted with material derived from the target account’s password. Nothing in that exchange is inherently abnormal, which is why the attack blends into ordinary authentication traffic. The critical weakness is not the protocol flow itself but the fact that the encrypted ticket can be taken offline and attacked without further interaction with the domain.

Practical implication: monitor SPN discovery and unusual TGS-REQ volume as identity-abuse signals, not as proof of a compromised account.

Why offline cracking turns service tickets into credential theft

Once the attacker captures the ticket, the work moves offline. That means the defender loses visibility and rate limiting, while tools such as hash crackers can test guesses until the password falls. Service accounts are especially exposed when passwords are long-lived, reused, or based on predictable patterns, because offline recovery depends on guessability rather than live authentication controls. The attack does not need privileged initial access, only a domain user context and a crackable service credential. Once recovered, the password becomes a reusable authenticator for the service account itself.

Practical implication: treat weak service account passwords as a direct credential exposure risk, not a compliance-only issue.

How cracked service credentials become privilege escalation

After password recovery, the attacker authenticates as the service account and inherits its permissions. In many environments, service accounts are overprivileged because they were created for availability and never revisited with lifecycle discipline. That creates a clean escalation path from low-privilege domain user to higher-value service access and, in some cases, lateral movement across systems that trust the account. The attack therefore converts an ordinary authentication mechanism into a post-exploitation foothold, with impact determined by the service account’s access scope.

Practical implication: review service account entitlements as part of privilege governance, not just password management.

Threat narrative

Attacker objective: Recover a service account password and use its privileges to escalate access inside Active Directory.

1. The attacker begins with ordinary domain access and enumerates service principal names to identify Kerberos-enabled targets.
2. The attacker requests a service ticket, captures the encrypted ticket material, and moves the blob offline for cracking.
3. If the password is recovered, the attacker authenticates as the service account and uses its privileges for escalation and lateral movement.
4. The end state is control of a service account that can expose sensitive services or widen access across the domain.

Breaches seen in the wild

• Storm-0501 hybrid cloud attacks 2024: Ransomware affiliate Storm-0501 stole Entra Connect Sync credentials to move from on-prem AD to Entra ID, then forged tokens via a rogue federated domain.

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 fundamentally a service-account governance problem, not a ticketing problem. Kerberos is doing what it was designed to do when it issues service tickets, and that is exactly why the attack persists. The weak point is the service credential that sits behind the ticket and can be cracked offline. Practitioners should read this as a lifecycle and entropy issue for NHI credentials, not as a protocol flaw alone.

Long-lived service credentials create an offline attack window that most identity controls do not see. Once the ticket leaves the KDC, defenders lose live enforcement and are left with password strength as the remaining barrier. That makes the relevant control question whether service account secrets are strong enough to survive offline guessing, not whether authentication succeeded. The implication is that password policy for service accounts is part of access security, not a housekeeping task.

SPN exposure expands the attack surface in proportion to service account sprawl. Every registered service principal becomes a candidate for ticket capture, and every weak password behind one of those accounts becomes a potential escalation path. This is why service account inventory and entitlements matter as much as secret quality. Teams should treat unmanaged SPNs as identity attack surface, not merely directory metadata.

Kerberoasting shows how overprivileged NHI accounts convert authentication into authority. If a cracked service account can administer systems, query sensitive services, or move laterally, the attacker has effectively turned one credential into domain leverage. The governance failure is allowing service identity scope to grow without proportional review. Practitioners should shrink standing privilege around service accounts before credential compromise becomes account compromise.

Service account compromise becomes a repeatable control failure when breach intelligence is disconnected from AD governance. Credentials can be weak at creation and later become exposed through breach reuse, which means a one-time password check is not enough. The field should recognise this as a continuous credential-assurance problem across NHI lifecycle management. That makes continuous screening and revocation logic part of the control baseline, not an enhancement.

What this signals

Kerberoasting protection belongs in service identity governance, not only in password policy. The attack succeeds because a legitimate Kerberos exchange hides a credential-recovery problem, so teams need lifecycle ownership for every SPN-enabled account. Without clear ownership, long-lived service identities become a standing escalation path that no directory default will close.

Offline cracking changes the control boundary for Active Directory. Once a ticket is captured, live authentication controls no longer help, which means the real defensive boundary is the strength and uniqueness of the service secret itself. That makes service account review, rotation discipline, and privilege minimisation the controls that matter most.

Active Directory programmes should treat service accounts as high-risk NHIs. Their secrets are often older, broader in scope, and less monitored than human credentials, yet they can carry comparable or greater authority. The practical implication is to bring them into the same governance cadence as other privileged identities.

For practitioners

• Inventory every SPN-enabled account Build a complete list of service accounts with registered SPNs, then map each one to owner, business function, and privilege scope so no Kerberoast target sits outside governance.
• Raise password entropy for service accounts Enforce long, non-dictionary passwords on all SPN-enabled accounts and prohibit reuse across services so offline cracking becomes materially harder.
• Remove standing privilege from service identities Reassess whether each service account really needs elevated access, then reduce permissions to the minimum required for the service to run.
• Continuously screen service credentials against breach data Treat breached-password detection as an active control for AD service accounts, because a credential that was safe at creation can later become crackable through external exposure.
• Correlate Kerberos request anomalies with password events Feed password change failures, compromise detections, and unusual TGS-REQ patterns into your SIEM so Kerberoasting indicators are visible alongside directory telemetry.

Key takeaways

• Kerberoasting works because a legitimate Kerberos flow can expose crackable service credentials behind SPN-enabled accounts.
• The article ties the attack to the 2024 Ascension ransomware breach and shows how cracked service passwords become privilege escalation.
• The effective control is not ticket suppression but stronger service account governance, including password strength, breach screening, and privilege reduction.

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.
• Offline Cracking: Offline cracking is the process of testing password guesses against captured encrypted material without interacting with the live system. It matters because it avoids lockout and detection controls, making password strength and breach exposure the deciding factors in whether an attacker succeeds.
• 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.

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.