Exploiting Windows Default Configurations for Domain Takeover via IPv6 DNS Spoofing

TLDR: This technique leverages the fact that Windows systems prioritize IPv6 over IPv4 and often have IPv6 enabled by default, even in IPv4-only environments. By deploying a rogue DHCPv6 server, an attacker can force clients to use a malicious DNS server, enabling NTLM relay attacks against domain controllers. This path leads directly to full domain compromise by capturing and relaying authentication requests from privileged users.

Active Directory environments are often built on legacy assumptions, and the transition to IPv6 has introduced a massive, often overlooked, attack surface. Most enterprise networks are still fundamentally IPv4-centric, yet Windows clients are configured to prefer IPv6 for name resolution by default. This creates a scenario where an attacker on the local network can easily intercept traffic that the operating system assumes is secure.

The attack relies on the fact that when a Windows machine boots or connects to a network, it broadcasts requests for network configuration. If an attacker is positioned on the local segment, they can respond to these requests faster than the legitimate infrastructure. By running a rogue DHCPv6 server, the attacker can advertise themselves as the primary DNS server for the victim machine. Because Windows prefers IPv6, the client will prioritize the attacker’s DNS responses over any legitimate IPv4-based DNS infrastructure.

The Mechanics of the Takeover

The core of this attack involves two primary phases: traffic interception and credential relaying. Once the attacker has successfully positioned themselves as the DNS server, they can intercept name resolution requests for services like Web Proxy Auto Discovery (WPAD). WPAD is a classic, high-value target because it is designed to automatically configure proxy settings for browsers. When a client asks for the location of the WPAD file, the attacker provides a malicious response that points the client to an attacker-controlled proxy server.

When the client attempts to connect to this "proxy," it will automatically initiate an authentication handshake. This is where tools like mitm6 and impacket become essential. The attacker uses these tools to capture the incoming NTLM authentication request. Since the client is essentially "asking" to authenticate, the attacker can relay that request to a domain controller. If the user is a domain administrator, the attacker gains the ability to execute commands with those privileges.

To execute this, the attacker typically runs a command similar to this:

# Start the rogue DHCPv6 server to intercept DNS requests
mitm6 -d yourdomain.local

# Simultaneously run the relay tool to capture and relay authentication
impacket-ntlmrelayx -t ldap://domaincontroller.yourdomain.local -smb2support

The beauty of this technique is that it requires zero interaction from the victim. It happens in the background as part of the standard network discovery process. Once the relay is successful, the attacker can use secretsdump to extract hashes from the domain controller, effectively ending the engagement with full domain admin rights.

Real-World Applicability

During a red team engagement, this is one of the fastest ways to move from a low-privilege position to full domain control. You do not need to find a complex zero-day or a misconfigured web application. You simply need to be on the local network segment. In many corporate environments, this is trivial to achieve through physical access, a compromised workstation, or even a rogue device plugged into a conference room port.

The impact is absolute. Once you have the ability to relay authentication from a domain administrator, you can create new users, modify group policies, or dump the entire NTDS.dit file. This falls squarely under OWASP A07:2021 – Identification and Authentication Failures, as the network is essentially trusting any device that claims to be a DNS server.

Defensive Considerations

Defending against this is difficult because it exploits the core design of Windows networking. The most effective mitigation is to disable IPv6 if it is not explicitly required by your infrastructure. If you must use IPv6, ensure that your network is properly segmented and that you are monitoring for unauthorized DHCPv6 traffic.

Beyond network-level controls, you should enforce LDAP signing and LDAP channel binding on your domain controllers. This prevents the relaying of NTLM authentication to LDAP, which is a common vector for these types of attacks. Additionally, disabling WPAD via Group Policy is a standard hardening step that removes a significant portion of the attack surface.

This attack is a reminder that the most dangerous vulnerabilities are often not bugs in code, but rather the default behaviors of the systems we rely on every day. As a researcher or pentester, your focus should be on identifying these "features" that provide an easy path to the crown jewels. If you are performing an internal assessment, check if your clients are making DNS requests over IPv6. If they are, you have a clear path to domain compromise.