Ghost SPNs expose a Kerberos reflection path to SYSTEM access

At a glance

What this is: This is an analysis of Ghost SPNs and Kerberos reflection, showing how a misconfigured SPN plus weak SMB hardening can enable remote privilege escalation to SYSTEM access.

Why it matters: It matters because the same control gaps that weaken machine identity governance, DNS permissions, and SMB trust boundaries can still let a standard user turn routine authentication into host compromise.

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.

👉 Read Semperis's analysis of Ghost SPNs and Kerberos reflection risk

Context

Ghost SPNs are Kerberos service principal names that point to hostnames that do not resolve in DNS. In practice, that creates a trust gap between directory state, name resolution, and the actual service endpoint, which is why this topic belongs squarely in machine identity and Windows access governance rather than generic vulnerability management.

The security problem is not just the reflection technique itself. It is the combination of default DNS write permissions, unresolved SPNs, and missing SMB signing that allows a low-privilege user to turn a reachable authentication path into SYSTEM-level execution on a domain-joined host.

Key questions

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. Security teams should inventory unresolved HOST and CIFS SPNs, remove entries for decommissioned services, and verify that DNS permissions cannot be abused to redirect authentication. The goal is to close the path before ticket reflection becomes possible.

Q: Why do unresolved SPNs increase relay risk in Windows environments?

A: Unresolved SPNs create a mismatch between directory trust and actual service reachability. If an attacker can register the missing name in DNS and force authentication, the target may issue or accept tickets in a way that enables reflection and relay. That is why SPN hygiene and DNS control belong in the same risk review.

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. That leaves room for relay-style attacks to replay Kerberos material back into SMB session setup and escalate privileges. In practice, unsigned SMB keeps a host open to reflected authentication abuse.

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.

Technical breakdown

How Ghost SPNs turn DNS control into authentication abuse

A Ghost SPN is a service principal name in Active Directory that references a hostname the domain cannot resolve. If a standard user can create or modify DNS records, that user can point the unresolved name at an attacker-controlled host. When a target machine tries to authenticate to that SPN, Kerberos issues a ticket for the target computer account, which can then be reflected back during SMB session setup. The failure is not Kerberos alone. It is the assumption that SPN registration, DNS reachability, and service identity all remain aligned after deployment.

Practical implication: audit unresolved SPNs and remove the assumption that DNS names in AD still map to live services.

Why SMB signing and loopback validation decide whether relay succeeds

The attack depends on the target accepting a reflected Kerberos blob during SMB session setup. SMB signing blocks unauthorised message tampering and replay, while loopback validation is meant to ensure the authentication context is genuinely local rather than relayed from a remote source. Microsoft’s fix for CVE-2025-58726 added checks in the SMB server path to terminate non-local connections when the SPN matches a valid local context. That means the exploit is not just about tickets. It is about whether the server can distinguish a real local authentication path from a relayed one.

Practical implication: require SMB signing on every domain-joined system and verify that relay-resistant validation is enforced in server paths.

How coercion tools convert a naming flaw into host compromise

Once an attacker identifies a valid Ghost SPN, coercion methods such as Printer Bug or PetitPotam can trigger the target to authenticate without direct user interaction. The attacker then relays the resulting AP-REQ back to SMB and obtains privileged execution as the machine account, which Windows maps to SYSTEM on the target. If the target is a Tier 0 asset such as AD CS, the impact expands from local compromise to domain compromise. The technical lesson is that a naming flaw becomes far more dangerous once coercion paths and overbroad machine privileges are both available.

Practical implication: reduce coercion exposure, monitor unusual Kerberos service ticket requests, and treat Tier 0 systems as relay-critical assets.

Threat narrative

Attacker objective: The attacker’s objective is to turn a misconfigured Kerberos path into SYSTEM-level remote execution and, where possible, expand that access into domain-wide compromise.

1. Entry occurs when a low-privilege domain user finds a Ghost SPN that points to an unresolved hostname and registers DNS so the name resolves to an attacker-controlled endpoint.
2. Escalation occurs when the attacker coerces the target machine into authenticating and relays the Kerberos AP-REQ back into SMB session setup, which the server accepts as a valid machine account context.
3. Impact occurs when the reflected authentication maps to SYSTEM on the target host, allowing arbitrary command execution and, on Tier 0 systems, potential domain compromise.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• JetBrains GitHub plugin token exposure — CVE-2024-37051 in JetBrains IntelliJ GitHub plugin exposed GitHub access tokens.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Default DNS write permissions are enough to turn a naming flaw into privilege escalation. The article shows that ordinary domain users can often register DNS records, which means an attacker does not need domain admin to weaponise a Ghost SPN. That is a governance problem in the entitlement model, not only a protocol problem. The practical conclusion is that DNS permissions sit on the same risk path as machine account controls.

