The clearest signals are changes to the ServicePrincipalName attribute on computer accounts, especially when the hostname no longer matches the computer’s DNS name. Additional indicators include removal and readdition of HOST class SPNs, plus Kerberos service ticket requests where S4U2Self shows the same account in both fields and S4U2Proxy includes a nonblank Transited Services value.
What SPN-jacking looks like in directory telemetry
SPN-jacking is usually visible first as directory drift, not as a loud authentication event. The most useful signal is an unexpected change to a computer object’s ServicePrincipalName values, especially when the hostname and DNS name stop lining up or the HOST SPNs are removed and then readded. Those changes matter because they can redirect Kerberos service authentication without changing the account that owns the object.
In practice, the suspicious pattern is a sequence, not a single edit: an SPN is deleted, the target account is modified, and the SPN set is restored in a way that looks operationally neat but is inconsistent with normal computer lifecycle activity. That is why SPN review should be treated as change detection on privileged directory attributes, not just as an inventory check.
A related clue is ticket behavior. When you see Kerberos service ticket requests where S4U2Self returns the same account in both fields, or S4U2Proxy includes a nonblank Transited Services value, you are looking at delegation-related traffic that deserves correlation with recent SPN changes. The ticket pattern alone is not proof, but it becomes highly meaningful when it follows a suspicious SPN edit.
Why the hostname mismatch and HOST SPN changes matter
Computer accounts are expected to have stable, predictable SPNs that match the machine’s identity in the directory and on the network. When the hostname no longer matches the computer’s DNS name, or when HOST class SPNs appear to be temporarily removed and then restored, the object may have been manipulated to alter how Kerberos resolves service identity. That is the core operational concern: the directory object still looks legitimate, but its service bindings are no longer trustworthy.
This is especially important because SPNs are not just labels. They are the lookup points Kerberos uses to find the right service principal for authentication. A malicious or unauthorized change can create an access path that is difficult to notice if teams only watch logon failures or account lockouts. The real signal is the mismatch between the directory record, the expected host identity, and the timing of the edit.
How to read the Kerberos evidence around a suspected SPN-jack
Ticket telemetry helps separate routine directory maintenance from abuse. S4U2Self where the same account appears in both fields can indicate constrained delegation activity that is worth validating against the service owner and recent change records. S4U2Proxy with a populated Transited Services field adds another clue that the ticket path is not a simple direct service request.
The key practitioner question is whether those ticket requests are consistent with the service’s normal delegation model. If they are not, look backward from the authentication event to the preceding SPN edits, account ownership, and the computer object’s recent attribute history. In a real investigation, the sequence often matters more than any one event.
Risk and Threat Considerations
SPN-jacking is risky because it can let an attacker redirect Kerberos service access while leaving the underlying account and object name apparently intact. That creates a detection gap: administrators may see a valid computer object and miss that its service bindings have been altered to support unauthorized authentication or delegation.
Failure mechanism: An attacker or insider modifies SPN values on a computer account, uses the changed binding to influence Kerberos service resolution, and then leverages delegation behavior to reach another service or impersonate a trusted flow.
Impact: The result can be unauthorized service access, privilege abuse, lateral movement, or hidden persistence inside active directory, especially when the change blends into normal operational updates.
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 CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1558 — Steal or Forge Kerberos Tickets | SPN-jacking is a Kerberos abuse pattern tied to ticket delegation and service access |
| Recommendation — Correlate SPN edits with Kerberos ticket activity and hunt for delegation abuse paths. | ||
| NIST SP 800-53 Rev 5 | AU-12 — Audit Record Generation | SPN changes and delegation events need auditable records for detection and review |
| AC-6 — Least Privilege | SPN abuse often succeeds when accounts can modify service bindings beyond need | |
| IA-5 — Authenticator Management | Kerberos service identity depends on controlled credential and authentication material | |
| Recommendation — Log directory attribute changes and preserve ticket events for investigation. Restrict who can change SPNs and other service-binding attributes. Rotate and govern service credentials tied to affected computer accounts. | ||
| NIST CSF 2.0 | DE.CM-01 — The network is monitored to detect potential cybersecurity events | SPN-jacking is detected by monitoring directory and Kerberos event patterns |
| ID.AM-01 — Physical devices and systems within the organization are inventoried | SPN integrity depends on accurate inventory of computer accounts and service bindings | |
| Recommendation — Monitor directory and Kerberos telemetry for abnormal SPN and delegation changes. Keep computer-account and SPN inventories current for change detection. | ||
Practitioner Guidance
What to verify: Compare every SPN change against the computer object’s expected hostname, DNS name, owner, and change ticket. If HOST SPNs were removed and readded, treat that as a meaningful control signal, not housekeeping.
Decision rule: If the SPN change is not clearly attributable to an approved lifecycle action, prioritize containment and directory review before assuming the ticket activity is benign. The faster you confirm whether the account’s service binding was intentionally changed, the easier it is to bound the blast radius.
Practitioner takeaway: SPN-jacking investigations work best when directory attribute history and Kerberos delegation evidence are reviewed together, because either signal alone can look normal while the combination exposes abuse.
Related resources from NHI Mgmt Group
- What are the signs that unconstrained delegation is still creating exposure in an Active Directory environment?
- What are the signs that an Active Directory environment is becoming too complex to manage safely?
- How should defenders reduce the risk of SPN-jacking in Active Directory environments with Constrained Delegation?
- How should security teams reduce the risk from SPN scanning 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
