Subscribe to the Non-Human & AI Identity Journal

Notifications
Clear all

Kerberoasting in Active Directory: what IAM teams need to fix


(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 11631
Topic starter  

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.

NHIMG editorial — based on content published by Enzoic: Kerberoasting Protection Active Directory Continuous Password Protection

Questions worth separating out

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.

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.

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.

Practitioner guidance

  • 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.
  • 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.
  • Reduce standing privilege on service identities Review what each service account can access, then remove rights that are not essential for runtime operation.

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

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

Kerberoasting in Active Directory: what IAM teams need to fix?

Explore further

View Full Forum →  |  NHI Foundation Course →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 2 months ago
Posts: 11186
 

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.

A few things that frame the scale:

  • 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.

A question worth separating out:

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.

👉 Read our full editorial: Kerberoasting protection exposes the weak link in Active Directory



   
ReplyQuote
Share: