DNS Tunnelling

Abusing DNS to hide communications and move data

Introduction

The Domain Name System (DNS) is one of the fundamental services that makes the Internet usable.

Whenever a user visits a website such as cybertrainer.uk, DNS helps translate the human-readable domain name (cybertrainer.uk) into the IP address (109.228.34.178) that devices use to communicate with the webservice that hosts the site.

Because DNS is so important, almost every organisation allows DNS traffic to pass through its network.

This creates an interesting security problem – What if an attacker could use DNS traffic for something other than resolving domain names?

So, Instead of simply asking – “What IP address belongs to this domain?”, a compromised computer could use DNS queries and responses to communicate with an external system and pass data inside the DNS query.

This technique is known as DNS Tunnelling.

As a concept, DNS tunnelling can be used for legitimate purposes, such as bypassing network restrictions in controlled environments, but it can also be abused by attackers to establish covert communication channels, maintain command-and-control connections, and potentially transfer information out of a compromised network.

Because DNS traffic is ubiquitous with everyday web traffic, malicious DNS communications can sometimes blend into normal network activity.

What is DNS Tunnelling?

DNS tunnelling is a technique that encapsulates data or other communications within legitimate DNS queries and responses. Instead of using DNS purely for domain-name resolution, an attacker can encode information within the DNS traffic.

An attacker-controlled DNS server can receive the information contained within the DNS requests and potentially send information back through DNS responses. The DNS protocol effectively now becomes a communication channel.

This is why DNS tunnelling is sometimes referred to as a covert channel.

Why would an attacker use DNS?

DNS has several characteristics that make it attractive for attackers to utilise:

  • DNS is everywhere – Almost every networked computer needs DNS – Without DNS, most systems would simply not be able to function
  • DNS is normally allowed – Organisations generally cannot block all DNS traffic, as doing so would disrupt normal network operations.
  • DNS traffic can blend into normal activity – A network may generate thousands of DNS queries every day. Security teams therefore have to distinguish legitimate DNS activity from suspicious behaviour.
  • DNS can cross network boundaries – DNS requests frequently leave the internal network and communicate with external DNS infrastructure. This can potentially provide an attacker with a pathway out of a restricted environment.

How does DNS Tunnelling work?

A typical DNS tunnelling scenario begins with a compromised system where an attacker installs or executes malware on the system. The malware needs to communicate with infrastructure controlled by the attacker (C2 – Command & Control)

However, the organisation may have strong outbound firewall restrictions that would typically deny the malware the ability to communicate, effectively rendering the C2 unreachable

The malware therefore attempts to use DNS – because this is allowed

Information for the C2 infrastructure can be transformed into a format that can be included within DNS queries, so the compromised computer generates apparently legitimate DNS traffic.

A DNS server controlled by the attacker receives the requests and extracts the information.

The C2 server builds a response to the query that can provide instructions for the compromised machine

The result is a two-way communication channel operating through DNS.

DNS tunnelling and encoded data

Data transmitted through a DNS tunnel generally needs to be represented in a form suitable for DNS. This means information may be encoded into DNS query components.

A simplified example might look something like:

a83kd92j.example-domain.com

The apparently random-looking portion could contain encoded information.

A series of requests might therefore appear as:

a83kd92j.example-domain.com

92jd82ka.example-domain.com

k29dks81.example-domain.com

Individually, each request may not immediately appear malicious, however, when thousands of unusual queries are examined together, a pattern may emerge.

DNS tunnelling as a covert channel

DNS was designed to resolve hostnames and provide information about domains. Using DNS to transport arbitrary information changes its intended purpose – This makes DNS tunnelling an example of a covert communication technique.

The attacker is effectively attempting to hide communications inside an otherwise legitimate protocol.

DNS tunnelling for Command and Control

As mentioned, one of the most important uses of DNS tunnelling is for Command and Control (C2).

The attacker may use the communication channel to:

  • Send instructions
  • Receive information
  • Maintain contact with compromised systems
  • Determine whether a system is still compromised
  • Coordinate multiple infected systems

DNS can provide a useful C2 mechanism because DNS traffic is frequently permitted through network security controls.

The DNS server effectively becomes part of the attacker’s command-and-control infrastructure.

DNS tunnelling for data exfiltration

