There might be one protocol quietly sitting in the background that many Cyber Security teams forget about: IPv6.
It’s often enabled by default, unmonitored, and rarely configured with the same precision as IPv4. And that’s exactly why attackers love it. When left unmanaged, IPv6 can open up a hidden pathway for man-in-the-middle (MitM) attacks, allowing someone to intercept traffic, reroute requests, or even harvest credentials without setting off alarms.
In this blog, we’ll break down how IPv6 misconfigurations create this risk, walk through how the attack actually unfolds in real environments, and share practical steps you can take to lock it down before it’s exploited.
Why Unmanaged IPv6 Is a Risk
IPv6 was introduced to solve a simple but critical problem: the world was running out of IPv4 addresses. While IPv4 uses 32-bit addresses (allowing around 4.3 billion unique addresses), IPv6 uses 128-bit addresses, offering an almost limitless number. It’s a huge improvement for scalability and most modern operating systems have IPv6 enabled by default, even if the wider network doesn’t actively use it.
The problem? Many organisations haven’t fully adopted IPv6 yet. They focus their defences around IPv4, leaving IPv6 either completely unmanaged or operating quietly in the background. Even if your business doesn’t think it’s using IPv6, it may still be active in the background. Unless your security posture is mature, with clear controls to mitigate IPv6 risks and verification through penetration testing, this exposure can easily go unnoticed.
How the IPv6 Attack Works
IPv6 attacks like this exploit the way devices automatically configure themselves when they join a network. The attacker doesn’t need to break encryption or exploit complex vulnerabilities; they simply take advantage of how IPv6 discovery works by default.
When a host connects to a network, it begins by asking a simple question: “Is there an IPv6 router out there?” This message, called a Router Solicitation (RS), is broadcast to the local network segment. It’s a normal part of IPv6’s Stateless Address Autoconfiguration (SLAAC) process, allowing devices to build their own IP address without needing manual configuration.
If an attacker is on the same local segment, they can respond with a malicious Router Advertisement (RA). This fake message tells every nearby host that a new IPv6 router is available, along with details about the network prefix and how to connect. The hosts, assuming this information is legitimate, automatically configure an IPv6 address and begin routing their IPv6 traffic through the attacker’s machine.
Once this happens, the attacker is sitting directly in the middle of the network flow. From here, things can escalate quickly.
The Turning Point: From Access to Exploitation
The fake RA can instruct victims to fetch additional settings via DHCPv6, such as which DNS server to use. An attacker on the link can run a rogue DHCPv6 service or inject RDNSS options, inserting their own device as the DNS server. From that moment, every DNS query the victim makes, whether to reach internal services or public sites can pass through the attacker first.
This is where the real damage begins. With control over DNS, the attacker can:
- Redirect traffic to look-alike or malicious hosts.
- Intercept requests to internal systems and capture sensitive data.
- Harvest or relay credentials from services using weak or plaintext authentication.
In short, the attacker gains visibility and influence over a victim’s communications while in many cases, users experience no disruption, though behaviour may vary depending on OS IPv6 preference settings. And because many organisations don’t actively monitor IPv6 traffic, this kind of attack can quietly persist for weeks or even months.
Even environments that believe they “don’t use IPv6” aren’t safe. If IPv6 is enabled by default, hosts will still send RS messages and accept RAs and all it takes is one attacker to answer first.
From DNS Control to Credential Theft
So the attacker controls DNS, now what? At this point they’ve turned a quiet misconfiguration into an active interception platform. DNS control doesn’t just let someone reroute web traffic; it creates realistic opportunities to capture authentication material and move laterally inside your estate.
Think about how many of your services still rely on legacy protocols or weak authentication flows. An attacker can take advantage of that in several ways:
- They can point internal hostnames to attacker-controlled IPs and present look-alike login pages that collect credentials directly.
- They can also transparently relay authentication attempts to the real service so the user never sees a warning and the authentication succeeds.
Common avenues for credential capture and misuse:
- Form-based capture and phishing look-alikes — victims are routed to a cloned portal and hand over usernames and passwords.
- Transparent credential relay — the attacker intercepts an NTLM/HTTP auth exchange and forwards it to the legitimate server, completing authentication on behalf of the victim. This is devastating when the target is a privileged account.
- Plaintext and misconfigured services — some internal services still send credentials in clear text (think legacy SQL connections, old APIs). If traffic is routed through the attacker, those secrets are trivial to harvest.
- Service impersonation — advertise an internal service (for example, an “SQL server” or file share). Servers and services may attempt to authenticate automatically, exposing machine or service credentials.
What’s the worst-case? If the attacker relays or captures a domain admin’s credentials, you’re looking at a full Active Directory compromise. That’s not theoretical; it’s a common escalation path in real engagements. One compromised admin hash or session can open up privilege escalation, domain replication, and persistence.
A Real-Life Example: When IPv6 Became the Attacker’s Gateway
We were on site, running routine checks, when something odd showed up in our packet captures. A web server kept trying to talk to an SQL host that didn’t quite exist, at least not where the app thought it did. Curious, we pushed a test: advertise an IPv6 prefix and behave like a router.
Within moments the server autoconfigured an IPv6 address from our prefix and started sending traffic our way. We announced an “SQL server” IP. The server connected and, to our surprise (and concern), sent its SQL username and password in plain text. No TLS. No IP whitelisting. Just credentials handed over like candy.
That one misstep, an unmanaged IPv6 plus plaintext auth gave us keys to the database and a fast route into sensitive data. It wasn’t glamourous. It wasn’t complex. It was painfully simple.
This engagement was a good reminder of how easily small oversights can align to create serious exposure. In this case, it wasn’t a complex exploit, just a few missteps quietly working together in the background.
It showed us that even when teams believe their environments are locked down, default configurations can still create unexpected pathways.
The lesson? Don’t underestimate what “low-risk” settings can do when combined. Make sure encryption is enforced, access is restricted, and IPv6 isn’t left to run unchecked. It’s often the simplest gaps that give attackers their opening.
Defending Against IPv6 Misconfigurations
If your organisation isn’t using IPv6, the simplest and safest option is to disable it entirely. Turning it off eliminates an entire attack surface that most monitoring tools won’t flag by default.
But if IPv6 is required it needs to be deployed securely and deliberately. Make sure it’s treated with the same attention as IPv4, not left to run on default settings.
Here are some steps to tighten your defences:
- Enable Router Advertisement (RA) Guard on switches to block rogue RAs from untrusted devices.
- Use DHCPv6 Guard to prevent unauthorised DHCP servers from responding to configuration requests.
- Monitor for unusual IPv6 activity, such as unexpected RAs, DHCPv6 announcements, or changes to DNS server configurations.
- Segment and restrict IPv6 traffic just as you would with IPv4, ensuring only approved routes and prefixes are allowed.
- Train IT teams to recognise the signs of IPv6-based MitM behaviour and to check for dual-stack configurations during audits.
IPv6 isn’t inherently insecure, it’s the lack of management that creates risk. The goal isn’t to fear the protocol but to bring it under control.
What We Can Learn
IPv6 might not be top of your priority list, but ignoring it could give attackers a way in you’ll never see coming.
Getting control of IPv6 doesn’t have to be complicated. With the right configuration, monitoring, and awareness, you can shut down this hidden pathway before anyone else finds it.
If you’d like to review your network setup or get advice from our experts, you can book a free 30-minute consultation or reach us directly at enquiries@equilibrium-security.co.uk or 0121 663 0055.
Ready to achieve your security goals? We’re at your service.
expertise to help you shape and deliver your security strategy.
About the author
