All kind of different services, like web browsing, email, active directory, etc., use the Domain Name System (DNS) protocol to turn IP addresses into human readable names and vice versa. DNS was never intended to be used for data transfer, however it has been used for this purpose by individuals with malicious/nefarious intent for years.
DNS tunneling is often used to get free Wi-Fi over publicly available hotspots where it’s not restricted, whereas normal data transfer is limited. DNS as a tunnel can be established while hiding data inside the DNS requests which then can be turned into real data on the destination DNS server. This can turn into a real threat when malicious software uses DNS to get data out of the company network, or even receive commands/updates from a command and control server.
DNS is a critical component of today’s internet. The most common purpose is to map domain names to IP addresses. Users can enter domain names (like company.com) in their browser and DNS will resolve this name to an IP address. Using this mechanism the computer knows to which IP address he has to communicate to get the right data.
DNS uses both UDP and TCP on port 53 for communications. TCP will be used for payloads over 512 bytes and for zone transfers.
DNS uses a hierarchical system to determine the correct IP address for a domain. There are 13 root DNS servers which are represented by many more than 13 physical servers.
To explain the hierarchical structure we will use an example: blog.company.com. The first request will contact the DNS root server responsible for the .com domain. This server will provide information about the DNS server that is responsible for the company.com domain. That server then can be contacted to resolve blog.company.com to its IP address and the communication can be established.
DNS Tunneling Overview
In the prior example the DNS server of company.com was contacted to resolve the blog.company.com request. Instead of resolving blog.company.com we could send a different request: ZG9tYWluPWxvZ3JoeXRobTt1c2VyPXRlc3Q7cGFzc3dvcmQ9MTIzNDU=.company.com. This request will be sent to the company.com domain. The difference here is that the string before company.com is base64 encoded and will decode to “domain=company;user=test;password=12345”. If the company.com DNS server would be aware of this technique we’ve just sent him data of a username and password from a user of the company domain (which has been collected by e. g. a malicious piece of software). The company.com DNS server could then hide data in the answer and send to the originator of the DNS request.
As you can see it is pretty simple to use DNS for data transmission.
Detecting DNS Tunneling
There are various methods to detect DNS tunneling. We will focus on the most important ones.
Frequency of the DNS requests
As we have learnt before a DNS request using UDP will have a maximum of 512 bytes as a payload. Typical DNS requests are smaller than 512 bytes. The attackers want to hide their data transfer in the noise of all the other DNS requests, that’s why they won’t create large DNS requests with more than 512 bytes using TCP, because it would be much easier to detect those.
Transferring millions of credit card data (or any other data that would be interesting for an attacker) will take a lot of DNS requests because they have to be split into < 512 bytes packages. That’s the reason why the amount of DNS requests coming from a host that wants to transfer data via DNS will be higher than usual. So if Host A normally does 200 DNS requests per day and all of a sudden this number goes up to 600 we should definitely take a look at that.
Length of the DNS requests
Let’s think about a common DNS request. Typically it is not that long, like google.com, mail.google.com, company.com, blog.company.com, yourcompanyname.com, etc. In our prior example the base64 encoded string was 56 characters long. With a longer username/password the string would be even longer, like 70+ characters. This is quite untypical for a domain name. We can use this characteristic to create a rule.
Pattern of the DNS requests
There are various patterns we can match against the URL field to detect DNS tunneling. We will show this by using a common example: The amount of numbers included in the URL.
Typical URL doesn’t consist of a lot of numbers. But when the data are encoded using base64 the URL can potentially consists of a lot of numbers, like in our prior example (8 numbers). We can use this to detect potential DNS tunneling.
Destination of the DNS requests
Almost all companies have their own DNS server infrastructure which the clients use for the DNS resolution. Some of the malicious software uses external DNS servers, which can be detected easily. SIEM has a build-in rule for this purpose which will alarm you of any outbound DNS activity.