Notifications
Clear all
Topic starter
11/08/2026 3:17 pm
TL;DR: Kerberoasting lets a low-privilege user request a service ticket, extract a service account hash, and crack it offline, with attackers often beginning within minutes of exposure according to Entro Security and GitGuardian/CyberArk research. The deeper problem is that Active Directory still assumes internal trust and reviewable access, assumptions that fail under modern credential abuse.
NHIMG editorial — based on content published by IS Decisions: Kerberoasting and Active Directory's attack surface
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: What breaks when standing privilege is not removed for privileged users and service accounts?
A: Standing privilege breaks the assumption that access is only available when needed.
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 all service accounts and SPN-bearing identities Build a complete list of service accounts, SPNs, owners, and application dependencies.
- Replace user-managed service accounts with Group Managed Service Accounts Use Group Managed Service Accounts where the platform supports them so passwords rotate automatically and human handling is removed from the credential lifecycle.
- Monitor SPN enumeration and unusual ticket requests Add alerts for LDAP queries that list SPNs, spikes in service-ticket requests, and repeated access to high-value service identities.
What's in the full article
IS Decisions' full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step Kerberoasting detection and hardening guidance for Active Directory environments.
- Detailed explanation of how LDAP queries, SPNs, and TGS ticket requests are used in the attack chain.
- Comparative discussion of ticket encryption strength, including RC4_HMAC versus AES-128 and AES-256.
- Architecture considerations for monitoring without inserting new failure points into the Kerberos flow.
👉 Read IS Decisions' analysis of Kerberoasting in Active Directory →
Kerberoasting in Active Directory: what should IAM teams change now?
Explore further
11/08/2026 3:29 pm
Kerberoasting is a non-human identity governance failure, not just a password problem. The attack works because service accounts are treated as background utilities rather than governed identities with lifecycle ownership, monitoring, and revocation discipline. That is an NHI programme gap, not merely a directory hardening issue. Organisations that do not classify service accounts as first-class identities will keep missing the control point that matters: who owns the secret, who rotates it, and who can still use it.
A few things that frame the scale:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
- Attackers are not waiting for normal remediation windows, which is why secrets exposure has to be treated as an immediate identity event rather than a routine hygiene issue.
A question worth separating out:
Q: Who should own Kerberoasting risk in an identity programme?
A: Ownership should sit with IAM, directory administrators, and application owners together, because the attack spans account lifecycle, authentication, and workload dependency. Security teams need a named owner for each service identity, a clear decommissioning path, and an agreed review cadence for privilege and encryption settings. Without that accountability, service-account risk stays invisible.
👉 Read our full editorial: Kerberoasting exposes the service-account trust gap in Active Directory
