The Internet was designed to share data, but sometimes the paths that enable it are blocked. When it comes to bad actors - that's a good thing. Most companies today have a Data Loss Prevention (DLP) policy to accompany their web proxies and firewalls. Some of them think this is the best way to stop data exfiltration and monitor what is going in and out of their employee's internet devices. But is this enough?
Some smart people (read, bad actors) have realized there are ways to bypass these controls - giving them unfettered access to network-connected data. Two main ways to achieve this are DNS Exfiltration and DNS Tunneling.
Let's back up and cover the basics of DNS. Any time that users or network-connected devices (including IoT devices) perform an Internet request -- from web browsing to email to online retail to cloud computing -- they use DNS. Machines on the Intranet use IP addresses made up of strings of numbers to communicate. However, humans do not want to keep track of many complex numbers whenever they want to perform a simple task. Enter DNS, which is used like a phone book to simplify the process of finding the numerical IP address that corresponds with each human readable domain name.
With this in mind, we will cover DNS Exfiltration. First, widely available clients can be loaded onto a system to achieve the bad actor's end goals. The client generates queries that might go along the lines of [Encoded data that I wish to send].[Valid Domain].
The Valid Domain (registered with a registrar) will have its nameservers, which will be able to process and decode that encoded data. This is a repeatable process, and in the long run can steal lots of data. A credit card number for instance, can be taken and converted into a hexadecimal string and added to a domain name as the encoded data part of the FQDN (fully qualified domain name).
Once this crafted FQDN is made, an nslookup on that domain (or dig) is all that's needed to exfiltrate the data. The end user is then presented with a NXDomain response (Non- Existent domain) from the authorative server. It's a rinse and repeat cycle to extract more and more data. At the modified authorative server, the encoded prefix is stripped off and the data is stored locally for reassembly offline. DNS domain names are restricted to 254 characters including overheads and each field (the characters between the dots in an FQDN) needs to be 1-63 characters, so this gives the exfiltrator leverage to craft many false domain names and steal data in a way that mostly goes undetectable.
Now, let's take a look at DNS Tunneling. As you may know, if you have been to an airport, or tried to connect to a corporate guest Wi-Fi network that requires a portal password, there are various clients available to circumvent these requirements. As such, this is not an inherently bad activity, but it can be exploited by bad actors. Tunneling starts by beginning a client session and entering the command 'listen' to open a tunneled port. Then, the user chooses a local port number for the server to listen to. All connections that are received on that port are forwarded via the client on UDP port 53 to the remote host/port that is also chosen.
Here is an example command and result:
'Listen (Port number (4321) www.example.com:80'
Browser input: http://localhost:4321
Client connects to example.com over DNS using the client.
Here is where the trouble starts: tunneling has moved beyond these initial applications and is being used today by an increasing number of malware packages to circumvent security controls. These controls are usually set on the external firewall where traditional port blocking occurs, but DNS is invariably open to allow browsers to resolve access to the login for the access portal/pay page for access. So, some bad actors started noticing this opportunity and since other protocols use tunneling (GRE, IPSec, TLS) why not use DNS? After all, it's all about using UDP port 53 as a transport mechanism to bypass portals/firewalls/paywalls, etc. By creating a special client, and hosting a modified name server on the internet, that is all that's needed for criminal access. The data is simply broken into 64-bit chunks that fit into a DNS query. Creative DNS responses are then used to send the return data back to the client on your network.
Being aware of exfiltration and tunneling techniques is just the first step on the journey. Now, read our whitepaper, 5 Must-Ask DNS Questions to find out if you are proactively protecting your network and users.