A temporary SPN change can cause Kerberos to issue service tickets for a target the attacker chose rather than the service that originally owned the SPN. If the ticket is encrypted for the intended server, the attacker can still use it after adjusting the visible service name. That turns a seemingly harmless delegation setup into a practical privilege escalation path.
How a temporary SPN change redirects constrained delegation
Constrained Delegation is supposed to bind a front-end service to a fixed set of back-end services. A temporary SPN change breaks that assumption by changing which service principal the Kerberos ticket is minted for, so the delegation path can be steered toward a different target without changing the broader delegation configuration.
That matters because Kerberos service tickets are still cryptographically valid for the principal they were issued to. If the attacker can make the visible service name look normal again after the ticket is created, the ticket remains usable against the intended server-side secret or key material even though the request path was redirected.
In practice, the weak point is not the delegation feature itself, but the mutable service identity metadata around it. When SPNs can be changed quickly, an attacker who already has enough privilege to edit that mapping can reshape the trust boundary long enough to obtain a ticket that should never have been issued for the real target.
Why the abuse becomes a privilege escalation path
The escalation comes from separation between ticket issuance and service ownership. Kerberos trusts the SPN at issuance time, while the backend service trusts the ticket if it can decrypt it. If a temporary SPN change causes the KDC to issue a ticket for the attacker-chosen target, the attacker can turn delegated authentication into access to a service that was never meant to be in that delegation chain.
This is why the technique is operationally dangerous even when it looks like a harmless administrative rename. The ticket can outlive the brief SPN change, and the attacker only needs a short window to capture a service ticket that can later be replayed or presented in a form the target accepts. The result is often broader access than the original constrained delegation relationship should have allowed.
In environments with multiple services sharing naming conventions, the problem is amplified by ambiguity. A temporary change can redirect not just one request, but a whole class of service ticket requests if monitoring and change control do not catch the modified SPN immediately.
What defenders should verify in delegated Kerberos paths
Defenders should treat SPN mutability as part of the delegation control surface, not as a naming detail. The question is whether the service principal mapped at ticket-issuance time is the same principal that should own the downstream access path, and whether any admin or automation can alter that mapping without strong approval, traceability, and rapid rollback.
- Inventory which services are allowed to receive delegated tickets and which principals can modify their SPNs.
- Alert on SPN changes that occur outside planned maintenance windows or that are followed by unusual Kerberos ticket activity.
- Validate that delegated services cannot be repointed to higher-value back ends without an explicit access review.
- Check whether ticket usage, service ownership, and DNS or hostname aliases can drift apart during normal operations.
For deeper context on the underlying delegation and token-handling pattern, RFC 8693: OAuth 2.0 Token Exchange is a useful reference point for thinking about token substitution and on-behalf-of flows, even though the protocol is different from Kerberos. For broader control thinking around privileged trust paths, RFC 9700: Best Current Practice for OAuth 2.0 Security and NIST Cybersecurity Framework 2.0 help frame the need for stronger governance and monitoring around mutable access relationships.
Risk and Threat Considerations
A temporary SPN change creates a short-lived but high-impact trust manipulation window. The main risk is that a delegated authentication path can be redirected to a different service target before defenders notice the change, letting an attacker convert an administrative naming action into unauthorized access.
Failure mechanism: The security boundary relies on the SPN remaining stable between ticket issuance and service use, but the mapping can be altered long enough for Kerberos to mint a ticket for the wrong principal, then restored before routine review catches it.
Impact: The attacker may obtain a valid service ticket for a privileged or otherwise unreachable target, enabling privilege escalation, lateral movement, or access to a service that should have been outside the original constrained delegation scope.
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 NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Temporary SPN changes exploit excessive control over delegated service mappings. |
| IA-5 — Authenticator Management | Kerberos tickets and service secrets depend on correct credential and key handling. | |
| CM-3 — Configuration Change Control | The attack depends on unaudited, reversible SPN configuration changes. | |
| Recommendation — Restrict SPN modification rights to the minimum administrators needed. Protect service keys and credential lifecycle so ticket validity cannot be abused. Require approved, logged change control for any SPN modification. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Mutable service names show why trust should be continuously verified, not assumed. |
| Recommendation — Treat service identity changes as signals to re-evaluate trust before access is granted. | ||
| MITRE ATT&CK | T1098 — Account Manipulation | Changing SPNs is a form of account or service attribute manipulation to gain access. |
| Recommendation — Map SPN tampering to account manipulation detections and hunt for abuse. | ||
Practitioner Guidance
What to verify: Confirm that every account or automation path able to edit SPNs is limited to a tightly reviewed set of administrators. If SPN changes can be made by the same principals that administer the delegated service, treat that as a control weakness, not an operational convenience.
Common mistake: Teams often monitor whether constrained delegation is configured correctly, but not whether the service identity can be repointed after the fact. In this scenario, the dangerous condition is temporal control of the SPN, so change detection and rollback speed matter as much as the delegation ACL itself.
Practitioner takeaway: The real control is not just “can this service delegate,” but “can anyone briefly change what that service name means.” If yes, the delegation path may be safer on paper than it is in operation.
Related resources from NHI Mgmt Group
- How should defenders reduce the risk of SPN-jacking in Active Directory environments with Constrained Delegation?
- What is the difference between unconstrained and constrained delegation?
- Who should be accountable when an agent credential is issued through delegation?
- How should security teams prevent AI agents from escalating privileges through delegation chains?
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
