Kerberoasting protection exposes the weak link in Active Directory

At a glance

What this is: This is an analysis of Kerberoasting in Active Directory, showing how attackers turn ordinary service ticket requests into offline password cracking and privileged account takeover.

Why it matters: It matters because service accounts are often over-privileged, long-lived, and weakly governed, which makes them a direct bridge between human IAM failures and NHI exposure.

By the numbers:

• Kerberoasting has been reported in many cyberattacks, including one of the largest healthcare data exposures of all time, the 2024 Ascension ransomware breach.

👉 Read Enzoic's analysis of Kerberoasting protection in Active Directory

Context

Kerberoasting is a service account abuse pattern in Active Directory where a valid domain user requests a ticket for a service principal name and then attempts to crack the ticket offline. The control gap is familiar to IAM teams: if the account behind the SPN has a weak or breached password, the attacker can turn standard Kerberos behaviour into credential theft.

For identity programmes, the lesson is that NHI governance cannot stop at human logins and MFA. Service accounts, especially those with privileged access, need the same discipline around password strength, exposure monitoring, and lifecycle control that teams already expect for high-risk human access, and the article's starting point is typical rather than exceptional.

Enzoic frames the issue around Active Directory password protection and continuous screening, but the deeper problem is the persistence of credentials that remain valid long enough to be targeted, cracked, and reused. That makes Kerberoasting a governance issue as much as a detection issue, especially where service accounts sit outside normal review cycles.

Key questions

Q: What breaks when service account passwords are weak in Active Directory?

A: Weak service account passwords turn Kerberos ticket requests into an offline cracking opportunity. An attacker can request a ticket using a normal domain user, extract the encrypted material, and brute-force the password outside Active Directory. If the secret is crackable, the attacker inherits the service account's privileges and can move laterally or access sensitive services.

Q: Why do service accounts increase Kerberoasting risk?

A: Service accounts are often long-lived, discoverable through SPNs, and more privileged than ordinary user accounts. That combination gives an attacker a legitimate ticket path plus a valuable identity to recover. Kerberoasting is dangerous because the abused account already carries business access, so compromise of the password becomes compromise of the entitlement set.

Q: How do security teams know whether SPN-enabled accounts are actually protected?

A: They know protection is working when SPN-enabled accounts are inventoried, owned, screened for breached passwords, and recertified on a regular schedule. A healthy programme also shows reduced privilege on service identities and visible alerts when a password is rejected or exposed. If none of those signals exist, the account is probably still a Kerberoasting target.

Q: Who is accountable when a cracked service account is used for lateral movement?

A: Accountability sits with the team that owns the service identity and the directory controls around it, not with Kerberos itself. The organisation should be able to name the owner, the approver of the privilege set, and the process that would have rotated or disabled the account after exposure. That is the control boundary auditors will examine.

Technical breakdown

SPN enumeration and ticket requests in Kerberos

Kerberoasting begins with an attacker enumerating service principal names, then using an ordinary domain user context to request a service ticket from the Key Distribution Center. This is not exploit code in the traditional sense. It is abuse of a legitimate protocol path. Because the request looks normal, the attacker can harvest targets without triggering obvious authentication failure signals. The service account behind the SPN becomes the real asset at risk, not the requesting user account. The technical weakness is that access to the ticketing mechanism is available to any authenticated user, while the security of the target hinges on password quality and account governance.

Practical implication: restrict high-value SPNs and review which service accounts can be discovered and requested by low-privilege users.

Offline cracking of ticket material and password strength

The returned TGS-REP contains material encrypted with a key derived from the service account password hash. The attacker moves that blob offline, where cracking tools can try dictionary or brute-force guesses without further interaction with Active Directory. This makes password entropy the decisive control point. Long, unique, uncompromised passwords raise the cost of cracking to the point where the attacker loses the window of opportunity. The protocol itself is not broken in the abstract. The abuse works because a reusable secret backs the service identity and remains stable long enough to be extracted and attacked offline.

Practical implication: enforce strong service account password policy and block known-breached credentials before they are committed to AD.

Privilege escalation through service account reuse

Once the password is recovered, the attacker can authenticate as the service account and inherit whatever access that identity holds. In many environments that means application access, directory rights, or lateral movement paths that were never intended for ordinary users. This is where Kerberoasting becomes more than credential theft. It becomes an access governance failure, because the account's privileges outlive the moment they were provisioned and can be repurposed by an attacker. Monitoring only ticket requests misses the real danger, which is the downstream abuse of an over-privileged, under-reviewed identity.

Practical implication: recertify SPN-enabled accounts and reduce their privilege scope to the minimum required for service operation.

Threat narrative

Attacker objective: The attacker wants a cracked service account credential that can be reused to take control of privileged services inside Active Directory.

1. Entry begins when an authenticated domain user enumerates SPNs and requests a Kerberos service ticket for a target service account.
2. Credential access follows when the attacker extracts the encrypted ticket material and cracks the service account password offline.
3. Escalation and impact occur when the recovered credentials are used to log in as the service account and reuse its privileges for lateral movement or sensitive service access.

Breaches seen in the wild

