Thesis: Detection, analysis and measurement of DNS tunnelling techniques

Understanding DNS tunnelling

DNS tunnelling leverages the DNS protocol to encode data within DNS queries and responses, creating a covert communication channel that can bypass traditional security measures like firewalls. Often, firewalls allow DNS traffic to pass through, which makes such traffic perfect for various malicious purposes, including data exfiltration and remote command execution. However, DNS tunnelling can also have legitimate uses, e.g. in networks controlled by authoritarian regimes.

DNS tunnelling typically involves encoding data into domain names and DNS records, which are then sent to a modified DNS server controlled for example by the attacker. The server decodes the data and processes it accordingly.

One of the key challenges in detecting DNS tunnelling is its ability to blend in with legitimate DNS traffic. To address that challenge, several detection techniques have been developed, including anomaly detection based on DNS query patterns, entropy analysis of DNS query names, and monitoring for unusual DNS record types. Previous studies have tried to detect DNS tunnelling in local networks or on recursive resolvers. To the best of my knowledge, none of those techniques have been applied to TLD traffic.

The goal of my research was to detect DNS tunnelling in .nl traffic. Ultimately, I wanted to understand whether DNS tunnelling occurs in the .nl domain. Note that the goal was not to block DNS tunnelling queries, nor to identify their users or to decode the information that was sent.

Methodology

In order to detect queries related to DNS tunnelling in .nl traffic, I first needed to understand what the traffic used in DNS tunnelling tools look like. I therefore set up a local testbed to simulate DNS tunnelling in a controlled environment. The insights I gained from the testbed helped me to develop rules, which I could then apply to real .nl traffic.

For my local testbed, I set up a simulated root server, .nl name server and a name server authoritative for the domain name used for the tunnelling. In additional, I set up a recursive resolver on which the DNS tunnelling client, relying on Iodine, was also located. Every system ran on a virtual machine.

For analysing .nl traffic, I relied on ENTRADA, SIDN’s own data platform that stores .nl traffic.

Detection methods

As in previous research, I utilised a dual approach combining traffic and payload analysis:

• Traffic analysis:

  This method involves monitoring DNS traffic patterns to detect anomalies indicative of tunnelling. I examined DNS query volumes for unusual spikes, irregular distributions, and deviations from typical traffic behaviour, which can signal potential tunnelling activities.

• Payload analysis:

  This method focuses on examining the content of DNS queries and responses. DNS tunnelling often involves encoding data within domain names or TXT records. By analysing payloads to determine characteristics such as query types and queried domain names, I was able to identify potential tunnelling activities.

Detection rules

Based on the observations I made in the testbed, and inspired by related work, I developed several detection rules. The rules were tested in both the DNS testbed and ENTRADA:

1. High entropy

   Evaluation of the entropy of queried names. DNS tunnelling often results in higher entropy values due to the randomness and complexity of encoded data.

2. Encoding detection

   Examination of DNS subdomains for specific encoding schemes like Base32, Base64. DNS tunnelling tools often encode their information using such schemes.

3. Resource record types

   Monitoring for less common DNS resource records such as TXT, NULL and PRIVATE. Such record types are often used by DNS tunnelling tools.

4. Continuous sequences

   Identification of continuous patterns of characters and numbers within DNS queries. From my testbed measurements, I saw that such patterns can be a sign of DNS tunnelling.

5. Specific characters

   Checking for the presence of the characters "z" or "y" in the leftmost label of the domain name, which has been observed to correlate with the use of DNS tunnelling tools.

Results

I applied the detection rules developed in the DNS testbed to .nl traffic in ENTRADA, and I was able to identify potential DNS tunnelling activities. Unfortunately, I can never be 100% certain that the identified queries are DNS tunnelling queries, but the fact that they match my rule set, and the fact that we cannot find other reasonable explanations for the traffic patterns in question are strong signs that.nl domain names are also used for DNS tunnelling.

As an example, “yrbbb0.*.*.nl.” is a domain name that I have identified in traffic towards the .nl name servers, which I classified as a query initiated by the DNS tunnelling tool iodine. I have removed the second-level domain name for privacy reasons.

On a randomly selected day, I found more than 3,000 unique .nl domain names potentially used for DNS tunnelling. I observed more than 250,000 queries for those domain names from 6 countries alone. Most queries for those domain names came from the United States.

Conclusion

In conclusion, my study shows that we can detect DNS tunnelling in traffic collected at a TLD, and that DNS tunnelling is still common. As future work, it might be interesting to study the motivation for DNS tunnelling and whether scanning for it might enable us to detect malware infections in networks. However, the otherwise welcome privacy-preserving technique QNAME minimisation will make it harder to detect DNS tunnelling at TLDs in the future.

For a more detailed description of my research, please have a look my master’s thesis.