Defenders should treat SPN-jacking as an abuse path that can redirect delegation to an unintended target without changing delegation settings themselves. The practical controls are to audit for ghost SPNs, review anomalous WriteSPN rights, and watch for privileged accounts that are still eligible for Kerberos impersonation. Adding highly privileged users to Protected Users also narrows the attack surface.
Why SPN-jacking becomes dangerous in constrained delegation
SPN-jacking is not a change to the delegation policy itself, it is a redirection of where that policy points. In constrained delegation environments, that matters because a single writable SPN can let an attacker swap the intended target for a controlled service, then abuse legitimate Kerberos flows to impersonate users against the wrong backend.
The practical security problem is that the attack stays inside normal directory and Kerberos mechanics. If defenders only review delegation settings at a high level, they can miss the hidden pivot introduced by an SPN change, especially when the affected account is privileged or widely trusted.
What defenders should inspect first
Start with the objects that make delegation usable rather than the delegation entries alone. Ghost SPNs, unexpected WriteSPN permissions, and accounts that remain eligible for Kerberos impersonation are the highest-value places to look because they reveal who can redirect or exploit the trust path.
Protected Users is also relevant here, but as a blast-radius reducer rather than a complete fix. Adding highly privileged users to that group narrows where Kerberos delegation abuse can succeed, so it is most useful when paired with SPN hygiene and permission review.
- Inventory all SPNs on privileged and delegation-enabled accounts, then flag duplicates, stale entries, and SPNs that no longer match an active service.
- Review WriteSPN and equivalent directory write rights on service and privileged accounts, especially where those rights are inherited or delegated through nested group membership.
- Check which high-value users can still be impersonated through constrained delegation and remove that eligibility where the business process does not require it.
Why directory hygiene matters more than configuration intent
Constrained delegation is often treated as safe because it is narrower than unconstrained delegation, but its security depends on the integrity of the service principal mapping. If the mapping is mutable by an unexpected principal, the control boundary shifts from policy design to directory control, and the real risk becomes who can rewrite trust relationships.
This is why defenders should think in terms of ownership, reviewability, and change detection. A correctly configured delegation rule can still be abused if the target identity, service mapping, or privilege relationship is quietly altered after approval.
How to make SPN-jacking harder to sustain
Use a combination of least privilege on directory writes, tighter ownership of service accounts, and continuous monitoring for SPN churn. The goal is to make SPN changes rare, attributable, and immediately visible when they affect a sensitive delegation path.
For environments with many service accounts, that usually means separating service ownership from administrative ownership, reviewing any permission that can modify servicePrincipalName attributes, and treating newly appearing SPNs on privileged accounts as an alert-worthy event rather than routine drift.
Risk and Threat Considerations
SPN-jacking creates a high-impact abuse path because it can redirect an established delegation trust to a different service without the defender noticing a formal delegation-policy change. That enables stealthy impersonation, unexpected lateral movement, and escalation when the substituted target has broader reach than the original service.
Failure mechanism: An attacker or insider with the ability to write an SPN or influence service mapping rebinds delegation to a target they control, then uses normal Kerberos impersonation to access resources as a trusted user.
Impact: The result can be credentialed access to systems that appear to be reached through legitimate delegation, making detection slower and blast radius larger when privileged identities are involved.
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 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Restricts who can modify SPNs and delegation-related rights. |
| IA-5 — Authenticator Management | Covers credential lifecycle and protected handling around delegated services. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | SPN changes and delegation abuse require reviewable directory and Kerberos telemetry. | |
| Recommendation — Limit directory write rights to the smallest set of administrators and service owners. Rotate and track service credentials that support delegation-enabled accounts. Review SPN and delegation-change logs for anomalous writes and impersonation activity. | ||
| CIS Controls v8 | CIS-5 — Account Management | SPN-jacking is reduced by governing service accounts, privileged accounts, and stale identities. |
| Recommendation — Inventory and disable stale service accounts and privileged identities that still allow delegation. | ||
| MITRE ATT&CK | T1098 — Account Manipulation | SPN-jacking is a directory account manipulation technique that changes trust paths. |
| Recommendation — Detect and investigate service-account attribute changes that alter Kerberos delegation paths. | ||
Practitioner Guidance
What to verify: Confirm that every service account and privileged account involved in constrained delegation has an explicit owner, a current business justification, and no unnecessary WriteSPN exposure. If you cannot explain why an account can be delegated to, treat that as a control gap, not a benign configuration detail.
Decision rule: If a privileged user or service is still eligible for Kerberos impersonation and does not need that capability for business operations, remove the path first, then reassess whether the related delegation is still justified. That sequence reduces risk faster than trying to prove abuse after the fact.
Practitioner takeaway: In constrained delegation, the safest posture comes from controlling who can rewrite the SPN relationship, not just from approving the delegation relationship itself.
Related resources from NHI Mgmt Group
- Why does constrained Kerberos delegation reduce risk compared with unconstrained delegation in Active Directory environments?
- How should security teams reduce the risk from SPN scanning in Active Directory environments?
- How should security teams reduce ransomware risk in Active Directory environments?
- How should security teams reduce the risk of DCSync abuse in Active Directory environments?
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
