Most internal networks still run IPv4 as the primary protocol for day-to-day traffic, but Windows enables IPv6 by default and actually prefers it over IPv4 when both are available. Because almost nobody actively manages or monitors IPv6 on internal networks, this creates a quiet, frequently overlooked attack surface that lets an attacker with no prior credentials hijack DNS resolution and relay authentication straight into Active Directory. This post explains exactly how the IPv6 DNS takeover attack works, why it is so effective, and how to detect and close it. Internal Active Directory assessments run by Sagefox Cybersecurity test for this exact exposure as a routine part of initial network reconnaissance, since it consistently succeeds in environments where IPv6 was never explicitly hardened.
Why IPv6 Creates an Unmonitored Attack Surface
IPv6 Is Enabled by Default and Preferred Over IPv4
Windows machines are IPv6-enabled out of the box, and the operating system's network prioritization logic favors IPv6 over IPv4 whenever both are present on the network. Most organizations never assigned static IPv6 addressing, never deployed an internal DHCPv6 server, and have no IPv6-specific monitoring in place, all while their Windows hosts continue running IPv6 in the background and listening for configuration information over it.
Windows Hosts Actively Ask for IPv6 Configuration
Because there is typically no legitimate DHCPv6 server on these networks, Windows machines regularly broadcast DHCPv6 solicitation requests looking for one, and just as often fall back to using the IPv6 Router Advertisement (RA) protocol and mDNS/LLMNR-style name resolution over IPv6. None of this traffic is malicious on its own, but it is a wide-open door for any attacker willing to answer.
How the Attack Works
Step One: Responding to DHCPv6 Requests
An attacker on the same network segment runs a tool that listens for DHCPv6 solicitation requests and responds before any legitimate server would, since none typically exists. The tool most commonly used for this is mitm6, purpose-built for exploiting exactly this gap.
sudo mitm6 -d target.localThis assigns the attacker's machine as the IPv6 DNS server for every Windows host on the segment that requests IPv6 configuration, all without needing any credentials or prior access to the network.
Step Two: Becoming the Trusted DNS Resolver
Once assigned as the IPv6 DNS server, the attacker's machine controls DNS resolution for any client configured to use it, including resolution of Active Directory-related hostnames like the domain's WPAD (Web Proxy Auto-Discovery) endpoint.
Step Three: Hijacking WPAD to Capture Authentication
With DNS control established, the attacker can respond to WPAD lookup requests with a malicious proxy configuration file, which many Windows systems request automatically as part of normal proxy autodiscovery behavior.
sudo ntlmrelayx.py -6 -t ldaps://10.10.10.10 -wh fakewpad.target.local -l /tmp/relay_lootRunning ntlmrelayx alongside mitm6 captures the NTLM authentication attempt generated when a Windows host tries to fetch its proxy configuration through the now-hijacked WPAD hostname, and relays that authentication in real time to a target of the attacker's choosing.
Step Four: Relaying Authentication to LDAP or LDAPS
The most damaging version of this attack relays the captured NTLM authentication directly to the domain controller's LDAP or LDAPS service, rather than to an arbitrary server. If the relayed account has sufficient privileges, this allows the attacker to make privileged directory changes, such as granting themselves further delegation rights or resetting a password, without ever needing to crack a hash.
sudo ntlmrelayx.py -6 -t ldaps://10.10.10.10 --delegate-accessThe --delegate-access flag is specifically useful here because it automates configuring Resource-Based Constrained Delegation on a target computer object using the relayed authentication, providing a direct path to full impersonation of any user against that target.
Step Five: Escalating from Relay to Domain Compromise
If the relayed account happens to be a domain administrator's machine account authenticating during normal background activity, or if RBCD was successfully configured against a computer object, the attacker can move immediately from a passive DNS hijack into full domain compromise, following the same S4U2Self and S4U2Proxy Kerberos delegation abuse techniques used in other Active Directory escalation paths.
python3 getST.py -spn cifs/targetserver.target.local -impersonate 'DomainAdmin' \
-dc-ip 10.10.10.10 target.local/ATTACKERPC\$:Password123!Why This Attack Is So Reliable in Real Environments
No Credentials Required to Begin
Unlike most Active Directory attack paths, which require at least some initial foothold or valid credential, the IPv6 DNS takeover starts entirely from a position of pure network access, making it one of the most valuable techniques available at the very start of an internal engagement.
IPv6 Is Rarely Monitored or Restricted
Firewall rules, network segmentation, and intrusion detection systems are frequently built around IPv4 traffic patterns, leaving IPv6 traffic on the same segment largely unmonitored. An attacker running this attack often generates no alerts at all, since nothing is actively watching for anomalous IPv6 router advertisements or DHCPv6 responses in the first place.
WPAD Autodiscovery Behavior Is Widespread
Windows systems requesting WPAD configuration automatically, without any user interaction, means this attack does not require any social engineering or user action to trigger. It happens passively as part of normal system behavior, as long as the attacker is positioned to respond before any legitimate service does.
Detecting IPv6 DNS Takeover Attempts
Monitoring for Rogue DHCPv6 Responses
Network monitoring tools capable of inspecting DHCPv6 traffic should flag any DHCPv6 advertisement or reply originating from a host not on an approved list of legitimate DHCPv6 servers, which in most organizations is an empty list since IPv6 was never formally deployed.
tcpdump -i eth0 -n 'udp port 547'Reviewing captured traffic for DHCPv6 responses from unexpected source addresses is a straightforward way to confirm whether this kind of activity has occurred on a given segment.
Reviewing DNS Query Logs for Suspicious WPAD Activity
Unusual volumes of WPAD-related DNS queries, particularly ones resolving to an unexpected internal IPv6 address, are a strong indicator that a takeover attempt is either underway or has already succeeded.
Auditing for Unexpected LDAP Bind Activity
Since the most damaging variant of this attack relays authentication directly to LDAP or LDAPS, reviewing domain controller logs for LDAP bind attempts originating from unusual source addresses, particularly ones correlating with IPv6 link-local addresses rather than expected IPv4 client ranges, can reveal an active or recent relay attempt.
Get-WinEvent -LogName "Directory Service" | Where-Object { $_.Id -eq 1644 }Defending Against IPv6 DNS Takeover
Disabling IPv6 If It Is Not Actually Used
The most direct mitigation for organizations that have no legitimate business use for IPv6 on their internal network is disabling it entirely at the host level through Group Policy, removing the attack surface rather than attempting to monitor and defend an unused protocol.
reg add "HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters" /v DisabledComponents /t REG_DWORD /d 0xFF /fDisabling WPAD Autodiscovery If Not Required
Where a legitimate proxy autodiscovery process is not in use, disabling WPAD entirely removes one of the key mechanisms this attack chain relies on to capture authentication.
reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad" /v WpadOverride /t REG_DWORD /d 1 /fDeploying a Legitimate DHCPv6 Server If IPv6 Is Required
For organizations that do need IPv6 for legitimate business reasons, deploying an authorized, monitored DHCPv6 server ensures that Windows hosts receive configuration from a trusted source rather than being left to accept the first response received on the network.
Enforcing LDAP Signing and Channel Binding
Since the most severe outcome of this attack path involves relaying authentication to LDAP, enforcing LDAP signing and channel binding on domain controllers closes the relay path even if an attacker successfully captures authentication through the DNS hijack portion of the attack.
Set-ADDomain -Identity target.local -Replace @{"msDS-LDAPServerSigningRequirement"="2"}This defense-in-depth approach, disabling unused IPv6 where possible and hardening LDAP where it cannot be, is exactly the kind of layered remediation guidance clients receive following an internal assessment through Sagefox Cybersecurity.
Common Mistakes Organizations Make with IPv6 Exposure
Assuming IPv6 Is Not a Risk Because It Is "Not in Use"
Many organizations believe that because they have not actively deployed IPv6, it poses no risk, without realizing that Windows hosts run IPv6 by default and will happily accept configuration from any device willing to offer it, whether or not the organization intended to use the protocol at all.
Disabling IPv6 Inconsistently Across the Environment
Partial IPv6 disabling, where some hosts have it turned off through Group Policy while others were missed due to inconsistent policy application, leaves gaps that a determined attacker will find during network enumeration regardless of the organization's overall intent to disable the protocol.
Overlooking IPv6 During Firewall and Monitoring Reviews
Security teams that build detection rules and firewall policies around IPv4 traffic patterns while leaving IPv6 traffic largely unreviewed create exactly the blind spot this attack depends on. A thorough security review needs to explicitly account for IPv6 traffic, not treat it as an afterthought.
Key Takeaways
The IPv6 DNS takeover attack succeeds because it exploits a protocol most organizations run without realizing it, monitor without configuring, and defend without actually intending to use at all. An attacker with nothing more than network access can hijack DNS resolution, capture NTLM authentication through WPAD, and relay that authentication directly into Active Directory, often achieving domain compromise before ever needing a single valid credential. Disabling unused IPv6, restricting WPAD where unnecessary, and enforcing LDAP signing together close off this entire attack chain.
If your organization wants a thorough internal assessment that specifically tests for IPv6-based attack paths alongside traditional Active Directory exposure, the team at Sagefox Cybersecurity can help identify and close this gap before an attacker finds it.
