Friends Don’t Let Friends Disable IPv6

If you’ve ever been on the receiving end of an internal pentest, you’ve probably seen this one. Somewhere around page 40 there’s a finding about IPv6 DNS takeover, a screenshot of a tool called mitm6, a frightening diagram ending in “Domain Admin”, and a one-line fix: disable IPv6.

It sounds reasonable. You’re not using IPv6, so why leave it on? Untick the box, close the finding, go to the pub.

Please don’t. I’ve spent a fair bit of time on this recently, including breaking it in a lab, and there’s a better way that takes three firewall rules and doesn’t leave Windows in a state Microsoft tells you not to put it in.

What the attack actually is

Your network might be “IPv4 only”, but your Windows machines don’t know that. Out of the box they have IPv6 switched on, they prefer it over IPv4, and they regularly ask the network “is there a DHCPv6 server out there?”. On most networks, nobody answers.

So an attacker who’s already on your LAN answers instead:

1. They run mitm6, which replies to those DHCPv6 requests and hands your PC an IPv6 address plus, crucially, an IPv6 DNS server, which is the attacker.
2. Windows prefers that shiny new IPv6 DNS server over your real IPv4 one, so the attacker now gets to answer your DNS lookups.
3. They answer the lookup for wpad (proxy auto-discovery), pretend to be your proxy and ask your machine to authenticate.
4. Your machine helpfully sends NTLM authentication, which they relay to something that’ll accept it: LDAP on a domain controller, or your certificate services web enrolment page.
5. Depending on how well those are locked down, that can end with new computer accounts, delegation abuse or a certificate that says they’re someone important.

The original Fox-IT write-up is from 2018 and it still works on plenty of networks today. The important thing to notice is that IPv6 is just the delivery van. The actual problem is that something on your network will happily accept relayed NTLM. Hold that thought.

Why “just disable IPv6” is the wrong fix

Don’t take my word for it:

We don’t recommend that you disable IPv6 or IPv6 components or unbind IPv6 from interfaces.

Microsoft: Guidance for configuring IPv6 in Windows for advanced users

Microsoft treats IPv6 as a mandatory part of Windows. They don’t test with it turned off, and they warn that components may stop working if you disable it. That isn’t theoretical hand-wringing either:

• Failover clustering uses IPv6 link-local addresses between nodes, even when everything you can see is IPv4.
• Exchange and domain controllers both have documented examples of things breaking with IPv6 disabled.
• DirectAccess and RRAS depend on it, and Delivery Optimisation’s peer-to-peer mode can use it too.
• IPv6-only networks are a real thing now. Some mobile hotspots and guest networks only hand out IPv6. A laptop with IPv6 ripped out simply won’t get online there.

There are also two popular “fixes” that don’t do what people think they do:

• Unticking IPv6 on the network adapter only affects that one adapter. It does nothing for Wi-Fi, the VPN adapter, or the USB dock someone plugs in next week.
• The “prefer IPv4” registry setting (DisabledComponents = 0x20) only changes which address Windows picks when it has a choice. It doesn’t stop the machine accepting a rogue IPv6 DNS server, and that rogue DNS server can hand back an IPv4 address just as easily. It is not a fix for this attack.

What to do instead: three firewall rules

The attack needs your PC to accept IPv6 configuration from a stranger. So leave IPv6 itself alone and block the two ways that configuration arrives: DHCPv6 and Router Advertisements.

netsh advfirewall firewall add rule name="Block DHCPv6 In" dir=in action=block protocol=udp localport=546 remoteport=547 profile=any
netsh advfirewall firewall add rule name="Block DHCPv6 Out" dir=out action=block protocol=udp localport=546 remoteport=547 profile=any
netsh advfirewall firewall add rule name="Block IPv6 Router Advertisements In" dir=in action=block protocol=icmpv6:134,any profile=any

In plain English:

• DHCPv6 In drops replies from any DHCPv6 server, including the attacker’s.
• DHCPv6 Out stops your PC asking in the first place.
• Router Advertisements In closes the other door. Router Advertisements can carry a DNS server too, so blocking DHCPv6 on its own isn’t enough.

