Look for an SPN added to an account that should not host one, followed quickly by Kerberos ticket requests, an SPN removal, and then unusual logon or privileged group activity. The key indicator is the tight sequence, especially when the account is not a normal service identity.
How to read the sequence behind a Ghost SPN attack
The key is not just that an SPN appears, but that it appears on an account that should not normally host one, then vanishes after ticket activity begins. That pattern suggests the attacker is using the SPN as a short-lived foothold to obtain Kerberos service tickets, then cleaning up to reduce visibility. The most useful clue is the timing between those events.
In practice, defenders should treat this as a behavioural chain, not a single alert. A legitimate service account usually shows a stable SPN pattern, predictable ticketing, and consistent follow-on logon activity. A ghost spn sequence is suspicious because it compresses setup, abuse, and removal into a narrow window, often before the wider account activity becomes obvious.
Related service-account and SPN handling patterns are covered in the Service Account Security Guide, which is useful when you need to compare normal service identity behaviour with abuse patterns.
What telemetry usually exposes the attack path
The strongest evidence comes from combining directory changes, Kerberos events, and account-use anomalies. Look for the account modification that adds the SPN, followed by ticket requests for that SPN, then the removal of the SPN, and finally logon activity or privilege changes that do not match the account’s normal purpose. The value is in correlation across these steps, not in any one event in isolation.
Do not stop at the directory object alone. A Ghost SPN attack often becomes visible only when you line up the SPN lifecycle with authentication and privilege activity. If the account is a user or admin account rather than a service identity, the signal becomes stronger because the behaviour no longer fits the expected access pattern for that principal.
For broader breach-pattern context across service accounts and credential abuse, The State of NHI & AI Agent Breach Report 2026 is a useful companion when you are comparing how attackers turn short-lived identity misuse into lateral movement.
External threat reporting also helps validate the wider attack chain, especially when you are mapping attacker behaviour to MITRE ATT&CK Enterprise techniques such as credential access and lateral movement.
What separates suspicious SPN activity from normal administration
Normal administration usually leaves a broader operational footprint: planned change tickets, repeatable service account ownership, and steady logon behaviour that matches the application or service. A Ghost SPN attack is different because the SPN is introduced briefly, used quickly, and removed before the account’s purpose can be challenged. That makes the change history itself part of the signal.
Another practical distinction is privilege drift. If SPN activity is followed by privileged group membership changes, unusual directory queries, or logons from unexpected hosts, the account has likely been repurposed for access rather than service delivery. That is especially important when the account should not have been interactive at all.
When you want a control baseline for identity and access monitoring around this pattern, the NIST SP 800-53 Rev 5 Security and Privacy Controls catalog provides the most directly relevant audit, authentication, access control, and configuration controls.
Risk and Threat Considerations
Ghost SPN activity is risky because it can convert an ordinary account into a temporary Kerberos abuse path, then remove the obvious configuration evidence after use. That creates a detection gap: the account may look ordinary again by the time analysts review it, even though the ticketing and privilege trail already show misuse.
Failure mechanism: The attacker adds an SPN to an account that should not host one, requests tickets or otherwise leverages that Kerberos service identity, then removes the SPN to reduce traceability while keeping any gained access or follow-on privilege.
Impact: This can enable stealthy authentication abuse, lateral movement, and privilege escalation, particularly where monitoring is not correlating directory changes with Kerberos activity and account-use anomalies.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1558 — Steal or Forge Kerberos Tickets | Ghost SPN abuse centers on Kerberos ticket acquisition and misuse. |
| Recommendation — Map the sequence to Kerberos ticket abuse and hunt for correlated directory changes. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Detection depends on correlating SPN changes with ticketing and logon activity. |
| IA-5 — Authenticator Management | The attack abuses credentialed access paths tied to service identity behavior. | |
| AC-6 — Least Privilege | Accounts that should not host SPNs or gain privilege need constrained access. | |
| Recommendation — Correlate directory, Kerberos, and logon logs to flag short-lived SPN abuse. Enforce strict credential handling and rotation for service-capable accounts. Remove unnecessary privileges and prevent non-service accounts from hosting SPNs. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | The pattern often exploits excessive permissions on an account that should be limited. |
| NHI-01 — Improper Offboarding | The SPN is removed after use, making lifecycle control and cleanup central to the abuse pattern. | |
| NHI-07 — Long-Lived Secrets | Persistent service-account material often enables the Kerberos abuse path behind SPN misuse. | |
| Recommendation — Review service-capable accounts for excessive privilege and restrict SPN assignment. Track identity lifecycle changes and alert on rapid SPN creation and removal. Reduce secret lifetime and rotate credentials tied to service-capable accounts. | ||
Practitioner Guidance
What to verify: Confirm whether the SPN addition, ticket requests, and SPN removal occurred within a narrow time window on the same account. If the account is not a known service principal, treat the sequence as a security event even if the SPN is already gone.
What to prioritise: Correlate directory modification logs with Kerberos and logon telemetry first, then assess whether the account had any legitimate service ownership, delegated administration, or recent change approval. That ordering matters because the attack often disappears from the directory faster than it disappears from authentication logs.
Common mistake: Investigating the SPN change in isolation and closing the alert once the SPN is removed. The removal is often part of the tradecraft, not evidence that the event was harmless.
Practitioner takeaway: The best signal is a short-lived SPN lifecycle on an account that does not normally host services, especially when ticketing and privilege activity immediately follow.
Related resources from NHI Mgmt Group
- What are the signs that an identity attack is underway even when there is no obvious service outage?
- What are the signs that a deepfake attack is underway during customer verification?
- What are the signs that a credential stuffing attack is underway in identity provider logs?
- What are the signs that a model denial of service attack is underway?