Notifications
Clear all
Topic starter
25/06/2026 12:28 am
TL;DR: Ghost SPNs can let a low-privilege domain user reflect Kerberos authentication back to a target host and reach SYSTEM-level access when SMB signing is not enforced, according to Semperis. The issue shows that SPN hygiene, DNS write permissions, and protocol hardening still determine whether relay-style attacks remain viable.
NHIMG editorial — based on content published by Semperis: Ghost SPNs, Kerberos reflection, and SMB elevation of privilege
By the numbers:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps.
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.
Questions worth separating out
Q: How should security teams handle Ghost SPNs in Active Directory?
A: Treat Ghost SPNs as stale identity objects with attack potential, not as harmless cleanup items.
Q: Why do unresolved SPNs increase relay risk in Windows environments?
A: Unresolved SPNs create a mismatch between directory trust and actual service reachability.
Q: What breaks when SMB signing is not enforced on domain-joined systems?
A: Without SMB signing, the server has a weaker guarantee that the authentication exchange it receives is authentic and untampered.
Practitioner guidance
- Audit unresolved SPNs across the domain Inventory HOST and CIFS SPNs that point to names no longer resolvable in DNS, then remove or correct them before they can be registered by an attacker.
- Restrict arbitrary DNS record creation Remove the default ability for standard users to register DNS records where business requirements do not justify it.
- Enforce SMB signing on every domain-joined system Verify that SMB signing is required on servers and clients, not only on domain controllers.
What's in the full article
Semperis's full article covers the implementation detail this post intentionally leaves for the source:
- Packet-level walkthrough of the Kerberos reflection sequence and how the AP-REQ is replayed to SMB.
- Patch-level analysis of the SRV2.SYS changes that block non-local connections in the vulnerable session setup path.
- Hands-on mitigation notes for auditing SPNs, constraining DNS writes, and validating SMB signing coverage.
- Disclosure timeline and Microsoft response details for CVE-2025-58726.
👉 Read Semperis's analysis of Ghost SPNs and Kerberos reflection risk →
Ghost SPNs and Kerberos reflection: are your SMB controls enough?
Explore further
25/06/2026 9:24 am
Ghost SPNs are a machine identity hygiene failure, not just a Kerberos quirk. The problem emerges when directory records, DNS resolution, and service registration drift out of sync, leaving an identity object that still exists in AD but no longer points to a real endpoint. That stale identity becomes an attack surface because the platform still trusts the name. Practitioners should treat unresolved SPNs as live security debt, not administrative clutter.
A few things that frame the scale:
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
- Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging at 37% and over-privileged accounts at 37%.
A question worth separating out:
Q: Who is accountable when a Ghost SPN leads to SYSTEM access?
A: Accountability is shared across directory administration, DNS permission design, and server hardening. AD owners must manage SPN lifecycle, infrastructure teams must restrict DNS write rights, and platform teams must enforce SMB signing and coercion resistance. A Ghost SPN exploit is a governance failure as much as a technical one.
👉 Read our full editorial: Ghost SPNs expose a Kerberos reflection path to SYSTEM access