• Cisco Active Directory credentials breach — Kraken ransomware group leaked Cisco Active Directory credentials.
• MITRE ATT&CK Enterprise Matrix — MITRE ATT&CK Enterprise — adversary tactics and techniques, threat detection, attack chain mapping, credential access, lateral movement, privilege escalation.

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 really a service-account governance failure, not just a password-strength problem. The attack succeeds because a legitimate Kerberos flow exposes an offline cracking opportunity, but the underlying issue is that the service identity is both discoverable and reusable. That makes OWASP-NHI style credential governance relevant even in a classic Active Directory environment. Practitioners should treat exposed service account passwords as an identity lifecycle problem, not a one-off hardening issue.

Standing service-account privilege creates the attacker's real margin. Once the password is recovered, the attacker does not need to improvise. They inherit whatever access the account already holds, which is why recertification and privilege scoping matter as much as password policy. NIST CSF access control and NIST SP 800-53 IA-5 both align to the same operational reality: the credential is only one half of the risk, the entitlement set is the other half. Practitioners should audit privilege attached to every SPN-enabled identity.

Long-lived service credentials create what we would call credential durability debt. The longer a service account remains valid, the more time an attacker has to request tickets, crack the hash, and reuse the identity. That debt accumulates when accounts are exempt from normal review, rotation, or breach screening. The implication is simple: identity programmes must measure how long a high-value secret remains usable, not just whether it meets baseline complexity policy.

Continuous breach screening changes the economics, but it does not replace governance. Real-time password vetting can reduce the chance that a known-bad secret enters Active Directory, and continuous monitoring can catch compromised credentials later. But those controls only work when the organisation already knows which service accounts matter and who owns them. The practitioner conclusion is to pair secret hygiene with clear accountability for every NHI that can be queried through Kerberos.

Kerberoasting shows why human IAM controls do not fully cover machine identities. Password policy, login governance, and audit logging still matter, but they do not solve the structural problem of service identities that are invisible to most review cycles. NHI governance must therefore extend into Active Directory, because the attack surface sits at the intersection of human-authenticated access and machine-used privileges. Practitioners should stop treating service accounts as background plumbing.

From our research:

• DeepSeek accidentally embedded over 11,000 secrets in its training data and left a database exposed online, revealing more than one million sensitive records including chat histories, backend credentials, and API keys, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.
• For a broader control map, see The 52 NHI breaches Report for recurring credential abuse patterns across real incidents.

What this signals

Credential durability debt: service identities that keep the same password for too long create a standing opportunity for offline cracking, reuse, and privilege escalation. The programme signal to watch is not only password age but also whether SPN-enabled accounts are owned, reviewed, and screened like other high-risk identities.

The next maturity step is to connect directory controls, SIEM, and breach-intelligence screening into one operational loop. When a service account password is rejected, reused, or exposed, the response should be measurable in resets, privilege reduction, or disablement rather than in isolated alerts.

For practitioners

• Inventory every SPN-enabled account Build a complete list of service accounts with registered SPNs, then map each one to an owner, business function, and privilege set. Without a current inventory, Kerberoasting risk stays hidden inside normal directory operations.
• Eliminate weak and breached service passwords Apply length, complexity, and breached-password screening to service account resets and changes, and block passwords that appear in compromise datasets before they are accepted into Active Directory. The key control is preventing crackable secrets from ever existing.
• Reduce standing privilege on service identities Review what each service account can access, then remove rights that are not essential for runtime operation. Service accounts that can reach sensitive data, admin functions, or broad directory scopes should be reclassified as high-risk identities.
• Add continuous exposure monitoring to Kerberos accounts Track service credentials for breach reappearance, password reuse, and unexpected authentication activity, then route alerts into SIEM workflows. Use the monitoring data to drive resets or disablement before offline cracking can finish.

Key takeaways

• Kerberoasting turns legitimate Kerberos ticket requests into offline password cracking against service accounts.
• The scale of the problem is not theoretical, with the article tying Kerberoasting to the 2024 Ascension ransomware breach.
• The most effective limiters are strong service-account passwords, reduced standing privilege, and continuous monitoring for exposed credentials.

Key terms

• Kerberoasting: Kerberoasting is an Active Directory attack that requests Kerberos service tickets for SPN-enabled accounts and then cracks the encrypted ticket material offline. The goal is to recover the service account password and reuse its privileges without needing to exploit software vulnerability.
• Service Principal Name: A Service Principal Name is the Kerberos identifier tied to a service account that allows clients to request tickets for a specific service. In practice, SPNs make service identities discoverable, which is useful for access but also creates a target list for attackers.
• 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 service account is a non-human identity used by applications, servers, or background processes to authenticate and access resources. These accounts often outlive the systems that created them, so governance depends on ownership, privilege review, and password hygiene rather than user-oriented controls.

What's in the full article

Enzoic's full post covers the operational detail this analysis intentionally leaves for the source:

• Password filter behaviour on domain controllers and how it intercepts resets in real time
• Continuous breach monitoring workflow for AD credentials and the response actions it can trigger
• SIEM event types such as PasswordChangeRejected and CompromiseDetected, plus how they are logged
• Operational examples of enforcing service-account password policy across OUs and user groups

👉 The full Enzoic post covers ticket flow, password screening, and SIEM integration details.

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.