Cynet's 24/7 MDR with the latest security updates and reportsDownload the Cyops Solution Brief
By: Ron Lifinski, Cyber Security Researcher
Most organizations have a firewall that acts as a filter between their sensitive internal networks and the threatening global Internet. DNS tunneling has been around for a while. But it continues to cost companies and has seen hackers invest more time and effort developing tools. A recent study found that DNS attacks in the UK alone have risen 105% in the past year. DNS tunneling is attractive–hackers can get any data in and out of your internal network while bypassing most firewalls. Whether it’s used to command and control (C&C) compromised systems, leak sensitive data outside, or to tunnel inside your closed network, DNS Tunneling poses a substantial risk to your organization. Here’s everything you need to know about the attack, the tools and how to stop it.
(To learn more about how Cynet can help you protect from DNS Tunneling click here)
This is part of an extensive series of guides about Network Attacks
DNS tunneling has been around since the early 2000s, when NSTX – an easy to use tool has been published to the masses. Since then there was a clear trend – tighter firewall security led to more widespread DNS tunneling. By 2011 it had already been used by malware such as “Morto” and “Feederbot” for C&C, and by the popular malicious payload for point-of-sale systems – “FrameworkPOS” for credit card exfiltration.
DNS was originally made for name resolution and not for data transfer, so it’s often not seen as a malicious communications and data exfiltration threat. Because DNS is a well-established and trusted protocol, hackers know that organizations rarely analyze DNS packets for malicious activity. DNS has less attention and most organizations focus resources on analyzing web or email traffic where they believe attacks often take place. In reality, diligent endpoint monitoring is required to find and prevent DNS tunneling.
Furthermore, tunneling toolkits have become an industry and are wildly available on the Internet, so hackers don’t really need technical sophistication to implement DNS tunneling attacks.
To better understand how hackers deploy this technique, let’s examine three of the popular tools that implement DNS Tunneling.
Most of the other DNS Tunneling tools focus on tunneling TCP traffic using DNS, but this tool is different. DNScat2 is designed to create an encrypted command and control channel over the DNS. It borrows some concepts from Metasploit’s handler and is made with ease of use in mind.
The tool is divided into two components, a client and a server. The client is written in C and the server is in Ruby.
The server is long-lived and can support connections from many clients, which makes it a basic C&C server. It will need to run first, before any of the clients.
After running the server, the client can run. This will open a session with the server that can either traverse the DNS hierarchy, which is the recommended way, or connect directly to the server via raw UDP. Going through the full DNS hierarchy requires an authoritative domain but will bypass most firewalls, since the DNS traffic is exchanged with the default server configured on the machine.
Connecting directly to the server is a useful feature for testing but is a lot more likely to be blocked by a firewall.
List of possible commands in a session
Forwarding the victim’s TCP port 22 through the tunnel
Iodine lets you tunnel IPv4 data through a DNS server. It creates a network interface on each of the clients and connects them together as if they shared the same network. This feature is unique to Iodine since other DNS tunneling tools focus on tunneling specific ports, and not the entire IPv4 traffic. This allows computers to ping each other, access all UDP/TCP ports and all other protocols that are encapsulated by an IP header.
The tool runs on Linux, Mac OS X, FreeBSD, NetBSD, OpenBSD and Windows and requires a TUN/TAP device. It also comes built-in with Kali Linux.
Iodine comes with as two executable files: iodined (The server), and iodine (the client).
To run the server, you need control over a real domain, and a server with a public IP address to run it on. then delegate a subdomain to the server.
The client is passed one or two arguments, the first is the local relaying DNS server, and the second is the domain by the server. If the first argument is not specified, the system’s current DNS setting will be used as a relay.
Running the server on the attacker’s “Kali Linux”
Running the client on the victim’s Windows machine
Opening a bind shell on port 666 on the victim’s machine
Connecting to the bind shell via the DNS tunnel
Heyoka is an exfiltration tool that uses spoofed DNS requests to create a bidirectional tunnel. The tool is not under active development anymore and according to its authors, is up to 60% faster than other tools by using binary encoding and NULL records. Heyoka also focuses on stealth by sending spoofed DNS traffic from other hosts in the network. This makes detection by a firewall and locating the machine that’s tunneling much harder. With that said, it currently works only on Windows.
Heyoka comes as a single executable that can run in two modes: master and slave. The master acts as a server and will listen on a local port, for example, 2222. The slave acts as a client and will forward one of its ports, for example, 22 through the tunnel and allow the attacker access to it by connecting to 127.0.0.1:2222 on the master machine. In this example, the victim’s SSH port will be exposed through DNS.
Running the server on the attacker’s Windows machine
Opening a bind shell on the victim’s Windows machine and running the tool
Receiving the connection on the server and interacting with the bind shell
Packet Capture (showing plain text data)
A firewall is no longer enough to separate an internal network and keep it safe, and DNS tunneling is just one of the creative techniques that cybercriminals use to escape internal networks. For example, Heyoka’s stealth mechanism proves that what’s invisible from the firewall’s perspective, is obviously malicious from the endpoint’s point of view. To combat DNS tunneling, the burden has shifted away from the network to the endpoint. Security professionals and vendors must examine incoming and outgoing traffic at the endpoint to detect and defeat these attacks.