SLAAC Attack – 0day Windows Network Interception Configuration Vulnerability

April 4, 2011 by Alec Waters

Windows machines compromised by default configuration flaw in IPv6

As anyone who has watched the reimagined Battlestar Galactica will tell you, Sixes are trouble. They are undoubtedly alluring, but all the while they are working covertly, following The Plan, right under the noses of their targets. Nobody realizes the true nature of the threat until it’s too late.

The Internet also has its own Six, IPv6 (formerly IPng – IP Next Generation). Modern operating systems ship with it by default, but adoption has been slow for many reasons. Despite the passing of the IPocalypse, it lies largely dormant within today’s networks, waiting for the chance to rise up and usurp its IPv4 predecessor.

This article describes a proof of concept of an interesting application of IPv6. I’m going to show you how to impose a parasitic IPv6 overlay network on top of an IPv4-only network so that an attacker can carry out man-in-the-middle (MITM) attacks on IPv4 traffic.

This new SLAAC Attack, if you will, is named for the process it is exploiting.

IPv6 Background

Aside from the increased address space, IPv6 is fundamentally different to IPv4 in several key areas. This article isn’t intended to be an IPv6 primer, but I’ll highlight the main features that are relevant to the attack.

Firstly, IPv6 does not use ARP – instead, there are a set of neighbor discovery protocols implemented over ICMPv6 that allow hosts to discover the physical addresses of others on the local link. Also, routers routinely advertise their presence on the local link by multicasting Router Advertisement (RA) messages.

When an IPv6-aware host receives an RA, it can derive itself a valid routable IPv6 address by means of a process called Stateless Address Auto Configuration (SLAAC). The host will use the source address of the RA as its default gateway.

In as much as it facilitates automatic host addressing, SLAAC sounds a lot like DHCP in the IPv4 world. However, SLAAC alone can’t supply all of the configuration parameters that a host might need (DNS servers, for example), so DHCPv6 is still needed to fill the gaps. It turns out that you need RA, SLAAC and DHCPv6 to accomplish for IPv6 what DHCP alone can do for IPv4, but that’s another story. Much more is covered in our Ethical Hacking training course.

Theory of Operation

This proof of concept targets Windows 7 hosts, but the theory ought to apply to any operating system that ships with IPv6 installed and operational by default. Let’s start with a diagram of the target network:

Pretty straightforward stuff; everything’s IPv4, and the border router is performing the usual NAT and firewall tasks. Let’s also assume that various countermeasures are in place to thwart conventional IPv4 MITM techniques such as ARP spoofing.

What we’re going to do is physically introduce a router, evil-rtr, to the target network. evil-rtr has two network interfaces – the victim facing interface is IPv6 only, and the Internet connected interface is IPv4 only. Our aim is to use evil-rtr to create a parasitic IPv6 overlay network that’s totally under our control, as shown by the tinted area in the diagram below:

evil-rtr will send RAs to the local network which will cause the hosts to derive routable IPv6 addresses for themselves. It is also equipped with a DHCPv6 server to supply the address of a recursive DNS server that’s under our control (evil-DNS in the diagram above). What we have not done is connect our IPv6 overlay network to the IPv6 Internet – evil-rtr only has a connection to the IPv4 Internet.

The Special Sauce

The changes made by introducing evil-rtr are pretty benign so far. Thanks to evil-rtr’s RAs, all the target hosts have routable IPv6 addresses in addition to their IPv4 ones, plus the address of a DNS server. This isn’t enough to do anything useful – we need another ingredient to progress the attack.

The “special sauce” is NAT-PT, an idea that’s so riddled with issues and caveats that it’s been consigned to the trashcan of history by the IETF. However, just because it’s an obsolete mess doesn’t mean it can’t be useful.

NAT-PT is one of the many IPv4-to-IPv6 transition mechanisms that have been devised to ease migration from the old to the new. Its job is to allow islands of IPv6 hosts to communicate with IPv4 hosts by translating IPv6 addresses into IPv4 addresses and vice versa. There’s a writeup here that shows its intended operation. It’s NAT-PT that allows our IPv6-addressed victims to access the Internet through evil-rtr’s IPv4 interface.