SMB signing is the control boundary that determines whether reflection remains exploitable. Without signing, the server cannot reliably reject the relayed authentication blob and the reflection path survives even after adjacent fixes. This is why patching one CVE does not close the class of attack when the underlying trust assumption still holds. Security teams should map SMB signing coverage as a host-level trust control, not a box-checking setting.

Ghost SPN abuse exposes identity blast radius in Windows estates. A single unresolved SPN can become a launch point for coercion, ticket relay, and privileged execution because the machine account is treated as authoritative by downstream services. The wider the machine privilege surface, the larger the blast radius when that trust is abused. Practitioners should use this as a signal to narrow machine account reach and isolate Tier 0 systems.

Named concept: ghost SPN persistence. Stale service principal names that survive decommissioning, renaming, or deployment changes create a persistent identity gap that attackers can convert into remote authentication abuse. That gap is especially dangerous where lifecycle cleanup is manual and DNS write rights are broad. The implication is that SPN lifecycle control must be treated as part of machine identity governance, not periodic housekeeping.

From our research:

• 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%.
• That governance gap shows why 52 NHI Breaches Analysis is useful next reading for teams tracing identity failures into real-world compromise patterns.

What this signals

Ghost SPNs are a reminder that machine identity risk often starts in administrative drift, not in a sophisticated exploit. When directory records outlive the services they describe, the security programme inherits a stale trust relationship that attackers can convert into relay abuse. Teams should add SPN lifecycle checks to their routine identity governance cadence and document where DNS permissions can still be abused.

Ghost SPN persistence: stale service principal names that remain in AD after a service changes state create a standing identity gap that normal patching does not remove. That gap matters because the attacker is exploiting lifecycle failure, not a single software bug. Programme owners should watch for stale machine identities in the same way they watch for orphaned service accounts and unowned secrets.

The article reinforces a broader pattern across Windows estates. Identity controls fail fastest when the organisation assumes names, tickets, and endpoints will continue to line up automatically. Security teams should compare their SMB hardening, DNS governance, and Kerberos telemetry against guidance in the OWASP Non-Human Identity Top 10 and treat unresolved SPNs as a measurable risk indicator.

For practitioners

• 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. Use the audit to separate active services from stale directory entries.
• Restrict arbitrary DNS record creation Remove the default ability for standard users to register DNS records where business requirements do not justify it. Tighten write permissions so a low-privilege account cannot redirect a Ghost SPN to an attacker-controlled endpoint.
• Enforce SMB signing on every domain-joined system Verify that SMB signing is required on servers and clients, not only on domain controllers. Treat unsigned SMB as an open relay path that can preserve reflection-style abuse even when individual patches are present.
• Monitor Kerberos service ticket anomalies Alert on unusual TGS requests for unresolved or suspicious SPNs, especially where the target hostname does not exist in DNS. Correlate those events with coercion primitives and remote authentication attempts.
• Reduce coercion paths around Tier 0 assets Patch known coercion vectors, disable unnecessary services such as Print Spooler where it is not required, and filter RPC paths that can trigger forced authentication. Prioritise AD CS and other Tier 0 hosts for segmented review.

Key takeaways

• Ghost SPNs create a durable machine identity flaw because stale SPNs can still be used to route authentication, even when the underlying host no longer exists.
• The exploit becomes practical when DNS write permissions, coercion paths, and missing SMB signing all align, which is why the issue is about governance as much as protocol design.
• Teams that want to limit this class of attack should prioritise SPN cleanup, DNS permission tightening, SMB signing enforcement, and tighter monitoring for suspicious Kerberos tickets.

Key terms

• Ghost SPN: A Ghost SPN is a service principal name in Active Directory that points to a hostname that no longer resolves in DNS. It matters because the identity record still exists and can be abused to redirect authentication, even when the underlying service is gone.
• Kerberos reflection: Kerberos reflection is an abuse pattern where an attacker captures an authentication attempt and replays it back to the victim’s own service. In Windows environments, it can turn a legitimate machine authentication into privileged access when signing and relay protections are weak.
• SMB signing: SMB signing adds integrity protection to SMB messages so they cannot be altered or relayed without detection. In this context it is a trust boundary control, because unsigned sessions can accept reflected authentication material that should never have been reusable.
• SPN lifecycle: SPN lifecycle is the ongoing management of service principal names across deployment, rename, decommissioning, and cleanup. It becomes a security control when teams verify that directory entries still match live services and remove stale identities before attackers can weaponise them.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Semperis: Ghost SPNs, Kerberos reflection, and SMB elevation of privilege. Read the original.