How to Detect DNS Tunneling in the Network?

In the past several years, we have seen multiple malware samples using DNS tunneling to exfiltrate data. In June, Microsoft Security Intelligence warned about BazarCall (or BazaLoader), a scam infecting victims with malware to get them to call a phony call center. BazarCall can lead to Anchor malware that uses DNS tunneling to communicate with C2 servers. APT groups also used DNS tunneling in a malware campaign to target government organizations in the Middle East. We will present a few techniques you can use to detect DNS tunneling in your network.

DNS Tunneling in a Nutshell

So how do attackers use DNS tunneling in their malware? It’s simple:

• First, they register a domain that is used as a C&C server.
• Next, the malware sends DNS queries to the DNS resolver.
• Then the DNS server routes the query to the C2 server.
• Finally, the connection between the C2 server and the infected host is established.

For attackers, DNS tunneling provides a convenient way to exfiltrate data and to gain access to a network because DNS communications are often unblocked. At the same time, DNS tunneling has very distinct network markers that you can use to detect DNS tunneling on your network.

DNS Tunnel to an Any Device

In terms of network markers, TXT type queries are very common in DNS tunneling. However, DNS tunneling can also be used in uncommon query types, such as type 10 (NULL).

To detect DNS tunneling in your network you need to examine long DNS queries and uncommon DNS query types, distinguish between legitimate security solutions as AVs and malicious traffic, and distinguish between human-generated DNS traffic and Bot-generated traffic.

In the following example, we will analyze the algorithm behind the DNS tunneling traffic that we have seen in our customer networks. We have seen many cases of DNS tunneling used on Windows, however in the following example it was used on Android.

Examine the Algorithm Generating the DNS

We have seen a few common characteristics where DNS queries were used on Android DNS tunneling use-cases.  In the screenshot (figure 1) we can see the same algorithm used in multiple DNS queries. We have broken the algorithm into eight parts: 

In figure 1, we can see the same algorithm used in multiple DNS queries. We have broken the algorithm into 5 parts:

1. There are 4-11 characters in the first part – Red
2. The first 6 characters in the second part are repeated between different queries – Blue
3. There are 63 characters in the next parts – Yellow
4. The last section has 10 characters – Black
5. The first letter in the second part is repeated with a unified string – Green

By examining the algorithm, we can understand that these DNS queries originate from the same Bot, since they have the same algorithm. We can also assume it is Bot traffic, since it’s a unified algorithm that is repeated in different DNS queries. Bot-generated traffic tends to be consistent and uniform.

Examine the Destination

Next, we examine the destination of the DNS queries. By examining the destination, we identify several unknown servers. When we examined what other DNS queries those servers received, we couldn’t find any except the tunneling queries.  If you can’t find any legitimate traffic to the DNS server, it’s another indicator that this is server may be used by malware.

Examine the Popularity

Given a sufficiently large networks, developing an algorithm for measuring the popularity of IP/Domain among your users will also help hunt malware. By using such a Popularity algorithm across the hundreds of thousands of users on the Cato network, we can see that the popularity of the servers in the DNS queries to be low. Low popularity of an IP is often an indicator of a malicious server as the server may only used by the malware. Low popularity alone, however, is insufficient to determine a malicious site. It must be joined with other indicators, such as the ones outlined above.

Conclusion

DNS tunneling is an old technique that allows attackers to communicate with C2 servers and exfiltrate data through many firewalls. Focusing on the network characteristics, though, allows the threat to be identified. In our case, we found multiple DNS queries generated by an algorithm, a destination with unknown servers, and servers that were unpopular. Any one indicator alone may not reflect malicious communications but together there’s a very high probability that this session is malicious — a fact that we validated through manual investigation. It was an excellent example of how combining networking and security information can lead to better threat detection.