To use NAT-PT you need to define an off-link /96 prefix; it can be pretty much any routable prefix you like. Any destination addresses seen by NAT-PT which match this prefix are interpreted as IPv6 addresses with a destination IPv4 address embedded in the last 32 bits.

For example, I might tell my NAT-PT box that the prefix I’m using is 2001:6f8:608:ace::/96. The IPv6 address of the DNS server that we’re going to give out via DHCPv6 is 2001:6f8:608:ace::c0a8:5802 – this address matches the specified prefix, so if NAT-PT sees traffic destined for it the last 32 bits (c0a8:5802) will be extracted and translated into the DNS server’s true IPv4 address of

The Garnish on the Special Sauce

We’re nearly there. With NAT-PT in place, evil-rtr is now providing a working path from the IPv6 victims to the IPv4 Internet. If we can cause the victims to pump IPv6 traffic through evil-rtr (instead of sending IPv4 through the legitimate border router) we can have our SLAAC Attack fun. It turns out that this is quite straightforward.

Thanks to evil-rtr, our victims have both IPv4 and IPv6 addresses; they are “dual stacked”. Dual stacked hosts will prefer to use native IPv6 where available, so we’re half way there already. The final garnish that will take us the rest of the way is DNS.

The dual stacked victims have an IPv4 DNS server (courtesy of the legitimate DHCP server) and an IPv6 DNS server (courtesy of evil-rtr’s DHCPv6 server). When one of the victims tries to look up www.google.com, it will send a DNS query to its IPv6 DNS server for both A (IPv4) and AAAA (IPv6) records. If the IPv6 DNS server can return results in a timely enough fashion, the victim will pick the IPv6 address over the IPv4 one if the former is present. It is this behaviour we will rely on to lure traffic through evil-rtr. Our IPv6 DNS server has to be quick, though – if it takes too long to reply, the victim will fall back to using the legitimate IPv4 DNS server instead, and no traffic will pass through evil-rtr.

But how can we make sure that any given DNS query always returns an IPv6 address?

NAT-PT implementations usually include a set of Application Layer Gateways (ALGs) which inspect traffic that has IP addresses carried within the application layer protocol. DNS is an example of a protocol that requires an ALG, as is FTP. Here’s what the IPv6 DNS transaction looks like with NAT-PT and the DNS ALG working their magic:

Things to note:

  • The address of the victim’s DNS server matches the NAT-PT prefix on evil-rtr, denoting that the last 32 bits contain the DNS server’s IPv4 address.
  • NAT-PT translates the source and destination IPv6/IPv4 addresses in both directions.
  • The DNS ALG translates the victim’s AAAA query for an IPv6 address into an A query for an IPv4 address and vice versa on the way back.
  • The DNS ALG also translates the IPv4 address in the reply to an IPv6 address that matches the NAT-PT prefix.

As far as the victim is concerned, www.google.com is reachable via IPv6 at 2001:6f8:608:ace::d155:8f63. It has absolutely no idea that IPv4 is involved in any way. The victim will therefore contact Google like this:

evil-rtr is therefore now a man-in-the-middle between the victim and Google.

To summarize the story so far:

  • We have not compromised or altered the operation of the victim’s IPv4 network, as we would have needed to do in order to MITM IPv4 traffic. We’ve not even needed to get an IPv4 address from their DHCP server.
  • We have not compromised an existing IPv6 network, because there wasn’t one before we arrived.
  • We have not compromised any given victim host (yet!). Each machine is behaving as designed and is choosing IPv6 over IPv4 of its own volition.
  • We have managed to totally alter the flow of traffic on the victim’s network by awakening the hosts’ latent desire to use IPv6 over IPv4.

The attack is also reasonably stealthy, since:

  • We’re introducing a new path to the Internet. Any defences or monitoring employed at the network’s IPv4 boundary are therefore ineffective and will raise no indicators of compromise.
  • There’s a chance that the victim’s security systems (e.g., host firewalls, HIPS, SIEM boxes, etc.) won’t be able to handle IPv6 traffic. IPv6 support on such systems is rarely as mature as its IPv4 equivalent.
  • Since the victims “aren’t using IPv6” they won’t be expecting an attack that makes use of it.
  • If the above is true, there’s a chance their Incident Response teams won’t have the necessary training and experience with IPv6 to deal with an incident that uses it.

