The DNS protocol was designed to ease the use of the Internet for the users. With it, we no longer have to remember four numbers divided by dots where they can have up to three digits in order to browse our favorite website. Of course, hackers always find a way to abuse any protocol, and devised a way to establish network communication to send data either from the victim, the attacker, or both ways.
Why is DNS tunneling bad? Generally speaking, the DNS protocol is allowed everywhere – it is not restricted, in most cases not even checked, and any device on the internal network is allowed to use it. You cannot just block the DNS protocol altogether, because then you would basically cut yourself off the rest of the internet. So, picture, if you will, a situation, where a hacker gains a foothold within a protected network by taking control over a computer of one of the employees when the said employee opens a malicious file the hacker sent. By accessing the web server, the computer downloads and launches a script that initiates the DNS tunnel, giving the hacker a full remote access, albeit slow. Now the attackers can send whatever they want via the tunnel without anyone knowing what they sent, and in most cases, that they had sent anything at all.
Fighting the DNS tunnels
To successfully block DNS tunnels, you must be able to detect them in the first place. Think of how a regular domain looks – e.g., subdomain.domain.net. When the attacker’s malware sends a request to resolve something like Oe120yBTbWl0aD4gMTISLtQ1LdY3OFk.attacker.online, you can notice at a first glance that the query is different but for the computer this is a valid query that complies with the DNS protocol so it will go through. What the computer does not see is that there is some information encrypted in the random character string. It might contain passwords, credentials or even entire file contents, spread across multiple requests like this. The tunnels can work both ways. It is just as easy to encode an executable command in the DNS response. The malicious script can simply parse the encrypter response and execute the command on the compromised machine.
DNS tunneling is not always bad though. Your antivirus software relies on DNS tunnels to send hashes of the files it scans to the vendor’s servers. It does this to find out whether a particular file is malicious or not. Other websites may use randomly generated text for legitimate purposes like sending telemetry information, so the detection has to be robust with the lowest amount of false positives as possible. There are multiple approaches that Whalebone works with. For example, we look into the amount of DNS requests, because the network traffic tunneled through DNS is way heavier than a regular DNS communication. As for breaking the tunnel, we make use of multiple security techniques in the DNS standard and enforcement of their combination actually breaks most of the malicious tunnels without hindering the regular DNS traffic. There are a few well-known domains for which we do not employ randomization so that we do not break the functionality of critical tools and services.
Against the more sophisticated tunneling mechanisms that are able to work even with all these mechanisms in place we use our neural networks to help us decide whether a particular activity should be considered as tunneling and eventually blocked or not.
DNS tunnels are used because the protocol itself is unrestricted in most cases, making it a safe bet for the attackers when they want to extract some valuable data from a well-secured company. To fill this gap, you need a solution that protects the DNS protocol and can recognize the tunneling with multiple approaches, not just a single one, because there are multiple ways to work with the tunnel and relying on just one detection method would keep you blind to some of them.
