Kerberos CNAME abuse exposes relay paths in Windows AD

At a glance

What this is: This research shows that DNS CNAME manipulation can coerce Windows clients into requesting attacker-chosen Kerberos service tickets, creating practical relay paths across common services.

Why it matters: It matters because IAM and PAM teams still often treat Kerberos as a safer default after NTLM deprecation, even though service-level signing and CBT controls decide whether relay is possible.

👉 Read Cymulate's analysis of Kerberos CNAME abuse and relay paths

Context

Kerberos relay is a service-level authorization problem, not just an authentication protocol issue. In Windows environments, DNS resolution can influence which service principal name a client requests, which means name resolution behavior can become part of the attack surface for identity security.

For IAM and NHI practitioners, the practical question is whether exposed services actually enforce signing and Channel Binding Tokens everywhere they are needed. If they do not, disabling NTLM can create a false sense of progress while leaving relayable services in place.

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 do Windows environments still need anti-relay controls after NTLM is disabled?

A: Because removing NTLM does not make Kerberos relay-proof. If exposed services still accept unsigned Kerberos sessions or fail to enforce Channel Binding Tokens, attackers can reuse coerced tickets for authentication. The remaining risk is service-specific, so NTLM removal must be matched with per-service hardening and validation.

Q: How do organisations know whether their Kerberos exposure is actually reduced?

A: They need to test live services, not rely on policy declarations. A reduced exposure state means the estate consistently rejects unauthenticated relay attempts, requires signing or CBT where relevant, and shows no unexpected acceptance of tickets across protocols. If one critical service still accepts relayed authentication, the risk remains active.

Q: Who is accountable when a relayable Kerberos service is exploited?

A: Accountability sits with the service owner, the platform team, and the identity governance function together. Kerberos relay is prevented at the service layer, so the control failure belongs to the systems that accepted the ticket and the teams that allowed unsigned or unbound authentication to remain in production.

Technical breakdown

How CNAME-based SPN coercion works in Windows

A Windows client resolving a service name can follow a DNS CNAME response and use the canonical name when constructing the Kerberos TGS request. That means an attacker with an on-path DNS position can steer the SPN the client asks for, even though the user intended to reach a different host. The important detail is that the coercion happens before ticket issuance, so the attacker is not breaking Kerberos crypto. They are manipulating the inputs that determine which ticket is requested.

Practical implication: treat internal DNS responses as security-sensitive input and not just name resolution traffic.

Why signing and Channel Binding Tokens stop relay

Kerberos relay succeeds when a service accepts the presented ticket without binding the authentication exchange tightly enough to the target service. Signing helps protect protocol integrity, while Channel Binding Tokens tie authentication to the specific channel and reduce relay opportunities over HTTP-based services. If either control is absent on an exposed service, a relayed ticket may be accepted even though the attacker never learned the password. The protocol remains intact; the service implementation is what determines exploitability.

Practical implication: validate signing and CBT enforcement per service, not as a domain-wide assumption.

Why cross-protocol relay widens the blast radius

This research also shows that some services accept Kerberos tickets based on the hostname portion of the SPN even when the service class differs. That creates cross-protocol relay paths, such as using tickets coerced for one protocol against another, which broadens the attack surface beyond the original target. In practice, the blast radius is defined by service behavior and trust in SPN handling, not by the nominal protocol label attached to the endpoint.

Practical implication: inventory which services accept Kerberos, then test whether their SPN and signing behavior allows cross-protocol reuse.

Threat narrative

Attacker objective: The attacker aims to impersonate a victim user and reuse that authenticated session against internal services to expand access.

1. Entry occurs when the attacker gains an on-path position in DNS traffic through techniques such as ARP or DHCP poisoning and returns a crafted CNAME and A record.
2. Escalation occurs when the victim client requests a Kerberos TGS for an attacker-chosen SPN, and the ticket can be relayed to an unsigned or unbound service such as SMB or HTTP.
3. Impact occurs when the relayed ticket is accepted, allowing user impersonation, lateral movement, privilege escalation, or remote code execution depending on the target service.

Breaches seen in the wild

• MITRE ATT&CK Enterprise Matrix — MITRE ATT&CK Enterprise — adversary tactics and techniques, threat detection, attack chain mapping, credential access, lateral movement, privilege escalation.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

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

NHI Mgmt Group analysis

DNS-controlled SPN selection is now part of the Kerberos trust boundary: Windows clients do not just resolve names, they can use canonicalized DNS responses to decide which service principal name to request. That means identity assurance is partly shaped by name-resolution behavior, not only by authentication policy. Practitioners should treat DNS integrity as a prerequisite for Kerberos trust.

