Topic starter
02/08/2026 12:06 pm
TL;DR: Kerberos service ticket requests can be coerced through DNS CNAME abuse, allowing on-path attackers to relay authentication across SMB and HTTP when signing or Channel Binding Tokens are missing, according to Cymulate. The issue shows that disabling NTLM alone does not remove relay risk because service-level controls, not Kerberos itself, determine exposure.
Editorial analysis by NHI Mgmt Group, based on content published by Cymulate: “Kerberos Authentication Relay Via CNAME Abuse”.
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.
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.
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.
Practitioner guidance
- Enforce signing on Kerberos-enabled services Make SMB signing mandatory on all servers and require signing wherever a service accepts Kerberos authentication.
- 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.
Bottom line: Kerberos relay in this case is driven by DNS manipulation and service-level acceptance, not by password theft or NTLM alone.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 1:11 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Kerberos CNAME abuse exposes relay paths in Windows AD