Kerberos Authentication Relay Via CNAME Abuse 

Originally published January 15, 2026. Updated January 21, 2026, with new attack scenarios in Cymulate Exposure Validation.

Cymulate Research Labs uncovered a dangerous flaw in how Windows environments handle Kerberos service ticket requests one that significantly expands the practical attack surface for Kerberos relaying in Active Directory. 

By abusing the interaction between Kerberos TGS requests and DNS CNAME resolution, this technique allows an attacker positioned on-path to coerce Windows clients into requesting user service tickets for attacker-chosen Service Principal Names. These tickets can then be relayed across protocols such as SMB and HTTP in environments where signing or Channel Binding Tokens (CBT) are not enforced, enabling user impersonation without ever knowing the victim’s password. 

The result is a highly practical, on-demand Kerberos relay technique that enables lateral movement, privilege escalation, and even remote code execution, pushing Kerberos exploitation beyond previously known constraints. 

Mitigation for this exposure is achieved by enforcing Channel Binding Token and signing on all services where current environment constraints allow, and by applying the latest Microsoft Windows security updates.

To test and validate resilience against attacks targeting this weakness, Cymulate Exposure Validation has been updated with new attack scenarios to simulate how attackers discover vulnerable targets and execute an exploit. These attack scanarios include:

• Scan for Relayable Windows Authentication Services (Missing Signing or CBT)
• Kerberos CNAME Abuse Relay Using MITM6 to AD CS (ESC8)
• Kerberos CNAME Abuse Relay - Enumerate And Relay

Executive summary 

This research was responsibly disclosed to Microsoft in October 2025. Microsoft confirmed the reported behavior and acknowledged that Windows Kerberos clients will follow DNS CNAME responses when constructing Service Principal Names (SPNs) for Ticket Granting Service (TGS) requests. 

The primary actionable security action Microsoft chose to implement was addressing the target services’ resilience. 

As a result, Microsoft implemented and backported CBT support for HTTP.sys across supported Windows Server versions, addressing Kerberos relay attacks targeting HTTP-based services. This remediation was released as a patch in January 2026 security updates and tracked under CVE-2026-20929. 

While this mitigation significantly reduces exposure for HTTP relay scenarios, the underlying behavior described in this research, the ability to coerce Kerberos clients into requesting service tickets for attacker-chosen SPNs via DNS CNAME manipulation, remains unchanged. 

More importantly, this highlights a broader and often misunderstood security reality: Kerberos itself does not inherently prevent relay attacks. Protection against Kerberos relay is enforced at the service level, not at the authentication protocol level. Each Kerberos-enabled service (SMB, HTTP, custom services, and others) must independently enforce protections such as signing and Channel Binding Tokens. 

As a result, much of the responsibility for preventing Kerberos relay attacks lies with organizations and service owners. Disabling NTLM or “moving to Kerberos” alone does not eliminate relay risk. Unless every exposed Windows authentication service in the domain explicitly enforces appropriate anti-relay protections, Kerberos remains a viable relay vector. 

This blog documents the CNAME-based SPN coercion primitive, its exploitation paths, and its broader security implications. 

Severity, likely impact and key findings 

Practical on-demand Kerberos relay of user accounts, greatly expanding the attack surface beyond previously known techniques allowing unauthenticated user impersonation and unauthorized protocol access. Depending on the target protocol this could result in: 

1. Remote code execution 
2. Lateral movement and privilege escalation 
3. Unauthorized access to systems and applications. 

Key finding: A Windows client attempting Kerberos service authentication flow will follow a CNAME response and subsequently request a TGS using the CNAME hostname as the SPN. This behavior allows an on-path attacker to force a client to request a ticket for an attacker-selected DNS name. 

Conditions for exploitation 

1. The attacker must be able to intercept or modify DNS traffic from the victim. Achievable network conditions include but are not limited to ARP poisoning, DHCPv4/DHCPv6 poisoning or other MITM techniques. 
2. The target service must accept Kerberos authentication without mandatory signing or CBT enforcement. Services tested that are vulnerable include SMB and HTTP when signing or CBT are not enforced. 

Background 

With Microsoft’s announcement that NTLM is being deprecated, many organizations are accelerating efforts to disable NTLM wherever possible, with the expectation that Kerberos provides stronger protection against credential relay and impersonation attacks. As a result, Kerberos is often treated as a “safe default” authentication protocol once NTLM is removed from the environment. 

In practice, Kerberos is more resistant to relay than NTLM, but it is not inherently relay-proof. Successfully relaying Kerberos authentication typically requires the attacker to coerce a client into requesting a Ticket Granting Service (TGS) ticket for a specific Service Principal Name (SPN) that matches the target service. Controlling SPN selection is therefore the central challenge in practical Kerberos relay attacks. 

