Ghost SPN identity attacks expose the limits of event-only SIEM

At a glance

What this is: This is an analysis of a Ghost SPN identity attack and the finding that traditional SIEM misses it when alerts are not correlated into an attack narrative.

Why it matters: It matters because identity abuse in Windows environments can hide inside routine-looking events, which means IAM, PAM, and SOC teams need correlated identity context, not isolated logs.

By the numbers:

• The entire attack chain can occur in as little as 11 minutes.
• Organizations using Gurucul AI SOC capabilities typically see 90%+ reduction in alert noise.

👉 Read Gurucul's analysis of the Ghost SPN attack and identity-driven detection

Context

Ghost SPN attacks abuse the service principal name lifecycle in a Windows domain so an attacker can request Kerberos tickets, remove the evidence, and then reuse the resulting credentials for lateral movement. The governance problem is not just detection volume, but whether identity controls can preserve context long enough to prove abuse after the fact.

For IAM, PAM, and SOC teams, the deeper issue is that standard event logging treats identity changes as isolated admin actions rather than as part of a privilege sequence. That makes attack reconstruction depend on correlation across Active Directory, Kerberos, authentication, and network telemetry, not on any single alert stream.

Key questions

Q: What breaks when SPN abuse is not correlated with Kerberos and login activity?

A: A single SPN change can look harmless, and a Kerberos ticket request can look routine, but together they may show credential extraction and privilege escalation. Without correlation, defenders see isolated admin noise instead of an attack story. The result is delayed response, missed containment, and a false sense of safety from green dashboards.

Q: Why do temporary identity changes create such a large detection gap in Windows environments?

A: Temporary changes compress the evidence window. If an attacker adds an SPN, requests a ticket, removes the SPN, and then logs in with the derived credentials in minutes, the original change may be gone before a human analyst reviews it. That is why timing, not just content, is central to detection.

Q: How do security teams know whether SPN modifications are actually working as a control?

A: Look for whether SPN changes are rare, authorised, and traceable to a documented service need. If changes routinely occur on user accounts, if approvals are missing, or if the same identity is modified and cleaned up quickly, the control is not working. Effective governance should leave a durable audit trail and a clear business rationale.

Q: Who is accountable when privileged access is created and removed too quickly to review?

A: Accountability sits with both the identity owners and the teams that control directory change rights. If delegation allows SPN manipulation without clear approval, then governance has failed even before the alert fires. Frameworks such as the NIST Cybersecurity Framework 2.0 expect identifiable ownership, traceability, and timely response, not after-the-fact confusion.

Technical breakdown

SPN abuse as a Kerberos credential extraction path

A Service Principal Name links a service account to Kerberos authentication, which allows clients to request a service ticket. In a Ghost SPN attack, an attacker temporarily assigns an SPN to an ordinary user account, requests a ticket, and then removes the SPN so the activity looks like routine directory administration. The key mechanism is that Kerberos ticket requests can be made against the modified account even after the SPN is removed, which helps hide the abuse from simple rule-based detection. This is why the technique is often called stealth Kerberoasting.

Practical implication: monitor SPN creation, reassignment, and removal as one lifecycle, not as separate directory events.

Why isolated SIEM alerts fail to reconstruct identity attacks

Traditional SIEMs usually treat Event 5136, 4769, and 4624 as unrelated signals. That model misses the identity chain because each event is individually plausible: a directory change can look administrative, a Kerberos ticket request can look normal, and a login can look authenticated. Without correlation across the same account, ticketing activity, and subsequent privilege changes, the system cannot distinguish a legitimate admin action from a short-lived credential extraction path. The failure is architectural: the alert model is event-centric while the attack is entity-centric.

Practical implication: correlate directory, Kerberos, and login telemetry at the entity level before triage.

Why anti-forensics makes timing part of the detection problem

The attack's speed matters because the evidence window is intentionally short. If an SPN can be added and removed within minutes, then detection based on later review is already too late. This compresses the time available for human analysis and makes noise reduction, enrichment, and automated incident summary more valuable than a long list of alerts. The operational lesson is that the SOC needs a narrative engine that can preserve sequence, not just a queue of events.

Practical implication: retain sequence context and enrich rapid add-remove patterns before analysts lose the evidence window.

Threat narrative

Attacker objective: The attacker wants short-lived credential exposure that turns into domain-level control before the security team can reconstruct the sequence.

1. Entry occurs when an attacker assigns an SPN to a non-service user account so Kerberos will issue a ticket against the modified identity.
2. Credential access follows when the attacker requests a Kerberos service ticket, then removes the SPN to hide the modification and support offline cracking.
3. Escalation and impact occur when the stolen credentials are used for a successful external login, followed by privilege escalation to Domain Admins and broader lateral movement.

Breaches seen in the wild

• Cisco Active Directory credentials breach — Kraken ransomware group leaked Cisco Active Directory credentials.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Event-only alerting is a broken assumption for identity attacks that compress into minutes. The SIEM model assumes the security team will see enough separate signals to reconstruct abuse after the fact. Ghost SPN breaks that premise because the identity state can be created, abused, and erased before the analyst has context. The implication is that identity programmes must value sequence preservation over isolated alert volume.

