IPv6 DNS takeover: whoever answers the Solicit first

02 Technical BreakdownFor engineers

DHCPv6 exists so IPv6 hosts can be told configuration they can't derive themselves, and DNS resolvers are the important half of that. The exchange is four messages:

client                                        anything listening
  |  SOLICIT   -> ff02::1:2 / udp 547               |
  |  <---------------------------  ADVERTISE / udp 546
  |  REQUEST   -> ff02::1:2                         |
  |  <---------------------------  REPLY

The options themselves are old and boring. Option 23 carries the recursive name server list and option 24 the domain search list, both specified in RFC 3646 back in 2003. Two other routes deliver the same information, and neither is verified either: DHCPv4 option 6 (RFC 2132), and the RDNSS and DNSSL options carried inside a router advertisement (RFC 8106, which updates RFC 6106). On a Windows estate the DHCPv6 route is the one that matters, because Windows prefers a DHCPv6-supplied resolver over anything an RA told it. Insinuator's lab work on the Windows 10 Creators Update found exactly that ordering, and it matches what RFC 8106 says should happen. On a mixed estate the RA door is the one to worry about, since Linux, macOS and most appliances accept a rogue RDNSS even where Windows wouldn't.

Nothing in that exchange authenticates the server. RFC 8415's security considerations say it plainly: DHCP "lacks end-to-end encryption between clients and servers", so hijacking is a design property rather than a bug, and the attack it names first is a malicious server "providing incorrect configuration information to the client" to mount a man-in-the-middle against "some service (such as DNS or NTP)". RFC 3646 had already predicted this exact finding three years earlier: the DNS option "may be used by an intruder DHCP server to cause DHCP clients to send DNS queries to an intruder DNS recursive name server". Its recommended mitigation was client-side authentication before installing a resolver list, which twenty-odd years later is still a SHOULD nobody implements. RFC 8415's only defined authentication protocol exists to protect the Reconfigure message, not the answer to a Solicit.

Two Windows defaults finish the job. IPv6 is enabled and preferred out of the box on everything since Vista, which Microsoft's own guidance states in as many words ("By default, Windows favors IPv6 global unicast addresses over IPv4 addresses", KB 929852), and the DHCPv6 client runs whether or not anyone deployed IPv6. You can see the preference on any host:

netsh interface ipv6 show prefixpolicies

The setting everyone reaches for, DisabledComponents = 0x20 ("prefer IPv4 over IPv6"), does not stop this. It flips those two precedences, which decides which address family you pick once a name has resolved, not which DNS server's answer you get. If the attacker's resolver answers faster than yours, prefer-IPv4 changes what you do with the reply, not who you asked. RFC 9099 disposes of the "we don't run IPv6" defence in one sentence: "it is possible even in an 'IPv4-only' network to attack L2-adjacent victims via their IPv6 link-local address or via a global IPv6 address when the attacker provides rogue RAs or a rogue DHCPv6 service."

The tooling is public, mature and small. mitm6, published by Fox-IT in 2018, sits on the interface, answers Solicit messages with a link-local address and itself as the resolver, and answers DNS selectively so normal traffic keeps working and nobody opens a ticket. It reads the FQDN option in the Solicit, which means it learns the hostname it is answering for. What the victim sees afterwards is one extra address and a new gateway:

# before, a Windows 10 box on an "IPv4-only" network
   Link-local IPv6 Address . . . . . : fe80::2527:53eb:9abd:8df2%15(Preferred)
   IPv4 Address. . . . . . . . . . . : 192.168.13.129(Preferred)
   DNS Servers . . . . . . . . . . . : 9.9.9.9

# after, once the attacker answered the Solicit
   Link-local IPv6 Address . . . . . : fe80::9900:1%15(Preferred)     <- attacker's lease
   Link-local IPv6 Address . . . . . : fe80::2527:53eb:9abd:8df2%15(Preferred)
   IPv4 Address. . . . . . . . . . . : 192.168.13.129(Preferred)
   Default Gateway . . . . . . . . . : fe80::b49f:39ff:fe37:9cd6%15  <- attacker

Then the second phase. Windows still looks up wpad when it wants to discover a proxy, and if the attacker is the resolver, the attacker gets to answer that lookup. The victim connects to the attacker's WPAD listener and authenticates to it in the enterprise's own name, and ntlmrelayx relays that authentication into LDAP, LDAPS or SMB. Practitioner write-ups of this chain describe the common endgame as relay into LDAPS plus abuse of resource-based constrained delegation on a target computer, which is a polite way of saying rights you were never supposed to have. The relay half is well understood; what unlocks it is the DNS half. No WPAD answer, no authentication. And the network reverts by itself when you stop: Fox-IT tuned the lease and lifetime values so the bad configuration ages out in minutes rather than days, which is why this doesn't have to wreck a client's week.

Two honest limits before the fixes. RA Guard is not a complete answer on its own: it is ingress-only, it needs TCAM support in hardware, it sees nothing in tunnelled IPv6 traffic, and it does not stop the extension-header bypass that RFC 9099 flags and somebody has already tooled. And nothing on the endpoint writes a neat "IPv6 takeover happened" event, so the detection surface is the network plus a configuration baseline you actually collect.