IPv6 stays bound, loopback (::1) still works, link-local still works, and Windows stays in a configuration Microsoft supports. All you’ve done is tell it to stop taking network settings from whoever shouts loudest.

The PowerShell version

Same rules, but with fixed names so they’re easy to find and remove later:

New-NetFirewallRule -Name 'FDLF-DHCPv6-In' -DisplayName 'Block DHCPv6 In' -Direction Inbound -Protocol UDP -LocalPort 546 -RemotePort 547 -Action Block -Profile Any
New-NetFirewallRule -Name 'FDLF-DHCPv6-Out' -DisplayName 'Block DHCPv6 Out' -Direction Outbound -Protocol UDP -LocalPort 546 -RemotePort 547 -Action Block -Profile Any
New-NetFirewallRule -Name 'FDLF-RA-In' -DisplayName 'Block IPv6 Router Advertisements In' -Direction Inbound -Protocol ICMPv6 -IcmpType 134 -Action Block -Profile Any

Check they’re really in force, and that nothing has handed you an IPv6 DNS server:

Get-NetFirewallRule -PolicyStore ActiveStore -Name 'FDLF-*' | Format-Table Name, Enabled, Profile, Direction, Action
Get-DnsClientServerAddress -AddressFamily IPv6

And if you need to back it out:

Remove-NetFirewallRule -Name 'FDLF-DHCPv6-In', 'FDLF-DHCPv6-Out', 'FDLF-RA-In'

For a real rollout, push the same three rules through Group Policy or Intune rather than running commands on each machine. Locally created rules can be ignored entirely if your policy turns off local rule merging, so always check what’s actually in effect.

The catches, because there are always catches

I’d be doing you a disservice if I pretended this was free.

It blocks the good guys too. These rules can’t tell your real router from a rogue one. If your network genuinely hands out IPv6 addresses, this will break that. It’s a fix for networks where IPv4 does the work and IPv6 is just sat there being exploitable. If you run proper IPv6, the answer is RA Guard and DHCPv6 Shield on your switches instead.

Laptops that travel need a decision. With profile=any the rules apply everywhere, including that IPv6-only hotspot, where the laptop now won’t connect. The alternative is profile=domain,private, which only applies the block on networks Windows classes as Domain or Private. That keeps hotel and coffee shop Wi-Fi working, but it means you’re unprotected on public networks, and a home network saved as Private still gets blocked. Neither is wrong. Just pick one on purpose.

It doesn’t clean up after an attack. If a machine has already been given a dodgy DNS server, adding the rules won’t remove it. The rules stop new rubbish arriving. They don’t take out the old.

Don’t get carried away and block all of ICMPv6. IPv6 needs a good chunk of it to function. Type 134 only.

Fix the real problem as well

The firewall rules buy you time and close this specific finding properly. The actual cure is making relayed authentication useless:

• Require LDAP signing and LDAP channel binding on your domain controllers. Audit first (Directory Service event 2889 shows you who’s still doing unsigned binds), then enforce.
• Require SMB signing on clients and servers.
• Turn on Extended Protection for Authentication on AD CS web enrolment and require HTTPS, or remove web enrolment if nobody uses it.
• Disable WPAD if you don’t use proxy auto-discovery.
• Set ms-DS-MachineAccountQuota to 0 so ordinary users can’t add computer accounts to the domain.
• Keep chipping away at NTLM generally. Microsoft’s own write-up on mitigating NTLM relay by default is a good place to start, and Server 2025 ships with several of these protections turned on.

The short version

• Don’t disable IPv6. Microsoft says not to, and things break in ways that are miserable to troubleshoot.
• “Prefer IPv4” and unticking the adapter box don’t stop this attack.
• Three firewall rules blocking DHCPv6 and Router Advertisements do, and I’ve tested it against mitm6.
• Only use them where you aren’t relying on IPv6 from your network, and decide what you want to happen on public networks.
• Then go and fix LDAP signing, channel binding and the rest, because that’s the bit that actually matters.

So the next time a report tells you to disable IPv6, you can politely say no, and show them something better.