A newly demonstrated Kerberos relay technique has revealed how attackers can bypass widely deployed protections by abusing DNS CNAME records. The publication of a working proof of concept has drawn attention not because Kerberos is fundamentally broken, but because the attack exposes a blind spot in how authentication, service identity, and name resolution interact inside Windows domain environments.
Kerberos authentication relies heavily on trust. A client requests access to a service, the Key Distribution Center issues a ticket for that service, and the client presents the ticket to prove its identity. Over time, security vendors and platform maintainers introduced defenses specifically aimed at stopping relay attacks, where an attacker intercepts and forwards authentication attempts to another service. Many organizations assumed these mitigations were sufficient and that Kerberos relay attacks were largely a problem of the past.
The new technique challenges that assumption.
Abuse of Name Resolution Instead of Authentication Logic
Rather than attacking Kerberos directly, this method focuses on DNS behavior, specifically Canonical Name (CNAME) records. A CNAME allows one hostname to act as an alias for another. This is a common and legitimate feature used for load balancing, service migration, and infrastructure abstraction. However, when combined with Kerberos authentication, CNAMEs introduce an unexpected opportunity for abuse.
In a typical scenario, a client requests a Kerberos ticket for a service identified by a hostname. The ticket is issued for the service principal name (SPN) associated with that hostname, not necessarily the final system that receives the connection. If DNS resolves that hostname via a CNAME to a different machine, Kerberos does not always re-evaluate whether the destination host is truly the intended service.
An attacker can take advantage of this behavior by placing a malicious system behind a carefully chosen CNAME. The hostname appears legitimate and trusted, while DNS resolution silently redirects traffic to attacker-controlled infrastructure. As a result, Kerberos authentication is successfully triggered and can be relayed, even in environments where traditional relay mitigations are enabled.
Why Existing Defenses Are Insufficient
Most Kerberos relay protections focus on validating the service identity during authentication. They assume that the service name accurately represents the endpoint receiving the authentication request. DNS CNAMEs break this assumption by separating the visible name from the actual destination.
Because the authentication process itself remains valid, security logs often show nothing obviously malicious. Tickets are properly issued, cryptography is intact, and no protocol violations occur. From a defender’s point of view, everything looks normal unless DNS resolution paths are closely inspected.
This gap is particularly dangerous in large enterprise networks, where DNS is complex and frequently modified. Permissions to create or alter DNS records may be broader than expected, and legacy aliases may persist long after their original purpose has been forgotten.
Practical Impact and Attack Scenarios
The release of a proof of concept demonstrates that this is not a theoretical issue. In real-world scenarios, an attacker with limited access, such as control over a workstation or the ability to register DNS records, could potentially trigger Kerberos authentication from higher-value systems. Relayed tickets can then be reused to access additional services, escalate privileges, or move laterally within the domain.
Importantly, this attack does not require breaking encryption or exploiting unpatched vulnerabilities. It relies on default behaviors and trusted relationships that exist in many environments. That makes it particularly appealing to skilled attackers looking for stealthy and reliable techniques.
Defensive Measures Going Forward
Mitigating this class of attack requires defenders to think beyond authentication protocols alone. DNS should be treated as a critical security dependency, not just an infrastructure service. Organizations should tightly restrict who can create or modify DNS records, especially CNAMEs associated with sensitive services.
Monitoring is equally important. Unusual Kerberos service ticket requests involving unexpected hostnames or alias chains should be investigated. Reviewing whether Kerberos authentication should rely on canonical names in specific scenarios can also reduce exposure.
Ultimately, this technique is a reminder that attackers increasingly exploit the boundaries between systems rather than weaknesses in a single component. Strong authentication can still be undermined if the layers supporting it are implicitly trusted. The newly released PoC makes one thing clear: assumptions about how systems interact deserve the same scrutiny as the systems themselves.
