Kerberos CNAME abuse exposes relay paths in Windows AD

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Cymulate's blog post: CNAME-based SPN coercion can turn standard Windows Kerberos lookups into relays against SMB, HTTP, and other services that do not enforce signing or Channel Binding Tokens.

Why it matters: It matters because IAM and infrastructure teams often treat Kerberos as a safer replacement for NTLM, but relay exposure is actually controlled by each service’s authentication hardening, not by the protocol choice alone.

Context

Kerberos relay risk in Windows is not only a protocol question, it is a service-hardening question. When DNS resolution can be influenced, a client may be led to request a service ticket for an attacker-chosen name, which creates an authentication path that the original application did not intend.

In Active Directory environments, that matters because SMB, HTTP, and other Kerberos-enabled services can remain relayable if signing or Channel Binding Tokens are not enforced. The article’s central point is that removing NTLM does not remove the need to govern service-level trust boundaries.

The primary problem is not a broken Kerberos implementation in the abstract. It is a mismatch between name resolution, SPN construction, and service-side enforcement that lets on-path attackers reshape legitimate authentication into relay traffic.

Key questions

Q: What breaks when Kerberos services do not enforce signing or CBT?

A: Kerberos relay becomes practical when the service accepts a valid ticket without binding the exchange tightly enough to the intended channel. In that state, an attacker who can influence DNS or sit on-path can coerce a ticket request and relay it to the target service for impersonation. The failure is at the endpoint, not in Kerberos itself.

Q: Why is removing NTLM not enough to stop relay attacks in Windows AD?

A: Because relay risk is controlled by the service that accepts the authentication, not by the name of the protocol being used. Kerberos can still be relayed if the target service does not require signing or CBT, so a protocol migration without service hardening leaves the abuse path intact.

Q: What are the signs that a Windows authentication service may be relayable?

A: Look for services that accept Kerberos authentication while signing is optional, HTTP endpoints without CBT, and internal applications that rely on default Windows behaviour rather than explicit anti-relay enforcement. Those conditions usually mean the service can be impersonated through a coerced ticket relay path.

Q: How should teams respond when DNS can influence Kerberos SPN selection?

A: Treat DNS as part of the authentication control path and reduce the number of systems that can answer internal queries. If name resolution can alter the SPN a client requests, then DNS poisoning or CNAME abuse becomes a practical impersonation route and should be governed like an identity dependency.

Technical breakdown

How CNAME resolution changes Kerberos SPN selection

Windows clients first resolve a service name through DNS, then construct the Ticket Granting Service request using the resolved hostname as part of the Service Principal Name. If an attacker can return a CNAME that aliases the original target to an attacker-controlled hostname, the client may request a ticket for that attacker-selected SPN instead of the intended one. That makes DNS a security-relevant input to authentication, not just to routing. The weakness is practical because it does not require password theft, only control over the name-resolution path.

Practical implication: treat DNS responses for internal service names as an authentication control surface, not as harmless metadata.

Why relay succeeds when signing or CBT is absent

Kerberos relay becomes viable when the target service accepts the ticket without binding the authentication to the intended channel or enforcing message integrity. Signing protects the session from tampering, while Channel Binding Tokens bind the authentication to the TLS or service channel so the ticket cannot simply be replayed elsewhere. Without those checks, the attacker can forward a valid service ticket to a different endpoint and impersonate the user. The article shows that SMB and HTTP are exposed when those service-level protections are not mandatory.

Practical implication: verify each Kerberos-enabled service individually for signing and CBT enforcement instead of assuming protocol choice has eliminated relay.

Why cross-protocol relay widens the blast radius

This technique is not limited to one protocol class because many services validate the hostname portion of the SPN more loosely than teams expect. That means a ticket coerced through one service name can sometimes be replayed to another service family when the receiving application accepts the hostname-based identity. In practice, that turns a name-resolution weakness into lateral movement, privilege escalation, or even remote code execution depending on what the relayed service can do. The blast radius is therefore determined by service behavior and trust configuration, not only by the original target.

Practical implication: inventory which services accept Kerberos tickets across protocol boundaries and harden the ones that can be abused as relay targets.

Threat narrative

Attacker objective: The objective is to impersonate the victim by relaying a valid Kerberos ticket into a service that will accept it without proper binding or signing.

1. Entry occurs when an on-path attacker intercepts or poisons DNS traffic and returns a crafted CNAME and A record for a legitimate Windows service name.
2. Credential access occurs when the victim client follows that response and requests a Kerberos TGS for an attacker-chosen SPN, creating a valid ticket without exposing the password.
3. Escalation occurs when the attacker relays that ticket to a target service that does not enforce signing or Channel Binding Tokens, allowing impersonation and unauthorized access.
4. Impact occurs when the relayed authentication is used for lateral movement, privilege escalation, or remote code execution against exposed Windows services.

Breaches seen in the wild