Over the years, researchers have explored multiple techniques to influence SPN selection. These include SOA-based abuse, CredMarshalTargetInfo manipulation, and LLMNR alias responses. While effective in certain scenarios, these techniques often come with significant operational constraints: reliance on deprecated name resolution mechanisms, dependencies on IPv6 being enabled, limitations to machine accounts rather than user accounts or reliance on a specific feature being enabled. 

Prior research, including work published by Google Project Zero, has also shown that Windows components may derive Kerberos SPNs from canonicalized DNS names rather than the originally requested hostname.  

This research builds on this observation and focuses on turning canonical name handling into a practical, generic, and on-demand coercion primitive. By abusing standard DNS CNAME resolution from an on-path position, an attacker can reliably cause default Windows clients to request TGS tickets for attacker-chosen SPNs while connecting to attacker-controlled infrastructure and applies broadly to user authentication on fully patched Windows systems. 

Kerberos DNS CNAME Abuse 

When a client connects to a service it first performs a DNS lookup to resolve the service name to an IP address. This resolution step can be abused. Upon receiving the client DNS query, an attacker can return a response that: 

• Returns a CNAME record that aliases the requested domain to an attacker-chosen hostname. And in the same response also: 
• Supply an A record for the attacker-chosen hostname that resolves to the attacker-controlled IP. 

This provides both the alias (CNAME) and the actual IP resolution in one response causing the victim to automatically and unknowingly, request a TGS for the attacker-chosen Service Principal Name instead of the one originally intended. 

To provide the additional functionality, we have cloned the MITM6 tool and added it the CNAME poisoning functionality: 