DNS tunnelling can also potentially be used for data exfiltration – The unauthorised transfer of information from an organisation.

An attacker may attempt to move information such as stolen credentials, application data, sensitive data, and more from a compromised computer through multiple DNS requests.

The amount of data that can realistically be transferred depends on the tunnelling method and the surrounding infrastructure. DNS is generally not an efficient replacement for conventional file-transfer protocols, but the attraction is that the communication may be difficult to distinguish from legitimate DNS traffic, and therefore not be blocked.

DNS tunnelling and malware

DNS tunnelling is particularly relevant when analysing malware behaviour. Some malware families have incorporated DNS-based communications into their command-and-control infrastructure.

Security analysts may therefore encounter DNS traffic associated with compromised endpoints even when no obvious external connection is visible.

DNS Tunnelling techniques

There are several ways DNS can be abused as a communication channel – many of them are based on the format of DNS records

A records

DNS A records normally provide IPv4 addresses. When abused, attackers can use DNS responses to communicate information through the returned values.

So in this scenario, malware can generate a DNS A record query, which is received by the attackers controlled DNS server – the response may contain an IPv4 address, but also other data such as extra code for the malware to process as instructions

AAAA records

DNS AAAA records provide IPv6 addresses. As with DNS A records, AAAA queries can receive data as part of the response

TXT records

DNS TXT records can contain textual information that is used to provide extra data about a domain, such as its email Sender Policy Framework (SPF) validation data. But if compromised, these files can be used to contain secrets stolen from an organisation

Because TXT records are legitimate DNS functionality, defenders cannot simply assume that every TXT query is malicious – Context is important.

DNS Tunnelling and Domain Generation Algorithms

Some malware uses Domain Generation Algorithms (DGAs) to automatically generate large numbers of random domain names according to an algorithm.

The malware periodically generates domains and then attempts to contact them. This can make it more difficult for defenders to simply block one known domain.

DGAs and DNS tunnelling are related but are not the same thing. A DGA is primarily a mechanism for generating domain names, whereas DNS tunnelling is a mechanism for using DNS as a communication channel.

They can, however, be combined within a malware campaign, botnets, ransomware, and other attacks.

DNS Tunnelling and DNS over HTTPS

Because DNS was built as a non-encrypted protocol, it is possible to “see” the queries and responses which are communicated. TO secure DNS, modern DNS data can be transported using technologies such as DNS over HTTPS (DoH), or DNS over TLS (DoT)

DoH encrypts DNS queries between the client and a DoH resolver. This provides privacy and protects DNS queries from certain forms of interception.

However, encrypted DNS also creates challenges for security monitoring – If an organisation cannot inspect DNS activity at an appropriate point in its infrastructure, identifying suspicious DNS behaviour can become more difficult.

This does not mean that DoH is inherently malicious, it means that organisations need to understand where DNS visibility exists within their environment.

Why DNS Tunnelling is difficult to detect

DNS tunnelling presents a difficult problem for security teams; Blocking DNS entirely is normally impractical – So, the challenge is therefore to identify abnormal DNS behaviour.

A single unusual DNS query may mean nothing, but thousands of unusual queries from the same workstation may tell a very different story.

Detection therefore depends heavily on patterns and context.

Indicators of DNS Tunnelling

Security teams may look for several characteristics that are tell-tale signs of DNS tunnelling

  • Unusually long DNS queries – DNS names have limits, so attackers attempting to transfer information may generate unusually long query names. Repeated long queries should be treated as suspicious.
  • High numbers of unique subdomains – Normal applications may repeatedly request a relatively small number of domains. A compromised host may generate large numbers of unique subdomains. A high rate of unique subdomains can be an indicator worth investigating.
  • High DNS query frequency – A workstation generating unusually large numbers of DNS requests may deserve investigation.
  • High entropy – Encoded or compressed data can produce strings that appear highly random. Security systems can calculate measures such as entropy to identify unusually random-looking domain components.
    High entropy does not prove malicious activity as many legitimate systems generate random identifiers. It is therefore best treated as one signal among several.
  • Unusual character patterns – DNS tunnelling may produce strings containing repeated patterns of letters, numbers, and encoded characters – Again, the important factor is the overall pattern rather than one suspicious string.

DNS Tunnelling Detection