Building evil-rtr

It doesn’t take much to implement evil-rtr. Only three packages are needed, namely radvd, dhcp6s, and naptd. Before we get these up and running, we need to set up our interfaces. In this example, eth0 is the Internet-facing IPv4 interface, and I’m going to assume that it can use a DHCP server somewhere to get an address. eth1 is the IPv6 interface, which we’ll configure like this:

root@evil-rtr:~# ifconfig eth1 inet6 add 2001:6f8:608:fab::1/64
root@evil-rtr:~# ifup eth1
root@evil-rtr:~# ifconfig eth1
eth1      Link encap:Ethernet  HWaddr 00:25:4b:fd:91:73
inet6 addr: 2001:6f8:608:fab::1/64 Scope:Global
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

We also need to make sure that IPv6 forwarding is turned on:

root@evil-rtr:~# sysctl -w net.ipv6.conf.all.forwarding=1
net.ipv6.conf.all.forwarding = 1

Now we can install our IPv6 toys.


This package is responsible for sending RAs to our victim hosts, and can be obtained here. The configuration file is quite straightforward:

interface eth1 {
AdvSendAdvert on;
AdvOtherConfigFlag on;
MinRtrAdvInterval 3;
MaxRtrAdvInterval 10;
prefix 2001:06f8:0608:fab::/64 {
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr on;

The important parts are the link prefix and the setting for AdvOtherConfigFlag. Setting this to “on” will set the O flag in the RAs. The O flag tells a client that it should also try to contact DHCPv6 for further configuration. Fire up radvd according to the documentation, and move on to…


I downloaded the WIDE DHCPv6 server from here. We have very little to hand out via DHCPv6, so the configuration file has just two lines:

option domain-name-servers 2001:6f8:608:ace::c0a8:5802;
option domain-name "pwned.by.v6";

Start it up, and move on to…


Get it here. Following the excellent documentation, we need to configure iptables and ip6tables like this:

root@evil-rtr:~# ip6tables -A OUTPUT -p icmpv6 --icmpv6-type 1 -j DROP
root@evil-rtr:~# ip6tables -A FORWARD -d 2001:6f8:608:ace:: -j DROP
root@evil-rtr:~# iptables -A INPUT -i lo -j ACCEPT
root@evil-rtr:~# iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT
root@evil-rtr:~# iptables -A INPUT -m state --state NEW -p tcp -m tcp --dport 22 -j ACCEPT
root@evil-rtr:~# iptables -A INPUT -j DROP

Then we can run napt-confmaker. I answered pretty much every question with the default answer, apart from the interface selections and the NAT-PT prefix.

Once we start naptd running, the trap is set.

The Attack

This is what the output of ipconfig looks like on the victim host before evil-rtr’s IPv6 interface is connected to the network:

Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix  . :
Description . . . . . . . . . . . : Atheros AR8131 PCI-E Gigabit Ethernet Controller (NDIS 6.20)
Physical Address. . . . . . . . . : 00-26-9E-47-4E-0F
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . : fe80::119c:ea76:23d4:290d%10(Preferred)
IPv4 Address. . . . . . . . . . . :
Subnet Mask . . . . . . . . . . . :
Lease Obtained. . . . . . . . . . : 30 March 2011 23:23:08
Lease Expires . . . . . . . . . . : 31 March 2011 13:55:33
Default Gateway . . . . . . . . . :
DHCP Server . . . . . . . . . . . :
DHCPv6 IAID . . . . . . . . . . . : 285221771
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-12-52-C9-D5-00-26-9E-47-4E-0F
DNS Servers . . . . . . . . . . . :
NetBIOS over Tcpip. . . . . . . . : Enabled

The presence of a link-local IPv6 address confirms that the host is IPv6-capable. Once we connect evil-rtr’s eth1 interface, the victim host sees the RAs, derives a routable IPv6 address for itself, then queries DHCPv6 for further configuration. Almost immediately, the output of ipconfig will change to look like this:

Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix  . : pwned.by.v6
Description . . . . . . . . . . . : Atheros AR8131 PCI-E Gigabit Ethernet Controller (NDIS 6.20)
Physical Address. . . . . . . . . : 00-26-9E-47-4E-0F
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IPv6 Address. . . . . . . . . . . : 2001:6f8:608:fab:119c:ea76:23d4:290d(Preferred)
Temporary IPv6 Address. . . . . . : 2001:6f8:608:fab:687a:83f:caa7:8f9c(Preferred)
Link-local IPv6 Address . . . . . : fe80::119c:ea76:23d4:290d%10(Preferred)
IPv4 Address. . . . . . . . . . . :
Subnet Mask . . . . . . . . . . . :
Lease Obtained. . . . . . . . . . : 30 March 2011 23:23:08
Lease Expires . . . . . . . . . . : 31 March 2011 13:55:33
Default Gateway . . . . . . . . . : fe80::225:4bff:fefd:9173%10
DHCP Server . . . . . . . . . . . :
DHCPv6 IAID . . . . . . . . . . . : 285221771
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-12-52-C9-D5-00-26-9E-47-4E-0F
DNS Servers . . . . . . . . . . . : 2001:6f8:608:ace::c0a8:5802
NetBIOS over Tcpip. . . . . . . . : Enabled
Connection-specific DNS Suffix Search List : pwned.by.v6

It’s game over for the poor victim host:

  • It has routable IPv6 addresses of its own
  • It has an IPv6 default gateway, which is actually the link-local address of evil-rtr’s eth1 interface rather than the address we manually gave it earlier on.
  • It has an IPv6 DNS server whose address matches the NAT-PT prefix used by naptd, and which will be translated into the IPv4 address of evil-DNS.

We have successfully awakened the victim’s latent desire to use IPv6 in preference to IPv4. We’ve not needed any passwords, hacks or brute force. All we had to do was nudge the victim in the right direction.

Poetry in Motion

When the victim browses to www.google.com, evil-rtr’s IPv6 eth1 interface sees this (download capture):

You can see the DNS queries sent via IPv6 to evil-DNS; both A and AAAA queries are sent, and IPv4 and IPv6 addresses delivered in response. Note that the returned IPv6 address matches our NAT-PT prefix, indicating that it has an embedded IPv4 address. The victim will choose to use this IPv6 address over the IPv4 one; evil-rtr is the man-in-the-middle.

The same transaction on evil-rtr’s IPv4 eth0 interface looks like this (download capture):

Note that all the IP addresses are IPv4, and all the DNS queries are all for A records instead of the mix of A and AAAA that we saw on eth1.

Developing the Attack further

There are several things we can do to take the attack further:

  • Given that this attack uses implanted hardware, we can make it really really tiny. Gumstix is an ideal platform; they’re small, they run Linux, and there’s a wide range of hardware on offer. An Overo Earth, a Tobi, and a 3G USB stick would give you a very small platform with an Ethernet interface to attach to the target network and an autonomous Internet connection. I’ve used Gumstix before; once you’ve got the build environment set up, the world’s your oyster.
  • We control evil-DNS, so we can make it return any IP address we like for www.google.com, thereby opening up numerous opportunities for phishing.
  • In its current state, evil-rtr will MITM all traffic that is the result of a DNS query; this isn’t exactly subtle. If we can make evil-DNS return addresses only for sites of interest we can be a good deal more selective. If we can make evil-DNS ignore requests we don’t care about, the victim will fall back to their IPv4 DNS server and traffic will flow as normal.
  • As we are the man-in-the-middle, we have the opportunity to interfere with the traffic between the client and the server. We could inject malicious iframes, change https:// links to plain old http:// links, etc, etc.
  • <insert other creative evil here>

Defending against evil-rtr

The attack is possible because we were able to inject RAs onto a network of IPv6-capable hosts – the key differentiators between this attack and other similar ones is that we are not trying to subvert an existing IPv6 network; we are instead trying to build a new one out of nothing. Nevertheless, our rogue RAs were the catalyst for the successful attack. If we can stop them in their tracks, the attack will go nowhere.

Most of the time, rogue RAs are nothing more than a nuisance, often generated as a result of something as simple as turning on Windows’ Internet Connection Sharing. However, it is a serious enough issue for the IETF to put together RFC6104, the “Rogue IPv6 Router Advertisement Problem Statement”. This document is more concerned with brokenness caused by “accidentally-rogue” RAs than it is with security issues, but Section 3 gives a useful list of mitigation techniques. Sadly, most of these are difficult to employ either due to the lack of a suitable implementation (e.g., SEND), or a lack of capable hardware (e.g., RA Guard or switch ACLs). Cisco also have some tips on first hop security here and here.

If the attack can’t be prevented by the methods listed in RFC6104, perhaps it can be detected instead. NDPMon is an IPv6 equivalent to ArpWatch and is designed to detect suspicious neighbour/router discovery traffic.

However, neither RFC6104 nor NDPMon will help to defend against a SLAAC Attack. Why would anyone deploy IPv6 countermeasures when they “aren’t using” IPv6? A SLAAC Attack targets IPv6-capable IPv4 networks, not native IPv6 or dual stack ones. The most effective defence is simply to disable IPv6 on all capable hosts if there’s no business reason to use it:

This is in complete alignment with the “Minimized” principle of the Defensible Network, but doesn’t exactly foster the accelerated adoption of IPv6. I know which way I’d jump!

Hands-on labs on the SLAAC attack are being added to courses at InfoSec Institute. If you need IT Security training, check out our ethical hacking, computer forensics, reverse engineering courses, CCNA certification class or CSSLP training. Online IT Security training is also available.


Introduction to IPv6 addressing and configuration

Posted: April 4, 2011
Alec Waters
View Profile

Alec Waters is a security researcher for InfoSec Institute and a network security specialist working for Dataline Software in the UK. Working with defense and healthcare clients, his focus is on incident response, network forensics and secure infrastructure design.

40 responses to “SLAAC Attack – 0day Windows Network Interception Configuration Vulnerability”

  1. David says:

    nice mitm technique

  2. Very good article. And it shows the importance of knowing what goes on in your network…

    Either properly configure your network for IPv6 or at least take IPv6-related security measures (rogue RA detection or even better -protection), or disable unused protocols (including IPv6) and make sure that they are disabled on every host.

    Personally I prefer the first: IPv6 is here, enabled by default on all recent operating systems and even preferred over IPv4. Whether you like it or not, you have to deal with it.

  3. David Farmer says:

    This is by no means a 0day attack, this has been a well known attack vector for some time. This is demonstrated by the work on the RFC 6104 in the IETF.

    It is good to raise the awareness of this issue. However, IPv6 is the future of the Internet, and in the near future the Internet will not be able to continue to grow without it. Therefore, the proposed mitigation of turning off IPv6 is equivalent of telling people to put there heads into the sand.

    Turning off IPv6 is at best a short term solution, and may only create a false sense of security. It is difficult to insure all computers have IPv6 turned off, as more and more OSes have it turned on by default.

    A better solution is to embrace IPv6 and begin to implement and manage IPv6 in your networks.

  4. Joe Klein says:


    Just an FYI, examples of IPv6 addresses for documentation purposes such as user manuals, RFCs, blog postings, etc, are expected to use the address 2001:db8::/32, based on RFC3849. So what is the justification, besides following an RFC? Best practice for IPv6 is to block this address range outbound at the firewall/router, allowing network/system admin to repeat and test configuration they find in documentation.

    Joe Klein

  5. Michael Sinatra says:

    I agree with Dave Farmer–this isn’t new at all and it’s pretty misleading to call it a 0day. It’s nice that you went to the trouble to demonstrate its feasibility, but I don’t think anyone has doubted that it could be done this way.

    What your article does do very nicely is to show (once again, but it’s good to keep hammering this point) that you do not need to be “running” IPv6 in your production network to be vulnerable. In fact, you are probably more vulnerable if you are not officially running IPv6. Network and security people can’t avoid IPv6 security issues by avoiding IPv6.

    Deploying IPv6 and getting used to it and all of its features and issues is critical–and it needs to be done now.

  6. Jerry says:

    Wow, a bit sensational. Not new, and not very hard to detect if you are current with technology.

  7. True, it’s not a 0day attack, but it does help to demonstrate how important it is not to ignore IPv6. Which is what a lot of smaller networks are doing (small/medium business, part of the edu space, etc).

  8. Ray Soucy says:

    Poor research before posting this.

    It’s a well known security concern within the IPv6 community and has been for the past few years. It’s not a “zero day” since it’s the design of IPv6 to permit this.

    Best practices for IPv6 deployment have included monitoring for rogue RA and filtering rogue RA at the port level.

    If you would have gone one RFC number up you would have found the RFC for RA Guard (RFC 6105) which is essentially a standard for filtering unauthorized RA.

    Using Cisco hardware its easy enough to filter rogue RA and rogue DHCPv6 server traffic.

    Here’s an example:

    On the switch:

    ipv6 access-list RA_Filter
    deny icmp any any router-advertisement
    deny udp any eq 547 any eq 546
    permit any any

    On each non-uplink port:

    ipv6 traffic-filter RA_Filter in

    There you go.

    Hopefully if anything this post will bring awareness that IPv6 can’t be ignored.

    It’s a story we’ve been trying to tell for years:

    Just because you haven’t deployed IPv6 doesn’t mean it’s not running on your network.

    People need to get up to speed and learn how to secure IPv6.

    Unfortunately the way this post is written it just sounds like IPv6 is the security problem and will likely prevent people from adopting it sooner rather than later.

  9. Arc says:

    Just an FYI, IPv6 get re-enabled after a reboot in Windows 7 if it is disabled in the way shown. You have to disable it from the registry. I don’t think it has been patched yet.

    You can see how to disable it here:

    and here:

  10. Alec Waters says:

    Hello Ray,

    The article did mention RA Guard and switch ACLs. I fully acknowledge best practice for IPv6 deployments, but the point is that the target of this attack is not an IPv6 network, but an IPv4 network.

    Keeping that in mind, why would an operator of an IPv4 network deploy IPv6 countermeasures ahead of time? Why would they even research the issue if they’re “not using IPv6”?


  11. Alec Waters says:

    Hi Arc,

    Thanks for the links!


  12. Alec Waters says:

    A comment from Johannes Ullrich over at SANS ISC:



  13. Jack says:

    To Ray –

    I think that the point most people are missing is that the target of the attack isn’t an IPv6 network – these can be defended with RA Guard, switch ACLs, etc, all the good stuff from the cited(!) RFC 6104. The target is an IPv4 network where I would imagine it is very unlikely that these IPv6-specific countermeasures have been deployed. Johannes Ullrich was one of those who “got it” : https://twitter.com/#!/johullrich/status/55096958074884096

  14. John Mann says:

    IPv6 is similar to IPv4 for local LAN security.

    For IPv4 you should block rogue ARPs and rogue DHCP servers.

    For IPv6 you should block rogue RAs and rogue DHCPv6 servers.

    And do bpdu-guard to stop un-managed switches or access points being added to your network.

    Although preventing this attack, I disagree with the general inference that turning off IPv6 on a NIC card turns off IPv6. You have left tunneled IPv6 enabled.

    “… disable IPv6 on all capable hosts if there’s no business reason to use it”
    The business case for IPv6 is the continued growth and innovation of the Internet. Ignore that at your peril.

  15. washam says:

    Since NAT-PT has been deprecated by IETF. I think NAT64 and DNS64 can achive the same effect.
    the linker for NAT64:http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-stateful
    the linker for DNS64:http://tools.ietf.org/html/draft-ietf-behave-dns64

  16. Other people have pointed the fundamental flaw in this article (there is nothing new, and the problem is not IPv6-specific, it is a general issue of LAN protocols, unless you force IPsec onto everybody). But I want to report an error coming from ignorance: the article says “SLAAC alone can’t supply all of the configuration parameters that a host might need (DNS servers, for example)” which is very untrue.

    The standard for supplying this DNS configuration was first RFC 5006, more than three years ago. It was replaced by RFC 6106 recently. It is widely implemented, for instance, the CPE shipped by Free (second largest ISP in France) all send DNS info in their SLAAC.

  17. Alec Waters says:

    Hi Stéphane,

    I apologise for my ignorant error. The source of my ignorance is the article I cited here, which says that “(RFC 6106) is rarely implemented in desktop operating systems”. Perhaps this statement isn’t accurate.

    Based on the above link, I implemented DHCPv6 because I was certain Windows 7 would use it; I was less certain that Windows 7 would listen to DNS options in RAs. As such, I felt that by using DHCPv6 I would have a greater assurance that the target machine will end up using evil-DNS.

    In any case, it’s all just a proof of concept. If you want to use RFC6106 instead of DHCPv6, or if you want to try DNS64 and NAT64 as suggested by washam, you can probably achieve the same effect.


  18. If the network you are in blocks outgoing DNS queries (over UDP 53) except from an allowed DNS server, then this doesn’t work at all. In fact, virtually any enterprise network I’ve seen w/ a secure DNS infrastructure does this.

  19. Alec Waters says:

    Hi Jeremy,

    The PoC above has evil-RTR with its own IPv4 Internet connection via 3G. It doesn’t matter what kind of outbound filtering the target network uses in this case – all MITM-ed traffic (including DNS) goes over evil-RTR’s own Internet connection.


  20. Alec Waters says:

    For Joe Klein:

    2001:6f8:608::/48 is my own prefix.


  21. reinfallt says:

    I just tried this and it works like a charm. I was wondering if/how you can combine this with a ssl proxy attack?

  22. Alec Waters says:

    Hi reinfallt,

    I was toying with using SSLStrip or similar on evil-RTR’s IPv4 interface. I don’t know if it will work properly with naptd, but it might be a good start.


  23. unixfreaxjp says:

    Nice paper. Great work. Allow me to link to this as reference.

  24. Alec Waters says:

    Thankyou 🙂


  25. Janos Mohacsi says:

    The article is describing an important issue. It was already known a while ago. Documented in RFC 6104, and can be contermeasured as described in RFC 6105.

    The SLAAC and RA can be enough alone to get DNS as described in RFC5006.

    This not a windows7 issue as the title suggest

    You should completly disable IPv6 if you don’t support in your network or provide native IPv6 to your clients. Similar trick could be used with Netbios…..

    Refer to NAT64 and DNS64 instead of NATPT.

  26. Stefano says:

    I’m not able to replicate this. Does windows change its default gateway to the Link-Local address of evl-rtr just after receiving the RA? If the answer is yes then something is wrong on my setup..could you please clarify this to me?

  27. Alec Waters says:

    Hi Stefano,

    Yes, that’s the behaviour I observed. Are you getting an IPv6 default gateway? What is it?


  28. Stefano says:

    Hi alec!
    I have now a plain Windows 7 with no updates on a virtual machine and it works. I have a messy installation on the windows 7 host so maybe the problem is that, or could it be some updates from microsoft? Does this attack work even on the most recent Windows 7 version?

  29. Alec Waters says:

    Hi Stefano,

    As far as I’m aware, this should work on just about any OS that has IPv6 enabled by default.


  30. Stefano says:

    ‘@Alec: NAT-PT isn’t stricly necessery, am I correct? I could use evl-rtr as DNS and also as web server if I wanted and let it reply to IPv6 http requests so no translation is required.

  31. Alec Waters says:

    Hi Stefano,

    Yes, I think you could do something like that.


  32. Duncan says:

    I have replicated the setup described in the above article by following the steps described in the article and have observed the following results:

    The above attack does not appear to work with Windows 7 hosts which have automatic updates applied. While Radvd does make the Windows7 target configure a global IPv6 and temporary IPv6 address on top of the link-local IPv6 address, there is no DNS server IPv6 value inside the DNS server list which replaces the IPv4 servers already present on the Windows 7 target, unlike what is presented in the article’s “output of ipconfig” screenshot. Additionally, there is also no “connection-specific DNS suffix” or “DNS suffix search list” entry value populated as displayed by the ipconfig/all command as opposed to what is presented inside the article’s post-attack ipconfig screenshot.

    Also, the article screenshot displaying the “ifconfig eth1” command which shows that there is only 1 inet6 address needed for the eth1 interface (i.e. inet6 addr: 2001:6f8:608:fab::1/64 Scope:Global) in order to run Radvd is not borne out during testing.
    Radvd will not even start up if there is no local link address configured (i.e. a fe80-based address of Scope:Link) for the IPv6-assigned interface, let alone send out RAs. There must be _BOTH_ a Link-scoped IPv6 address and a Global-scoped IPv6 address present otherwise Radvd will give an “error parsing or activating the config file: /etc/radvd.conf” (its words, not mine).
    Given this observation, the ifconfig eth1 display as described in the article is thus not realistic for the purposes of executing Radvd successfully. Note that the article’s “output of ipconfig” screenshot shows a default gateway of “fe80::225:4bff:fefd:9173” – where did this come from if the eth1 address does not have this link-scope address configured which would have been shown when the “ifconfig eth1” command was run?

    Thus, based on the actual replication of the steps described in this article against a Windows 7 target with automatic updates enabled, i can only conclude that the attack technique as described will fail due to the aforementioned observations.

  33. Alec Waters says:

    Hello Duncan,

    Sorry to hear you couldn’t make it work.

    Did you have dhcp6s running? This (together with setting the O flag in the RAs output by radvd) is what gives you the IPv6 DNS server and DNS suffix.

    Also, I did not have to explicitly add a link-local address to eth1 on evil-rtr. AFAIK, these are usually generated automatically by virtue of IPv6 being enabled on an interface.


  34. Stefano says:

    ‘@Alec: have you been able to works with sslstrip in this scenario?

  35. Ted says:

    Thanks. Good illustration.

    To be quite frank, I don’t care what label you put on it (“zero day” or not) or whether this is “new” or already known to the gurus out there. The article is clearly targeted at the millions of other mere mortals who run existing IPv4 networks with Windows 7, and who have not yet read every single RFC ever produced.

    BTW we already have mitigation measures in place (by prefering corporate IPv4 addreses over any IPv6 via over riding the RFC3484 prefix proxy table) to counter all such unexpected tunnels and interactions.

    See for example:

    netsh interface ipv6 add prefixpolicy prefix=::ffff:A.B.C.D/112 precedence=32 label=5 store=persistent

    (A.B.C.D being your corporate IP range & /112 assuming you have an IPv4 /16. Adjust to taste)

  36. Duncan says:

    I never did get this to work and, yes, i did have a DHCPD6 server running successfully (with command “dhcpd -6 -cf /etc/dhcp/dhcpd6.conf”) and the subnet declarations are ok (in your example, the value put in would be equivalent to your using 2001:6f8:608:fab::) otherwise the server would not have started in the first place.

    There is also no lease entry written to the dhcpd6.leases file which one would expect if the Windows machine was asking for an IPv6 address, yet the Windows machine has obtained a valid global IPv6 address and a valid Temporary IPv6 address and recognizes the Default Gateway IPv6 address. Therefore, the conclusion is that the Windows 7 box does not populate its DNS server cache with the information entered into the dhcpd6.conf file and therefore NAP-TD never gets to see any AAAA request to the fake DNS server.

    And regarding the link-local issue in my OP, my point was that your interface display did not match reality. As you mentioned, all IPv6 interfaces will have a link-local address auto-configured, yet your display did not which caused confusion. To illustrate, here’s the cut-and-paste of your display:

    root@evil-rtr:~# ifconfig eth1
    eth1 Link encap:Ethernet HWaddr 00:25:4b:fd:91:73
    inet6 addr: 2001:6f8:608:fab::1/64 Scope:Global
    RX packets:0 errors:0 dropped:0 overruns:0 frame:0
    TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:1000
    RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

    Notice that there is no line that says “inet6 addr: Scope:Link”.
    In general, a how-to article should have all information provided inside it be as accurate and complete as possible.

  37. vox says:

    Hi, great article!!!

    just trying to duplicate in a vm lab but cannot get naptd to compile 🙁

    did you need to make any change to the naptd files to make it work?


  38. Shanash says:

    Hey, you must use DNS64 and NAT64 instead of NAPT.

Leave a Reply

Your email address will not be published.