Identity context, not raw alert count, is the control gap this attack exploits. An SPN change, a Kerberos ticket request, and a login are each defensible on their own. What fails is the assumption that administrative-looking changes remain interpretable once the account has been cleaned up. Practitioners should treat cross-domain correlation as a core identity control, not a SOC convenience.

Ghost SPN is a named example of identity blast radius compression. A short-lived SPN assignment can expand into ticket issuance, credential reuse, and domain admin escalation in a single chain. That compresses exposure into a window smaller than most manual review cycles and makes standing detection boundaries less useful. Teams need to understand how quickly a local directory change can become enterprise-wide control loss.

SPN lifecycle governance was designed for visible, slower-moving service administration. That assumption fails when an attacker can create and delete the SPN within minutes because the lifecycle is no longer governed by administrators, but by an adversary seeking forensic disappearance. The implication is that review cadences built for stable service identities do not map cleanly to adversarial SPN manipulation.

Attack reconstruction has become an identity governance function, not just an SOC function. When the platform can automatically summarize what happened, it is doing more than triage; it is preserving the identity story that would otherwise be lost between teams. Practitioners should treat that capability as part of governance evidence, especially where service account misuse can escalate into directory-wide compromise.

From our research:

• The entire attack chain can occur in as little as 11 minutes, according to Ultimate Guide to NHIs.
• Another finding from our research shows that 97% of NHIs carry excessive privileges, which broadens the attack surface when identity compromise lands.
• That is why Top 10 NHI Issues is the right next resource for teams mapping privilege and lifecycle control gaps.

What this signals

Ghost SPN-style attacks show why identity observability has to move from event review to sequence review. Teams that still depend on isolated logs will keep mistaking clean-up activity for benign administration, especially where the account lifecycle is shorter than the analyst's review window. The practical shift is to treat directory change history, Kerberos telemetry, and login context as one governance surface, not separate tools.

A useful named concept here is identity blast radius compression: a brief identity change can expand into domain-wide control faster than traditional investigation cycles can react. That has direct implications for PAM, Active Directory governance, and SOC playbooks because review windows that assume stable privilege are already too slow. The reader's programme should measure whether it can preserve attack sequence before forensic context disappears.

With the Ultimate Guide to NHIs, NHI Mgmt Group has long argued that visibility is the prerequisite for lifecycle governance, and this case shows why that is true in practice. When attackers can hide inside ordinary identity operations, the programme needs stronger identity telemetry and stricter delegation boundaries, not more alert volume.

For practitioners

• Correlate SPN lifecycle events as one control stream Join Event 5136 changes with Kerberos ticket activity and downstream logons for the same account so a rapid add-remove pattern becomes a single investigative object.
• Flag non-service accounts that receive temporary SPNs Create detection logic for SPNs assigned to user accounts or identities that are not expected to host services, then review every exception for authorization and purpose.
• Tighten delegated rights that can modify SPNs Audit WriteSPN, GenericAll, and related Active Directory delegation paths so only explicitly approved administrators can alter service principal mappings.
• Review Kerberos encryption choices for service accounts Prioritise accounts still using weak RC4 where stronger Kerberos configurations are possible, because ticket weakness increases the value of a successful SPN abuse path.
• Build incident summaries that preserve attack sequence Require AI-assisted or analyst-authored summaries to show what happened, in what order, and which identity objects changed so cleanup activity does not erase the story.

Key takeaways

• Ghost SPN attacks exploit the gap between routine-looking directory events and the real identity story behind them.
• An 11-minute attack chain is short enough to outrun manual triage, which is why correlation matters more than alert volume.
• Teams that control SPN changes, Kerberos telemetry, and delegation rights together are better positioned to stop credential extraction before domain escalation.

Key terms

• Ghost SPN attack: A Ghost SPN attack is a stealthy Kerberos abuse technique where an attacker temporarily assigns a Service Principal Name to an account, requests a service ticket, and removes the SPN to hide evidence. The goal is credential extraction and later privilege escalation without leaving a durable administrative trail.
• Service Principal Name: A Service Principal Name is an Active Directory attribute that maps a service instance to an identity for Kerberos authentication. In attack paths, it becomes a high-value control point because changing it can redirect ticket issuance and create a short-lived path to credential abuse.
• Identity blast radius: Identity blast radius is the amount of access and operational reach that a compromised identity can unlock before defenders contain it. For service identities and delegated admin paths, it often expands faster than teams expect because one credential or change can cascade into multiple systems and privileges.
• Attack reconstruction: Attack reconstruction is the process of turning separate security events into a single, ordered story of entry, escalation, and impact. It is essential when identity abuse is short-lived, because the forensic value comes from sequence and context, not from any one alert.

What's in the full article

Gurucul's full blog covers the operational detail this post intentionally leaves for the source:

• The incident timeline and screenshots showing how the AI-driven summary reconstructs the Ghost SPN attack.
• The specific alert compression and triage workflow used to turn fragmented telemetry into one incident view.
• The recommended analyst playbook for validating the SPN modification, reviewing delegated rights, and checking for lateral movement.
• The comparison table that quantifies noise reduction, MTTD impact, and analyst workload changes.

👉 Gurucul's full post covers the attack timeline, AI incident summary, and guided response steps.

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 identity security capability, it is worth exploring.