Topic starter
11/07/2026 8:21 pm
TL;DR: Kerberoasting abuses Kerberos service tickets in Active Directory by requesting SPN-based tickets, extracting the encrypted ticket material, and cracking weak service account passwords offline, a pattern Enzoic says is especially relevant after the 2024 Ascension ransomware breach. The real control problem is not ticket issuance itself but long-lived, crackable service credentials that turn normal authentication into privilege escalation.
Editorial analysis by NHI Mgmt Group, based on content published by Enzoic: “Kerberoasting Protection”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: Kerberoasting works because a legitimate Kerberos flow can expose crackable service credentials behind SPN-enabled accounts.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
11/07/2026 8:51 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Kerberoasting protection exposes the weak link in Active Directory