Skip to main content

What Is a DNS Covert Channel?

Blog dns covert channel 08dec16 en

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 192.168.0.73

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 192.168.0.73.

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.

Comments

    alice taylor  19:03 UTC on 12 December 2016

    Thanks for sharing your info. I really appreciate your efforts and I will be waiting for your further write cat mario | whatsapp baixar | tank trouble |

    Vladimer Svanadze  02:22 UTC on 13 December 2016

    Thank you for interesting blog, was very useful for understanding this issue. Thanks for your effort!

    Jason Tomon  06:38 UTC on 25 December 2016

    Very useful information, thank you!

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."