Notifications
Clear all
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.
NHIMG editorial — based on content published by Cymulate: Kerberos Authentication Relay Via CNAME Abuse
Questions worth separating out
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 do Windows environments still need anti-relay controls after NTLM is disabled?
A: Because removing NTLM does not make Kerberos relay-proof.
Q: How do organisations know whether their Kerberos exposure is actually reduced?
A: They need to test live services, not rely on policy declarations.
Practitioner guidance
- Enforce signing on every Kerberos-capable service Require SMB signing, LDAP signing, and application-level message integrity wherever Kerberos is accepted.
- Make Channel Binding Tokens mandatory on HTTP services Verify that IIS, AD CS Web Enrollment, and custom HTTP applications reject Kerberos authentication without CBT.
- Audit DNS poisoning exposure paths Harden DHCP, ARP, and DNS trust relationships so clients cannot be steered through rogue name resolution.
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.
👉 Read Cymulate's analysis of Kerberos CNAME abuse and relay paths →
Kerberos CNAME abuse: are your Windows relay controls enough?
Explore further
02/08/2026 1:11 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Kerberos CNAME abuse exposes relay paths in Windows AD