BenZamir/MITM6-Kerberos-CNAME-Abuse: A modified version of [mitm6](https://github.com/dirkjanm/mitm6) with Kerberos CNAME abuse capabilities to support Kerberos CNAME relay. 

Let's look at an example. A victim attempts to access server01.newcorp.local which is an existing server in the domain. It first attempts to resolve the DNS address of the target service, getting a CNAME and A record for an attacker-chosen target: 

The victim’s attempts to connect the attacker’s malicious server and gets a 401 Unauthorized response, requiring Kerberos authentication: 

Yet the CNAME & A record responses cause the machine to request a TGS for the attacker’s target DNS:

And provide the attacker-chosen TGS to the malicious server:  

Using that manipulation, the attacker can force the victim to request a TGS for an SPN under the attacker’s control.  

The attacker can forward that ticket to the intended service and gain successful authentication, impersonating the victim. The krbrelayx tool already does that part. 

One important observation is that Kerberos relay in general is less constrained then initially assumed, as many documented research already proved that many services accept TGS tickets issued based only on the DNS part of the SPN even when the SPN service prefix does not match the expected service type.  

For example, SMB services tend to accept an HTTP class SPN and HTTP endpoints usually accept CIFS class SPNs. This behavior enables cross-protocol Kerberos relay, significantly broadening the scope and impact of DNS-based SPN coercion (and allowing cross-protocol relay). 

To perform the attack, the only pre-requirement is DNS MITM position within the network which could be made by the following methods: 

1. Initiate ARP poison attack to masquerade as the gateway and intercept outgoing DNS requests. 
2. DHCPv6 poisoning: Exploit DHCPv4 broadcast requests to inject the attacker’s address as DNS server and use that position to send the malicious CNAME and A records. 
3. DHCPv6 poisoning: The attacker could use the currently known MITM6 technique to advertise and respond to DHCPv6 solicit messages, inject itself as a DNSv6 server and use that position to send the malicious CNAME and A records. 
4. Use any other valid DNS poisoning method. 

Note: most of the techniques above rely on being in the same LAN segment as the victim machines but the main requirement is to masquerade as the DNS server, causing the victim to attempt and perform DNS resolution against the attacker regardless of segment position.  

Putting It All Together 

Before diving into the exploitation example, let’s tie everything together with a clear, end-to-end view of how the pieces come together: 

1. The attacker targets an unprotected protocol (no signing or CBT) supporting Kerberos authentication. For example: 

• SMB service without signing enforced 
• HTTP service 
• HTTPS service without Channel Binding Token enforced 

Note: testing was done over the services listed above. Other services supporting Kerberos authentication may be vulnerable as well (e.g. MSSQL). 

2. The attacker gains a DNS poisoning network position by either: 

• DHCPv6 Poisoning (also known as MITM6) 
• ARP Poisoning -> DNS queries interception 
• DHCPv4 Poisoning (e.g. using the responder tool DHCP poisoning feature, injecting to victims the attacker as the DNS server) 
• Other method of poisoning the victim into attempting to resolve DNS against the attacker 

The attacker sets up a malicious DNS server. For the proof of concept, I cloned the MITM6 tool and extended it with the necessary functionality to support Kerberos CNAME abuse relaying, leveraging both DHCPv6 and ARP poisoning techniques.  

3. A victim attempts to access a domain asset. When the attack begins, the victim attempts to access a legitimate asset and first attempts to resolve the service’s DNS name. Because of the setup in step three, these queries are redirected to the rogue DNS server. The malicious server responds with a crafted CNAME pointing to an attacker-chosen target, along with an A record resolving that CNAME to an IP address controlled or selected by the attacker. 

In every configuration tested (including default), the client used the CNAME combined with the intended service type as the SPN DNS value when constructing the TGS-REQ, rather than the original and legitimate service address. This behavior was consistently observed across all victim systems tested, all of which were fully up to date: 

• Windows 10 
• Windows 11 
• Windows server 2022 
• Windows server 2025  

4. The victim then presents the service ticket when authenticating to the attacker-controlled host. 

5. The attacker relays that ticket to the intended target. Because the ticket was issued for the target hostname (the CNAME) rather than the original service name, the target accepts the ticket and the attacker is able to impersonate the victim and inherit their privileges. 

Abuse flow chart:

Exploitation walkthrough examples 

Example 1: CNAME Kerberos relay using DHCPv6 poisoning to ADCS  Web Enrollment (ESC8) 

The environment: 

• Victim: Windows 11 Pro 
• DC: Windows 2022 
• Victim’s Original Target: DESKTOP-IBE6812.mycorp.local (a valid and existing device in the domain using Windows 10 Pro Workstation) 
• Attacker’s target: adcs-server.mycorp.local (Windows server 2025 with the ADCS role)  
• DESKTOP-IBE6812 is a legitimate machine that is active and exists within the domain: 

Walkthrough 

1. The attacker uses the mitm6 with CNAME tool to set a rogue DNS server in addition to DHCPv6 poisoning and can intercept and poison the DNS resolve request from the victim: 

The victim attempts to access the intended server but unknowingly, his machine requests a TGS for adcs-server.mycorp.local instead and forwards it to the attacker.  

For the victim, the only visible host is DESKTOP-IBE6812.mycorp.local: 

2. The attacker receives the desired service ticket and uses it to impersonate the user against the ADCS web enrollment service, requesting a certificate under the victim’s name: 

Example 2: CNAME Kerberos relay to SMB using DHCPv6 poisoning (MITM6) 

The environment: 

• Victim: Windows 11 Pro 
• DC: Windows 2022 
• Victim’s Original Target: HTTP access to file01.mycorp.local 
• Attacker’s target: DESKTOP-IBE6812.mycorp.local Windows 10 Pro Workstation (SMB) 

Walkthrough: 

1. The attacker uses the mitm6 with the CNAME feature and creates a rogue DNS server and uses DHCPv6 poisoning (AKA MITM6) in addition to CNAME poisoning: 

And uses the krbrelayx tool to set fake HTTP and SMB servers to intercept users’ authentication service tickets and relay them: 

Note that in that example, the attacker attempts a cross-protocol relay, relaying Kerberos authentication from HTTP to SMB. 

2. The victim attempts to access the file01.mycorp.local service’s HTTP server: 

Note that:  

• NTLM auth is disabled and the victim is using Kerberos authentication. 
• The victim is not exposed to the fact that the machine requested a TGS for a different DNS. 

3. The attacker intercepts the victim’s DNS resolve request for the original server, returning a CNAME record of the attacker’s target (to force the client to request a TGS for the attacker’s target instead of the original DNS) and an A record of the attacker’s IP address: 

4. The victim then attempts to authenticate against the attacker’s address with the TGS intended for the attacker’s target. The attacker relays the authentication and achieves a successful SMB authentication in the name of the victim: 

The attacker triggered a reliable, on-demand Kerberos relay and forwarded the ticket to a target of their choice. 

Example 3: CNAME Kerberos relay using ARP poisoning to ADCS web enrollment (ESC8) 

The environment: 

• Victim: Windows 11 Pro 
• DC: Windows 2022 
• Victim’s Original Target: web01.mycorp.local (via HTTP) 
• Attacker’s target: adcs-server.mycorp.local Windows Server 2025 (ACDS ESC8) 

Walkthrough: 

1. The attacker sets a rogue DNS server and fake HTTP and SMB servers: 

The attacker sets the target service’s DNS address for CNAME record poisoning: 

2. The attacker initiates an ARP poisoning attack, masquerading as the gateway (half duplex, victim -> attacker -> gateway): 

3. When the victim attempts to access any domain asset (*.mycrop.local) it performs a DNS resolution request, the attacker intercepts it (DNS resolution passes through the gateway so the victim has no idea who is actually replying), responding with a CNAME record pointing to the attacker’s target and an A record for the attackers’ IP. 

In the example: 

Victim attempts to resolve web01.mycorp.local 

Attacker responds with: 

1. CNAME record pointing web01.mycorp.local to adcs-server.mycorp.local 
2. A record for adcs-server.mycorp.local pointing to the attacker’s IP 

After a successful DNS record poison, the victim accesses the attacker’s rogue HTTP (or SMB) server. The attacker responds with a 401 message, requesting Kerberos authentication: 

The attacker redirects the victim’s legitimate network flow back to the original Domain Controller, allowing it to request a valid TGS. 

The victim requests a TGS with the DNS of the attacker’s target (adcs-server.mycorp.local) as SPN and forwards it to the attacker’s server which performs a relay attack, using that service ticket to authenticate against the attacker’s target. In this example, to request a certificate in the name of the victim: 

What Can I Do Against It? 

There is no single switch to flip. Mitigation means removing relay opportunities at the service layer, while accepting that tightening these controls is operationally painful. 

Enforce signing everywhere 

• Require SMB signing on all servers, not just domain controllers. 
• Enforce LDAP signing and LDAPS Channel Binding Tokens (CBT) where supported. 
• Any Kerberos-capable service that allows unsigned or unbound authentication remains relayable. 

Make CBT mandatory for HTTP/S 

• Enforce HTTPS and CBT on all internal HTTP based services (IIS, ADCS Web Enrollment, custom apps, etc..). 
• Kerberos over HTTP without CBT is still vulnerable to relay, even when NTLM is fully disabled. 

Reduce DNS trust where possible 

• Harden DNS infrastructure and limit who can answer client DNS queries. 
• Consider stronger DNS options such as DNS over HTTPS (DoH) to reduce on-path DNS manipulation opportunities, especially in high-risk network segments. 
• Treat internal DNS responses as security-sensitive input, not just name resolution. 

Assume cross-protocol relay is real 

• Do not rely on SPN service-class matching for protection. 
• Services frequently accept tickets based only on the hostname portion of the SPN. 

Detect anomalies 

• Alert on unusual TGS requests (new or rare SPNs, HTTP SPNs followed by SMB/LDAP access, etc..). 
• Monitor for unexpected internal CNAME usage, especially involving sensitive services. 
• Watch for authentication patterns where tickets are reused across protocols. 

Operational disclaimer 

• These controls will break things if dependent services, legacy systems, or third-party applications do not fully support signing or CBT. 
• That friction is exactly why these protections are often incomplete, and why Kerberos relay remains viable in real environments. 

How Cymulate Exposure Validation simulates the exploit 

On January 15, 2026, we updated Cymulate Exposure Validation with the attack scenario Detecting Common Relayable Windows Authentication Services (Missing Signing or CBT). This production-safe attack scenario executes the expected network service discovery (T1046) that an attacker would use to identify vulnerable endoints and execute the attack described in this blog.   

On January 21, 2026, we enhanced Cymulate Exposure Validation with a two additional scenarios: 

• Kerberos CNAME Abuse Relay Using MITM6 to AD CS (ESC8) 
• Kerberos CNAME Abuse Relay - Enumerate And Relay 

Kerberos CNAME Abuse Relay Using MITM6 to AD CS (ESC8) performs active Kerberos relay exploitation by leveraging the CNAME abuse technique in combination with MITM6 to coerce authentication and impersonate a user against Active Directory Certificate Services, ultimately obtaining a certificate issued in the user’s name. 

Kerberos CNAME Abuse Relay - Enumerate And Relay chains together the attack scenarios to simulates an end-to-end attack path, covering the full flow from initial enumeration through successful exploitation. 

Conclusion 

The way Kerberos clients and services interpret DNS CNAME responses creates a protocol and default-configuration weakness that can be abused to perform attacker-controlled, on-demand authentication relays. Unlike prior methods that were often constrained to machine accounts or special network conditions, CNAME-based coercion yields attacker-controller TGS tickets on demand. This increases opportunities for privilege escalation, unauthorized access, and domain compromise, but the root cause is a fixable interaction between DNS resolution and SPN selection that can be mitigated by changes to client and server behavior.