Kerberos is relay-resistant, not relay-proof: The protocol’s resistance is often misread as a blanket defense, but the actual control point sits with each service that accepts the ticket. If SMB, HTTP, or custom services do not enforce signing and CBT, the domain still has relayable authentication paths. The field should stop describing Kerberos as inherently safe once NTLM is removed.

Service-level binding is the real control plane for relay prevention: This research reinforces a named concept we call the relayable service boundary, the point where authentication becomes exploitable because the endpoint accepts a valid ticket without binding it tightly enough to the intended channel or service. That boundary varies by application, which means exposure is uneven and often hidden inside infrastructure assumptions. Security teams need to govern services, not just protocols.

Cross-protocol ticket reuse widens identity blast radius: When services accept tickets based mainly on the hostname portion of the SPN, the attacker’s options expand beyond the originally targeted protocol. That collapses the assumption that service class separation meaningfully limits relay impact. The practical consequence is that one exposed endpoint can become a pivot into several others.

NTLM deprecation increases the cost of incomplete Kerberos hardening: Many organisations remove NTLM while leaving unsigned or unbound Kerberos services in place, which shifts rather than eliminates relay risk. That is a governance failure, not a protocol victory. The real question is whether the Windows estate can absorb Kerberos-only authentication without creating new impersonation paths.

From our research:

• 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• That governance gap becomes more acute when identity trust depends on runtime behaviour, a theme explored in 52 NHI Breaches Analysis.

What this signals

Windows identity teams should read this as a reminder that protocol migration is not the same as control completion. If NTLM removal is the milestone, service-level signing, CBT enforcement, and DNS trust hardening are the operational finish line.

Relayable service boundary: the practical exposure point is whichever service accepts Kerberos without binding the authentication exchange tightly enough to the target channel. Once that boundary is understood, teams can prioritise the endpoints that turn a coerced ticket into real access.

For broader identity programmes, this also reinforces the value of attack-path validation across authentication dependencies. If a single unsigned service can preserve lateral movement risk, access reviews alone will not surface the problem until testing does.

For practitioners

• Enforce signing on every Kerberos-capable service Require SMB signing, LDAP signing, and application-level message integrity wherever Kerberos is accepted. Test legacy and third-party services separately, because one unsigned endpoint can preserve relayability across the domain.
• Make Channel Binding Tokens mandatory on HTTP services Verify that IIS, AD CS Web Enrollment, and custom HTTP applications reject Kerberos authentication without CBT. Treat HTTP/S services without binding as relay targets until proven otherwise.
• Audit DNS poisoning exposure paths Harden DHCP, ARP, and DNS trust relationships so clients cannot be steered through rogue name resolution. Focus on segments where attackers could masquerade as the DNS server and influence SPN selection.
• Test for cross-protocol Kerberos acceptance Validate whether services accept tickets issued for unexpected SPN classes, such as HTTP tickets against SMB endpoints. If they do, the relay blast radius is larger than your service inventory suggests.
• Prioritise remediation on high-value relay targets Start with services that can turn relayed authentication into durable access, especially certificate services and administrative interfaces. Those endpoints convert a single coerced ticket into long-lived identity compromise.

Key takeaways

• Kerberos relay risk persists when service-level protections are incomplete, even if NTLM has been removed.
• DNS CNAME manipulation can change which SPN a Windows client requests, creating a realistic coercion path for attackers on the network.
• Signing, CBT, and per-service validation are the controls that determine whether a Kerberos ticket can be safely relayed.

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.
• Service Principal: An application identity object in Microsoft Entra ID and Microsoft 365 that represents a specific app inside a tenant. It holds permissions, ownership, and configuration data that define what the application can do. In NHI governance, it is a high-value identity that should be reviewed like any other privileged account.

What's in the full article

Cymulate's full blog covers the operational detail this post intentionally leaves for the source:

• Step-by-step attack walkthroughs for DHCPv6 poisoning, ARP poisoning, and DNS relay setup in Windows environments.
• Attack scenario details for Exposure Validation, including how the scan identifies relayable Windows authentication services.
• Practical examples of Kerberos relay against SMB, HTTP, and AD CS Web Enrollment when signing or CBT is missing.
• Patch and mitigation context around the Windows updates that backported CBT support for HTTP.sys.

👉 Cymulate's full post covers the attack walkthroughs, exposure validation scenarios, and mitigation details.

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 building or maturing an IAM programme, it is worth exploring.