What Is a DNS Covert Channel?

8 December 2016

Dave Piscitello

In the first part of our covert channel series, I explained that a covert channel is an evasion or attack technique used to transfer information in a secretive and typically unauthorized or illicit manner. I also explained how one could create a covert channel using the Internet Protocol (IP) or the Internet Control Message Protocol (ICMP).

In this part, I will explain why the Domain Name System (DNS) is also an attractive protocol for covert channels, and illustrate how the DNS could be used to create a covert download channel.

Why Use a DNS Covert Channel?

Network administrators often block traffic to Internet services that they do not want their users to access with Internet firewalls. DNS queries and responses are rarely blocked, because users must ask the DNS questions to resolve domain names to Internet addresses. This makes DNS a strong candidate for someone who wants to transmit or receive information without detection. DNS covert channels can be used to bypass a Wi-Fi paywall to avoid paying a service fee, or to run an unapproved application from a work computer. They can also be used to tunnel other Internet protocols such as Secure Shell, IP or even Tor. Cyberattackers can use a DNS covert channel in a more dishonest way, such as a communications channel between a computer they have compromised and a computer they operate. Sadly, malware writers are increasingly using the DNS for covert communications between infected computers and command-control hosts.

A DNS Covert Channel in 3… 2… 1…

Setting up a DNS covert channel requires very little investment or infrastructure. You need a domain name, a name server to host name resolution for that domain name (a "real DNS server"), and a fake DNS server to communicate with clients over a covert channel using artificial DNS queries and responses.

Let's consider how cyberattackers might download malicious software from a server they operate to a computer they have infected with an installer or dropper malware. They could:

  1. Choose a domain name, e.g., example.com.
  2. Configure a "real" DNS name server to host this domain: ns.example.com. This is where the cyberattacker will host the zone file for this domain name. The cyberattacker could do this during their domain registration and choose any public DNS operator for this purpose.
  3. Add an address record to the zone file for example.com for a computer that will behave like a DNS server, but will be used to download malware covertly. Let's call this covert.example.com, for example:
    covert.example.com. 600 IN A

At this point, the cyberattackers have a working name service that will resolve the host name covert.example.com to a fake DNS server hosted at

Covert Communications Use DNS Query and Response Data

The cyberattackers next define the format of DNS queries that covert channel clients running on infected computers will ask and the format of corresponding answers that fake DNS server software operating at covert.example.com will return. The cyberattackers in this example use a sub-label to identify a request in a DNS query, e.g., question.covert.example.com, and they use a text (TXT) record to return the answer, so a conceptual exchange between the covert channel client on an infected computer and the fake DNS server would be:

QUESTION: question.covert.example.com   IN TXT
ANSWER: question.covert.example.com 0 IN TXT "there is new malware software for you"

This is a pretty basic exchange. It's also not very covert, so cyberattackers could choose to hide the plain text by using an encoding scheme called Base64 (try it yourself here). If the cyberattackers were to use Base64 to encode question and answer, anyone who examined this exchange would see the following:

QUESTION: cXVlc3Rpb24=.covert.example.com   IN TXT
ANSWER: cXVlc3Rpb24=.covert.example.com 0 IN TXT "dGhpcyBpcyBuZXcgbWFsd2FyZSBzb2Z0d2FyZSBmb3IgeW91"

Cyberattackers often decide that Base64 is not sufficiently covert. In these cases, they could use a third-level label to convey encryption key derivation information, i.e., information that would allow the covert channel client to calculate (derive) a key to decrypt the response data in the TXT message answer.

Using messages that conform to DNS protocol standards is an important part of operating covertly. Length limits for labels (63 bytes) and TXT records (255 bytes) would constrain the message exchange in this example. Cyberattackers could overcome these length limits by using the third-level label as a parameter that identifies and distinguishes "chunks" of data in the request. The covert channel client is now able to make multiple DNS queries to download a larger "payload" by assembling the "chunks" of malware software returned in TXT message answers.

The mechanisms I've described here are used by the Feederbot malware [PDF, 220 KB], whose DNS queries are of the form:

Random data Chunk identifier Encryption key derivation data Delegated Name TLD

The Feederbot malware DNS TXT record response is composed as follows

DNS TXT rdata
Base64 encoded data
Checksum Chunk of malware software

Joe Minieri produced a four-minute YouTube video that describes a covert channel similar to what I've described, entitled Stealing Corporate Data Undetected.

The DNS Is a Green Field of Covert Channels

I've chosen to illustrate one of several DNS covert channels and, in particular, one that is purposely designed for malicious or criminal use. Software for DNS covert channels is available for download from public repositories. Several popular DNS covert channel software are "general purpose", i.e., they create bidirectional tunnels to support a variety of Internet protocols. If you're curious, you can read how Dan Kaminski's OzymanDNS can be used to create a TCP tunnel for Secure Shell (SSH) or how NSTX or Iodine can be used to tunnel IPv4 traffic. I even found a paper that describes how to use the time-to-live (TTL) field of the DNS protocol to support a covert channel.

DNS is a necessary service, and few organizations examine DNS traffic for security threats.

In a future post, I'll discuss measures to detect or mitigate DNS covert channel threats.

Dave Piscitello