Topic starter
02/08/2026 12:06 pm
TL;DR: CNAME abuse can coerce Kerberos service ticket requests for attacker-chosen SPNs, Cymulate reports, enabling relay across SMB and HTTP when signing or Channel Binding Tokens are missing. Windows AD exposure now depends on service-level protections, not on Kerberos alone or NTLM removal.
Editorial analysis by NHI Mgmt Group, based on content published by Cymulate: “Kerberos Authentication Relay Via CNAME Abuse”.
Key questions
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.
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.
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.
Glossary terms: Kerberos Relay, Channel Binding Token, ServicePrincipalName, CNAME-driven SPN coercion
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 2 days ago by NHI Mgmt Group
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