Detecting DNS Tunneling

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 Overview

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 logrhythm.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.logrhythm.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 logrhythm.com domain. That server then can be contacted to resolve blog.logrhythm.com to its IP address and the communication can be established.

DNS Tunneling Overview

In the prior example the DNS server of logrhythm.com was contacted to resolve the blog.logrhythm.com request. Instead of resolving blog.logrhythm.com we could send a different request:

ZG9tYWluPWxvZ3JoeXRobTt1c2VyPXRlc3Q7cGFzc3dvcmQ9MTIzNDU=.logrhythm.com

This request will be sent to the logrhythm.com domain. The difference here is that the string before logrhythm.com is base64 encoded and will decode to

“domain=logrhythm;user=test;password=12345”

If the logrhythm.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 logrhythm domain (which has been collected by e. g. a malicious piece of software). The logrhythm.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 in this article and show how to leverage LogRhythm SIEM to detect those methods.

Frequency of the DNS requests

As we have learned 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.

LogRhythm has a built-in feature that can make detecting this easy. We can build a rule that automatically creates a baseline of the number of DNS requests. We will then create an alarm if this number goes up by at least two times the baseline count.

F_Blanke_1

The first rule block will generate the baseline. It looks for any DNS query and groups the requests by the “Origin Host.” The only data field we need is the count of the requests.

F_Blanke_2

The second block now looks for the last two days and compares the count of DNS requests to the last day. If the increase is twice as high as the baseline count we will get an alarm.

All these numbers can be fine-tuned to best fit into your environment. I would suggest to start low (live count > 2*base count) and increase it if you are getting too many false positives.

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, logrhythm.com, blog.logrhythm.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.

F_Blanke_3

This rule looks for all DNS queries and matches a regular expression (“.{60,}”) against the URL field. This regular expression matches whenever the URL field is longer than 60 characters. We then group the requests by “Origin Host” and “URL.”

Again the minimum length of the URL can be fine-tuned to fit your environment. I would suggest to start low (minimum lengths around 40 to 60) and increase it if you get to many false-positives.

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.

F_Blanke_4

This rule looks for all DNS queries and uses the regular expression (\d.*?){5,} to determine if the URL consists of more than 4 numbers. This time we also use an exclude filter to exclude any DNS queries that consists of IP addresses which typically have more than 4 numbers.

Like always the number can be fine-tuned to fit into your environment. I would suggest to start low (more than 5 numbers like in this example) and increase it if you get too many false-positives.

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. LogRhythm has a build-in rule for this purpose: Int: Susp: Outbound DNS Activity. This rule can be easily enabled and will alarm you of any outbound DNS activity.

F_Blanke_5

This rule looks for any outbound DNS connections and groups them by “Hostname (Origin)”, “Impacted Application” and “Hostname (Impacted)”.

Sources:

Detecting Rogue Svchost Process

Detecting the Juniper Netscreen OS Backdoor

Automatic Management of User Account Expiry Use Case