SPN-jacking is an Active Directory abuse technique where an attacker temporarily changes a Service Principal Name to redirect Kerberos delegation to a different account. It can bypass normal delegation restrictions when WriteSPN rights exist, allowing the attacker to obtain usable service tickets without changing the underlying delegation configuration.
How SPN-jacking works
SPN-jacking is a Kerberos abuse path in Active Directory where an attacker temporarily changes a Service Principal Name so tickets are issued for a different security principal. The technique relies on write access to the SPN attribute and does not require the attacker to reconfigure delegation itself.
The key idea is that Kerberos service tickets are bound to the SPN value, so a temporary swap can redirect where the domain controller thinks the service lives. That makes the technique useful for abusing delegation flows, especially where normal delegation restrictions would otherwise block direct ticketing paths.
Why it bypasses normal delegation boundaries
SPN-jacking matters because the control being changed is not the delegation setting itself, but the service name used by Kerberos to resolve the target. In practice, that can let an attacker obtain usable service tickets for a different account while leaving the underlying delegation configuration untouched.
This is what makes the technique deceptive to defenders. A quick review of delegation policy may look clean, while the attack actually succeeds through a temporary directory-object change that alters service resolution at ticket issuance time.
The abuse is also highly dependent on directory permissions. If an actor can write the SPN on a target object, they may be able to influence which identity receives delegated access in a way that is difficult to spot in routine delegation reviews.
Where attackers use it in an Active Directory attack chain
SPN-jacking is usually valuable as a privilege and ticket-manipulation step inside a broader Active Directory compromise. It can help an attacker turn limited directory write rights into delegated service access, then move toward lateral movement, impersonation, or access to protected service flows.
It is related to other Kerberos and directory abuse patterns because the attacker is exploiting trust in name-to-service binding. The important security property is not the SPN field itself, but the fact that Kerberos authorization decisions depend on it.
For defenders, that means SPN changes should be treated as security-significant directory events, not just routine administration. A temporary change can have lasting investigative value even if the attribute is later restored.
Detection and defensive priorities
SPN-jacking is easiest to abuse where directory permissions are overly broad, SPN ownership is unclear, and change monitoring is weak. The safest posture is to treat write access to SPNs as a sensitive administrative capability and monitor for unexpected attribute changes on service accounts and computer objects.
Reviewing delegation settings alone is not enough. Defenders also need visibility into who can modify SPNs, which accounts are eligible for service ticketing changes, and whether the change history matches approved administration.
Well-tuned monitoring should look for short-lived SPN edits, unusual service-ticket requests, and directory changes that do not align with service deployment or maintenance activity. Those signals are often what separate legitimate administration from abuse.
Risk and Threat Considerations
SPN-jacking creates a direct access-control risk because a temporary SPN change can redirect Kerberos delegation without changing the visible delegation policy. That makes it attractive for attackers who already have directory write rights and want to convert them into ticket-based access or lateral movement.
Failure mechanism: An attacker abuses write access to the SPN attribute, causes Kerberos to issue tickets for an unintended target, and then restores the original value to reduce detection.
Impact: The result can be unauthorized service access, delegated privilege misuse, and a misleading security posture where normal delegation reviews fail to reveal the abuse path.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1098 — Account Manipulation | SPN-jacking manipulates directory account attributes to redirect Kerberos service access. |
| Recommendation — Monitor and alert on suspicious service-account attribute changes that redirect authentication or delegation. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | SPN write access is the enabling privilege that must be restricted to reduce abuse. |
| AU-2 — Event Logging | SPN changes and ticket-relevant directory events need auditability to support detection and forensics. | |
| AC-2 — Account Management | Service accounts and their attribute ownership must be governed to prevent unauthorized SPN changes. | |
| Recommendation — Restrict SPN write permissions to only the administrators who truly need them. Log SPN modifications and correlate them with service-ticket activity for investigation. Review ownership and lifecycle controls for service accounts that can carry SPNs. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account and service-object governance directly reduces risky directory write access. |
| Recommendation — Inventory and control privileged service accounts that can change SPNs. | ||
| NIST CSF 2.0 | PR.AA-05 — Manage Access Permissions | The technique succeeds when SPN write permissions are too broad. |
| DE.CM-01 — Monitoring for Security Events | Unexpected SPN edits are security events that merit continuous monitoring. | |
| RS.AN-01 — Investigation Analysis | SPN-jacking investigations require correlating attribute changes with ticket issuance and access behavior. | |
| Recommendation — Enforce and review permissions for objects that control Kerberos service resolution. Continuously monitor directory changes that affect service names and delegation paths. Correlate SPN edits with Kerberos activity to confirm or rule out abuse. | ||
Practitioner Guidance
What to watch for: Focus on SPN write permissions as a privileged control surface. If multiple teams can modify service-object attributes, clarify ownership and review whether those rights are truly required.
Governance implication: Treat SPN changes as auditable security events with change-management expectations, especially for high-value service accounts and delegation-sensitive workloads. That makes it easier to distinguish approved administration from ticket-redirection abuse.
Related resources from NHI Mgmt Group
- How should defenders reduce the risk of SPN-jacking in Active Directory environments with Constrained Delegation?
- Who is accountable when a Ghost SPN leads to SYSTEM access?
- What breaks when SPN abuse is not correlated with Kerberos and login activity?
- How do security teams know whether SPN modifications are actually working as a control?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
