Most network teams have checked the box: IPv6 disabled. But disabling IPv6 in Windows isn't actually what the default UI does. Unchecking the IPv6 adapter in network properties leaves the protocol stack fully alive inside the kernel. DHCPv6 solicitations are still sent, mDNS still runs, and link-local addresses are still auto-assigned. The checkbox is cosmetic. The attack surface remains.
How a rogue DHCPv6 server hijacks DNS on Windows networks
On any network segment where IPv6 traffic isn't actively filtered at the switch or firewall level, Windows machines continuously listen for DHCPv6 announcements on the multicast group ff02::1:2. No special configuration is needed on the victim side — this is default Windows behavior since Vista.
An attacker on the same segment can spin up a malicious DHCPv6 server, such as the one built into the tool mitm6. When clients send DHCPv6 solicitations, the rogue server responds with a link-local IPv6 address assignment and, critically, designates itself as the preferred IPv6 DNS server. The victim machine updates its DNS resolver configuration accordingly. From that point on, DNS queries can be routed through the attacker.
This isn't a Windows bug. It's RFC-compliant behavior. Windows natively prefers IPv6 over IPv4 when both are available, so once an IPv6 DNS response exists, it wins.
From poisoned DNS to NTLM relay
With DNS resolution under their control, the attacker can respond to any name query: internal shares, intranet web applications, SYSVOL, authentication servers. The victim machine attempts to authenticate against the spoofed destination using NTLM, Windows' challenge-response authentication protocol.
Two paths open from here. The first is capturing the NTLMv2 hash transmitted during the authentication attempt and cracking it offline using a dictionary or rule-based attack. The second path is more immediately effective: relaying the hash in real time toward a legitimate network target — LDAP or SMB on a domain controller, for instance. If the victim account has sufficient privileges and LDAP signing isn't enforced, the attacker can create machine accounts, modify ACLs, or read sensitive AD objects without ever knowing the cleartext password.
The tool ntlmrelayx from the Impacket suite handles this relay automatically. In a typical scenario, mitm6 manages the DHCPv6 announcements and fake DNS responses while ntlmrelayx receives incoming authentications and forwards them to LDAP on the DC. The entire chain can execute within minutes of an attacker plugging in to a network port.
Why partially disabling IPv6 doesn't protect you
This is where the gap between perceived and actual security becomes dangerous. Unchecking IPv6 in Windows network adapter properties does not remove the IPv6 stack. Link-local addresses (prefix fe80::) are still auto-configured on every interface. mDNS still operates. Router Advertisements are still processed.
Genuine IPv6 disabling on Windows requires setting the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\DisabledComponents to 0xFF, or deploying a GPO that unbinds IPv6 from all interfaces. Even then, if managed switches on the segment don't have RA Guard or DHCPv6 snooping enabled, other machines on the network remain exposed.
In heterogeneous environments — which are common across Moroccan enterprises and sub-Saharan African organizations where Windows 10 workstations, legacy 2012 servers, and unmanaged switches coexist — the partial disable approach is particularly risky. It creates a false sense of security while leaving the actual attack surface intact. The SOC and red team use cases trained on realistic Active Directory environments make this dynamic very visible: IPv6-based attacks succeed precisely where teams believe the protocol is off.
Defenses that actually work
Effective mitigation requires layered controls. At the network level, enabling DHCPv6 snooping and RA Guard on managed switches is the first barrier. These features block unauthorized DHCPv6 responses and Router Advertisements at the port level, preventing rogue server deployment on the segment.
Harden NTLM relay targets in Active Directory
On domain controllers, enabling LDAP signing and LDAP channel binding is non-negotiable. Both settings are disabled by default on Windows Server versions prior to 2019. With them enforced, a relayed NTLM authentication toward LDAP will be rejected even if the hash is valid. Configuration is straightforward through the Domain Controller: LDAP server signing requirements GPO setting.
Monitor for IPv6 anomalies in your SIEM
Detection rules should cover sudden DHCPv6 traffic on IPv4-only segments, unknown fe80:: addresses appearing in ARP or neighbor discovery tables, and NTLM authentication events toward unusual destinations. Without these specific correlation rules, the attack chain produces almost no alerts in default log configurations.
Enabling SMB signing across all domain workstations and servers closes off the SMB relay path. It's not an IPv6-specific measure, but it eliminates one of the most impactful exploitation routes downstream.
What this attack reveals about broader security posture
The DHCPv6 / NTLM relay chain is symptomatic of a wider pattern: treating unused protocols as nonexistent ones. IPv6 is running. LLMNR is running. NetBIOS over TCP/IP is running. On most unhardened Windows networks, all three can be abused to capture authentication material without any user interaction beyond a normal network login.
Static configuration reviews rarely catch this. Actively testing these vectors in a lab environment, then correlating what they look like in real telemetry, is what builds genuine detection capability. Running a cyber maturity diagnostic that includes lateral movement scenarios gives security teams a far more accurate picture of what an insider threat or compromised vendor could achieve in the first hour on the network.
Frequently asked questions
Does a Windows machine listen for DHCPv6 even when IPv6 appears disabled?
Yes. Unchecking IPv6 in the network adapter properties dialog does not remove the IPv6 stack from the Windows kernel. Link-local addresses are still assigned automatically and DHCPv6 solicitations are still sent. Full disabling requires a registry change or a dedicated Group Policy Object.
Does the attacker need to crack the NTLM hash for this attack to succeed?
No, and that's what makes it particularly effective. NTLM relay uses the captured hash directly against another target on the network without ever decrypting it. If LDAP signing is not enforced on the domain controller, the attacker can operate in Active Directory with the victim's privileges.
Is DHCPv6 snooping enough as a standalone protection?
It's a necessary layer but not sufficient on its own. It should be combined with LDAP signing, SMB signing, and the disabling of LLMNR and NetBIOS over TCP/IP. Each control removes one step from the attack chain; the combination makes the full chain impractical.
Can a standard SIEM detect this attack?
It can, but only with specific correlation rules in place: DHCPv6 traffic on IPv4-only segments, unknown link-local addresses in neighbor tables, and NTLM authentication events pointing to unlisted destinations. Without those rules, the attack produces almost no signal in default Windows event logs.