Kerberoasting exposes the service-account trust gap in Active Directory

At a glance

What this is: This is an analysis of Kerberoasting in Active Directory, showing how service-account exposure and weak internal trust let attackers move from a low-privilege account to higher-value access.

Why it matters: It matters because many identity programmes still treat service accounts as operational exceptions, when in practice they are governed identities that need stronger lifecycle, monitoring, and privilege controls.

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.

👉 Read IS Decisions' analysis of Kerberoasting in Active Directory

Context

Kerberoasting is a password and ticket abuse technique that targets Active Directory service accounts, which are non-human identities used to run applications and infrastructure services. The attack matters because it turns ordinary directory access into a path toward privileged application control, even when no domain controller is directly compromised.

The broader identity issue is not just cracking speed. Active Directory still reflects assumptions from a perimeter-era design, where internal access implied trust and service accounts were monitored less rigorously than human users. That creates a governance gap for NHI programmes, especially where service accounts outnumber the controls applied to them.

Key questions

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. When a privileged credential stays valid after the task ends, compromise of that credential gives attackers a ready-made path to sensitive systems, lateral movement, and administrative actions without a fresh approval step.

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

Technical breakdown

How Kerberoasting uses service tickets and offline cracking

Kerberoasting starts when an attacker with a low-privilege account enumerates service principal names, then requests a Kerberos service ticket for a target service account. Parts of that ticket are encrypted with the service account's password-derived key. The attacker then takes the ticket offline and cracks the hash without further interaction with the domain controller. Weak encryption, short passwords, and long-lived service account credentials all increase success rates. The core risk is that the authentication flow itself becomes a source of reusable credential material.

Practical implication: reduce exposure by removing user-managed service accounts and enforcing stronger, rotated credentials on machine identities.

Why Active Directory makes low-privilege enumeration so useful

Active Directory exposes enough directory metadata for a normal user to discover service accounts, group membership, and SPN attributes. That design is convenient for administration, but it also gives attackers a built-in reconnaissance surface from which they can identify high-value targets. Once an SPN is known, the attack does not require elevated rights to proceed. This is why Kerberoasting is less about brute force and more about structural visibility into identities that should be more tightly governed.

Practical implication: monitor LDAP queries and SPN enumeration as identity recon signals, not just as generic directory traffic.

Why service accounts become a privileged blind spot

Service accounts are machine identities, but many organisations still manage them like static utility accounts rather than governed credentials. They often lack MFA, receive weak password hygiene, and escape the monitoring applied to human identities. In practice, that means a compromised service account can provide persistent access to applications, data, and adjacent systems. Kerberoasting succeeds because the account's secret can be recovered without alerting the domain controller, then reused wherever that service identity has authority.

Practical implication: inventory service-account permissions and retire any account whose access cannot be justified by an owner, purpose, and rotation policy.

Threat narrative

Attacker objective: The objective is to recover a high-value service account secret and use that identity to gain control over privileged applications or downstream data.

1. Entry occurs when the attacker compromises a low-privilege user account and uses it to query Active Directory for service principal names.
2. Escalation occurs when the attacker requests a service ticket for a targeted service account and extracts a crackable hash from the ticket material.
3. Impact occurs when the cracked service account password is reused to control an application or access the data and systems that identity governs.

Breaches seen in the wild

• MITRE ATT&CK Enterprise Matrix — MITRE ATT&CK Enterprise — adversary tactics and techniques, threat detection, attack chain mapping, credential access, lateral movement, privilege escalation.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

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

Standing service-account privilege is the real exposure window. Kerberoasting only becomes valuable when a service account remains usable long enough for an attacker to harvest, crack, and reuse its secret. That is the same structural failure seen across NHI sprawl: access persists longer than operational need, while the organisation assumes internal identities are inherently safe. Practitioners should treat every long-lived service account as a residual trust object that expands blast radius.

Identity blast radius is the right concept for Kerberoasting defence. The attack shows that one compromised user account can unlock a much larger privilege domain if service accounts are over-granted or poorly segmented. This is why least privilege has to be measured at the account and application boundary, not just at the user layer. Teams should map which service identities can reach critical applications and treat those paths as attack surfaces.

Kerberoasting exposes the limits of human-oriented monitoring for machine identities. Many programmes watch for suspicious human logons but do not baseline SPN discovery, service-ticket requests, or service-account password strength with equal rigour. That creates a blind spot where the attack can proceed through normal directory behaviour. The implication is clear: NHI governance must include machine-account telemetry, not only user-facing controls.

Strong passwords alone do not close the governance gap. The article correctly notes that RC4_HMAC makes offline cracking easier and AES strengthens the target, but the underlying issue is that the identity remains crackable at all if it is long-lived, overexposed, and weakly monitored. Encryption choice matters, but governance over service-account purpose, duration, and rotation matters more. Practitioners should treat cryptography as a limiter, not a substitute for lifecycle control.

From our research:

• 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.
• For a broader breach lens, see 52 NHI Breaches Analysis for recurring patterns in compromised machine identities and access reuse.

What this signals

Identity teams should treat service-account exposure as an incident, not a housekeeping task. Kerberoasting shows that attackers can turn directory visibility into offline credential recovery with very little noise, so the response model has to assume rapid exploitation rather than leisurely follow-up. The operational signal is whether SPN-bearing identities are owned, monitored, and rotated on a schedule that reflects real attack tempo.

Service-account governance needs to converge with workload identity management. Once machine identities are given application reach, their secrets and privileges need the same review discipline applied to other high-value access paths. Programmes that cannot answer which service identities can reach critical systems are carrying hidden blast radius.

As part of that shift, the Ultimate Guide to NHIs , Key Challenges and Risks is the right reference point for building a service-account inventory and removal plan. The practical change is not more tooling alone, but a programme that can see, own, and retire machine identities before they become attack paths.

For practitioners

• Inventory all service accounts and SPN-bearing identities Build a complete list of service accounts, SPNs, owners, and application dependencies. If an identity has no named business owner or no clear runtime purpose, treat it as an offboarding candidate rather than a tolerated exception.
• 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. Prioritise application accounts that have broad reach or long password ages.
• 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. Baseline normal query patterns first, then investigate deviations as reconnaissance signals.
• Reduce the blast radius of service identities Segment high-value applications so no single service account can reach unrelated systems. Pair that with access review of service-account entitlements and removal of domain-admin style privileges unless they are explicitly justified.

Key takeaways

• Kerberoasting succeeds because service accounts are treated as routine infrastructure objects instead of governed identities with clear ownership and lifecycle controls.
• The attack can move from low-privilege access to privileged application control without touching the domain controller again, which makes detection and containment harder.
• Reducing Kerberoasting risk requires visibility into SPNs, stronger service-account management, and a smaller blast radius for machine identities.

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.
• Service Principal Name Collision: A condition where two objects contend for the same SPN or a confusable variant of it. Because Kerberos relies on SPNs to resolve which account owns a service key, a collision can misdirect tickets, break service access, or enable privilege escalation if write rights are too broad.
• Group Managed Service Account: A Group Managed Service Account is a Windows-managed service identity designed to reduce manual password handling. It automatically rotates complex credentials and is intended for applications and services that need non-human access with less exposure than a traditional service account.
• 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.

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.

👉 The full IS Decisions article covers the attack chain, detection challenges, and hardening options in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.