Hide & Seek

We all love playing Hide & Seek. A game we enjoyed playing in our childhood. The rules were so simple, one person would close their eyes and start counting (often counted as 50) while other players would hide. The seeker then opens his eyes and tries to find the hiders; the first to be found will become the next seeker, and the last is the winner of the round. There are different versions of the game in different regions but we’ll focus on this. If you can hide until they find the last person, you can be a winner. Hiding is not an easy task. This also applies to security threats in the modern world. They use various evasion techniques or remain inactive until their intentions are fulfilled without any discovery. You know how difficult it is to bypass firewalls and modern security devices, so malware is never an easy task 😅. For the same reason, it is not easy to make a C&C callback or exchange sensitive information.

In this blog, we’ll discuss one of such evasion techniques called DNS Tunnelling. Long story short, I was reading about Dependency confusion by Alex birsan and in his article on how he was able to exfiltrate information from tech giants including Apple, Paypal,…, he referred to the technique he used to transfer data from their system to a server. Which was of course DNS tunneling. An attack that had been there for some time and no one cared about it. This attack uses the DNS protocol to transfer data.

But how ❔ How does he manage to send information using a protocol which was never intended to transfer data ❔

The DNS Protocol

The Internet is basically a group of connected computers, each with its own IP identifier. If Computer B wants to communicate with Computer A, it must know A’s IP. It is like knowing the home address to receive an online package. So if you want to talk to a computer on the network, you need to know their lP. But there is a problem, humans are bad at math (accept it 😄). Nah.. just kidding. The problem is that we can’t remember all these random numbers separated by dots(Eg: 192.168.1.1). To solve this issue, a new system was introduced called the DNS(Domain name system). Which basically resolves a given domain name to an IP.

Stackoverflow.com :: 151.101.129.69

DNS is like a big phone book, with the help of which you can call your friends without remembering their phone numbers. When you type a domain name into an address bar, such as medium.com, a set of actions takes place in the background.

It’s like going to a place where you don’t know the way and asking the locals for directions 😕. After typing in medium.com, the browser will issue a DNS lookup for the domain you typed in. This is basically checking if someone has the IP corresponding to medium.com. It will first check whether your local DNS server has a cached copy. If not it will forward the request to the next level the Root name server. This process will continue until the Authoritative nameserver. The authoritative server will be able to reply with the required IP, based on which further communication will take place. If you want to learn more about DNS refer to this article.

Now that we have an understanding of how DNS works, let’s try to transfer data over DNS.

Although this may seem unfair, I will use Burp Collaborator because I don’t want to buy a custom domain or make use of iodine,dnscat like tools.

DNS Tunneling

This method takes advantage of the fact that DNS requests to unknown, untrusted, or known bad domains and resources are often kept unfiltered.

DNS packets contain many fields and headers in which data can be concealed.

Step#1:: Start your burp collaborator instance.

Step#2:: Copy collaborator client URL. Add random values before the copied URL. i.e, if your collaborator URL is zcfe44hkzgcqhbnohna30196fxlq9f.burpcollaborator.net then change it to mysecret.zcfe44hkzgcqhbnohna30196fxlq9f.burpcollaborator.net. Paste it in the browser address bar and hit enter.

Step#3:: Analyze collaborator interactions for DNS requests.

As you can see, a DNS lookup request was made for the domain we just entered. You can add data to a DNS lookup request, even an encoded payload.

Likewise, an attacker with a custom DNS server and access to your system can act as an authoritative server to handle requests to various subdomains. Any DNS request made by the victim to “{data}.attacker.com” will end up reaching the attacker’s machine. The attacker can then respond to the victim’s DNS request enabling a bidirectional data transfer channel.

However, some of you may be skeptical. This does not make sense, because what we have just done is basically trying to resolve a Sub-subdomain that does not exist. Normally, the request will show an error page indicating “This site can’t be reached”. The reason why this does not happen is because of the following Burp Collaborator features:

• It uses its own dedicated domain name, and the server is registered as the authoritative DNS server for this domain.
• It provides a DNS service that answers any lookup on its registered domain (or subdomains) with its own IP address.

So we can add any data in front of the generated collaborator ID and still receive a callback 👌.

Similarly, if a user makes a request for an anonymous domain name in a protected environment, it will eventually leave the environment because it needs to be resolved to an IP.