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.
Editorial analysis by NHI Mgmt Group, based on content published by Semperis: “Exploiting Ghost SPNs and Kerberos Reflection for SMB Server Privilege Elevation”.
Key questions
Q: What breaks when a Ghost SPN is left in Active Directory?
A: A stale SPN can become an authentication target even though the host it names no longer exists.
Q: Why does this Ghost SPN issue create privilege-escalation risk?
A: Because the authentication exchange is not just proving identity, it is also carrying trust about where the service lives.
Q: What signs suggest Kerberos reflection is being attempted in a Windows environment?
A: Look for unusual TGS requests to HOST or CIFS SPNs that do not match a known service endpoint, especially when the target hostname is unresolved or recently changed.
Practitioner guidance
- Enforce SMB signing everywhere Make SMB signing mandatory on all domain-joined machines so relay-style Kerberos abuse cannot succeed through an unsigned session.
- Audit and remove Ghost SPNs Inventory SPNs that point to unresolved or decommissioned hosts, then correct or delete them before they become a reflection target.
- Restrict DNS record creation Remove the default ability for standard users to register arbitrary DNS records, especially where those records can influence authentication paths.
Bottom line: Ghost SPNs turn stale service metadata into a live authentication target when DNS and SMB controls are weak.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 11 hours ago by NHI Mgmt Group
25/06/2026 9:24 am
Ghost SPNs create an identity control gap, not just a naming defect: The exploit works because an SPN can outlive the hostname it was meant to represent. That leaves AD with a live authentication object that no longer matches a real service boundary. The practitioner consequence is that SPN lifecycle hygiene is an identity control, not a housekeeping task.
A question worth separating out:
Q: How should teams respond when SMB signing is not enforced on domain-joined systems?
A: Treat the environment as relay-capable until proven otherwise. Prioritise host groups that expose HOST or CIFS SPNs, remove unresolved SPNs, and tighten DNS write permissions so attackers cannot combine name control with unsigned authentication.
👉 Read our full editorial: Ghost SPNs expose a Kerberos reflection path to SYSTEM access
This post was modified 11 hours ago by NHI Mgmt Group