• Storm-0501 hybrid cloud attacks 2024: Ransomware affiliate Storm-0501 stole Entra Connect Sync credentials to move from on-prem AD to Entra ID, then forged tokens via a rogue federated domain.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Kerberos relay exposure in Windows is now a service-governance problem, not a protocol-selection problem. The article makes clear that Kerberos does not become relay-proof simply because NTLM is removed. If signing and Channel Binding Tokens are not enforced at the service layer, the authentication stack still accepts a relayed identity. For practitioners, the governance question shifts from which protocol is enabled to which services actually bind authentication correctly.

DNS CNAME handling creates an identity coercion path that many programmes do not model. The authentication decision is being influenced by name resolution, which means the trust boundary begins before the service is reached. That is a useful named concept for this issue: CNAME-driven SPN coercion, where DNS indirection reshapes the SPN a client requests and gives the attacker control over the eventual relay target. Practitioners should treat resolution logic as part of identity attack surface mapping.

Service-level anti-relay enforcement is the real control plane. The article shows that SMB and HTTP remain exposure points when signing or CBT is optional, which means the environment is only as strong as its weakest Kerberos-enabled service. This is not a universal protocol flaw, but it is a broad governance gap because ownership is fragmented across service teams. The implication is that relay risk must be governed per service, not assumed away at the directory level.

Disabling NTLM can create false confidence if the remaining Kerberos estate is not hardened. Organisations often interpret protocol migration as a security milestone, but this research shows that migration without service enforcement just changes the abuse path. The broader NHI lesson is that authentication posture is an ecosystem property, with DNS, SPN construction, and service acceptance all contributing to outcome. The practitioner conclusion is to govern the full authentication chain, not its label.

Windows relay resilience depends on enforced trust boundaries, not on client compliance alone. Microsoft’s mitigation for HTTP.sys reduced one relay path, but the underlying coercion primitive remains relevant wherever services fail to bind the ticket to the intended channel. That means patching helps, yet it does not replace hardening discipline across every exposed Windows authentication service. Practitioners should treat relay resistance as a per-service control assurance question.

What this signals

CNAME-driven SPN coercion: this pattern shows that identity attacks can begin in DNS, long before a service sees the request. Programmes that only review authentication settings after connection establishment are missing the earlier trust dependency that makes relay possible.

Kerberos hardening has to be owned per service because different endpoints expose different relay behaviour. When SMB or HTTP accepts unbound authentication, the control failure is not theoretical, it is an operational exposure that can be mapped and tested across the environment.

The practical signal for identity teams is that protocol migration work should be paired with service-level assurance. Disabling NTLM may reduce one set of risks, but it does not remove the need to enforce signing, CBT, and DNS trust boundaries across the Windows estate.

For practitioners

• Enforce signing on Kerberos-enabled services Make SMB signing mandatory on all servers and require signing wherever a service accepts Kerberos authentication. Do not leave signing optional on internal endpoints that can become relay targets.
• Require Channel Binding Tokens on HTTP services Turn on CBT for internal HTTP and HTTPS services, including IIS, AD CS Web Enrollment, and custom applications, so relayed tickets cannot be replayed across channels.
• Harden DNS as an authentication dependency Reduce who can answer client DNS queries, monitor for internal CNAME abuse, and treat name resolution as security-sensitive input because it can reshape Kerberos SPN selection.
• Inventory relayable services and protocol boundaries Identify which Windows services accept Kerberos without mandatory signing or CBT, then prioritise the ones that can be reached through SMB, HTTP, or other cross-protocol relay paths.

Key takeaways

• Kerberos relay in this case is driven by DNS manipulation and service-level acceptance, not by password theft or NTLM alone.
• The article shows that unsigned or unbound services remain the critical exposure point, especially where SMB and HTTP are still reachable.
• The defensive lever is control of the full authentication chain, including DNS trust, service signing, and Channel Binding Tokens.

Key terms

• Kerberos Relay: Kerberos relay is the reuse of a valid Kerberos ticket against a different service endpoint that accepts it without sufficient binding to the original channel or target. It is a service-level failure mode, not a password theft problem, and it becomes practical when signing or channel binding is missing.
• Channel Binding Token: A channel binding token links authentication to the specific transport session that initiated it. When enforced correctly, it makes replay and relay attacks much harder because the authentication material cannot simply be moved to another connection and reused as if nothing changed.
• ServicePrincipalName: ServicePrincipalName is an Active Directory attribute that identifies the service or application associated with an account. In practice, it helps security teams locate service accounts during discovery and validate whether an account is still tied to a legitimate workload, which supports inventory and governance efforts.
• CNAME-driven SPN coercion: CNAME-driven SPN coercion is the abuse of DNS canonical-name resolution to influence which Service Principal Name a Windows client requests during Kerberos authentication. It matters because it turns name resolution into a lever for ticket redirection and relay.

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.