Effective detection usually combines multiple sources of information. Security teams should monitor:

  • DNS query logs
  • DNS response logs
  • Endpoint telemetry
  • Firewall logs
  • Proxy logs
  • Network flow data
  • EDR alerts
  • SIEM events

This allows analysts to correlate DNS activity with activity occurring on the endpoint.

DNS Tunnelling and SIEM

A Security Information and Event Management (SIEM) platform can be particularly useful for detecting DNS tunnelling.

A SIEM can correlate:

  • DNS queries
  • Source host
  • Destination domain
  • Process information
  • User account
  • Authentication events
  • Network connections
  • Endpoint alerts

This allows security analysts to move from “This DNS query looks strange“, to “This workstation is generating abnormal DNS traffic from a previously unseen process immediately after suspicious activity.”

Context dramatically improves detection.

How can organisations defend against DNS Tunnelling?

  • Centralise DNS traffic – Organisations should consider forcing internal systems to use approved DNS resolvers. This provides greater visibility and makes it more difficult for compromised systems to communicate directly with arbitrary external DNS servers.
  • Monitor DNS activity – DNS logging should be enabled where practical.
  • Restrict direct external DNS – Where appropriate, firewalls can prevent internal systems from directly communicating with external DNS infrastructure. Instead, DNS requests can be routed through approved organisational resolvers.
  • Use DNS security controls – Organisations can use technologies that identify things such as malicious domains, newly registered domains, known C2 infrastructure, and suspicious DNS patterns
  • Endpoint monitoring – DNS monitoring becomes significantly more powerful when combined with endpoint telemetry. Security teams can identify which process generated the DNS request to help distinguish legitimate software from potentially malicious processes.
  • Network segmentation – Network segmentation can restrict which systems are allowed to communicate with external services limiting the potential impact of a compromised endpoint.
  • DNS Filtering – DNS filtering can prevent systems from resolving known malicious domains.
    DNS filtering is not a complete solution to DNS tunnelling, as attackers may use previously unknown infrastructure. However, it can significantly reduce exposure to known malicious domains.
    See my blog posts on setting up a pi-hole to achieve this in your home network

Blocking DNS Tunnelling

Organisations should be careful about attempting to block DNS tunnelling using simplistic rules.

For example a simple rule which states “Block every long DNS query.” could create large numbers of false positives.

Legitimate applications can generate:

  • Long hostnames
  • Random identifiers
  • Tracking domains
  • Cloud service identifiers

Effective detection should therefore consider multiple characteristics.

A more useful approach would be to look holistically at the DNS

E.G. – Length + entropy + frequency + domain reputation + host behaviour + process information

This combination of artefacts is far more valuable than any single indicator.

DNS Tunnelling Prevention Checklist

Organisations should consider:

  • Centralised DNS resolution.
  • Prevention of unnecessary direct external DNS connections.
  • Enabling DNS logging.
  • Monitoring DNS query frequency.
  • Monitoring unusually long domain names.
  • Monitoring high-entropy subdomains.
  • Monitoring large numbers of unique subdomains.
  • Using DNS filtering.
  • Blocking known malicious domains.
  • Integration of DNS monitoring with SIEM platforms.
  • Correlation of DNS activity with endpoint telemetry.
  • Monitoring newly observed domains.
  • Use of network segmentation.
  • Investigation of unexplained DNS anomalies.
  • Maintenance of appropriate visibility when using encrypted DNS technologies.

Conclusion

DNS is one of the most important services on modern networks- This is fact. It allows computers to locate services and communicate across the Internet.

DNS Tunnelling abuses DNS as a communication channel, allowing attackers to potentially hide command-and-control traffic or move information through DNS queries and responses.

Detecting DNS tunnelling requires more than simply looking for malicious domains. Security teams need to understand what normal DNS activity looks like and identify deviations from that baseline.

Unusually long queries, large numbers of unique subdomains, high query frequencies, random-looking domain components, unusual record types, and communication with suspicious domains can all provide useful indicators.

The key lesson is simple:

DNS traffic is not automatically harmless simply because DNS is a legitimate network service.

For defenders, DNS represents both a fundamental network dependency and a valuable source of security intelligence.

By monitoring DNS effectively, organisations can detect malicious communications that might otherwise remain hidden within normal network activity.