DHCPv6 spoofing and WPAD: when a network "without IPv6" becomes a way in
"We don't use IPv6." That is often true for the network team, but not for Windows machines, which enable IPv6 by default and keep asking for it. On a network where nobody answers those requests, an attacker can step in instead of a legitimate server.
How it works
At startup and at regular intervals, a Windows machine sends DHCPv6 solicitations to obtain an IPv6 configuration. On an IPv4-only network, no answer comes back. An attacker on the same segment can answer in place of a legitimate server and give the machine an IPv6 address and an IPv6 DNS server: their own. Because Windows prefers IPv6 over IPv4 by default, this rogue DNS server takes priority for many queries. Forged Router Advertisement messages can have a similar effect.
WPAD, the missing piece
Once in control of the client's DNS, the attacker answers, among others, Web Proxy Auto-Discovery (WPAD) queries. The client then fetches a proxy configuration pointing to the attacker's machine and authenticates to it with NTLM in order to browse. That authentication can be relayed to LDAP or LDAPS on a domain controller, or to other services that require neither signing nor channel binding. Depending on the relayed account's rights, the attacker can then change directory objects, for example create a computer account or tamper with a machine's delegation settings. All of this without any password or software vulnerability.
Don't disable IPv6 blindly
The instinctive response is to disable IPv6 across the fleet. Microsoft advises against it: Windows is tested with IPv6 enabled and some components rely on it, even locally. Unbinding IPv6 from network adapters can cause unpredictable behaviour. When the goal is to reduce IPv6 usage, Microsoft instead recommends configuring the prefix policy to prefer IPv4 over IPv6 (the DisabledComponents value documented by Microsoft). That setting changes preference order but does not, on its own, stop a spoofed DHCPv6 configuration from being accepted, so it needs complementing.
Countermeasures that work
- On the network: enable RA Guard and DHCPv6 Guard (or their equivalents) on access switches, so that router advertisements and DHCPv6 replies are only accepted from legitimate ports.
- On clients: through Windows Firewall managed by Group Policy, block inbound DHCPv6 replies and inbound router advertisements where IPv6 is not used, testing on a pilot group first.
- For WPAD: if no proxy is auto-discovered, turn off automatic settings detection by policy; otherwise publish a legitimate, protected WPAD record, and keep
wpadin the DNS global query block list if you don't use it. - Against relay: require LDAP signing and LDAPS channel binding on controllers, SMB signing, and limit the number of computer accounts users can create (
ms-DS-MachineAccountQuota).
Deploying IPv6 is an option too. A network where IPv6 is actually managed, with legitimate DHCPv6 servers and routers and switch-level protections, leaves far less room for spoofing than one where IPv6 is enabled but ignored.
What an audit checks
- unmanaged DHCPv6 traffic and router advertisements on user segments;
- RA Guard and DHCPv6 Guard protections on access switches;
- WPAD configuration on clients and in the DNS zone;
- LDAP signing, channel binding and SMB signing requirements, and the value of
ms-DS-MachineAccountQuota.