DNS Threats part 3: DNS tunnelling
DNS tunnelling is a technique threat actors can use to establish a covert communication channel from inside a protected network.
DNS tunnelling is not an actual attack on the DNS infrastructure per se but a sinister way to abuse the DNS protocol to establish secret communication channels. Since DNS traffic is generally allowed through firewalls and its queries and query responses are rarely monitored, the DNS tunnelling technique has proven quite effective and hard to discover by normal means since it is disguised as legitimate DNS traffic.
For DNS tunnelling to work, the attacker needs to register an authoritative zone on DNS servers under the attacker’s control. The zone could have been registered years ago and possibly also have some sort of legitimate use to avoid being stamped as a suspicious domain by anti-malware software. The attacker also needs to plant the tunnelling code (malware) on a host inside the target network.
DNS tunnelling is known to be used for Data Exfiltration and the Command & Control (C2) channel. However, it could also be used to encapsulate regular IP protocols such as HTTP/HTTPS, SSH, and FTP if the situation allows it. Malware is the major consumer of DNS Tunneling techniques, but it could also be used if an attacker has gained access to hosts inside a target network.
All communication protocols must comply with the standards defined by the IETF through numerous RFCs. Firewalls and Intrusion Detection Systems usually check that packets don’t deviate from those standards, where a deviation usually triggers an alert and the packet is dropped. Additional threat intelligence systems may use AI and large databases of known attacks to recognise traffic patterns and possibly indicate an attack. Good cyber defence systems cost lots of money and many organisations can’t afford complete cyber defence coverage, which threat actors could exploit.
DNS exfiltration
As the name indicates, threat actors use the DNS protocol to covertly exfiltrate data from inside an organisation through firewalls and possibly Intrusion Detection Systems back to the attacker-controlled infrastructure. If good security countermeasures are in place, each packet that leaves the network gets inspected to validate that it is what it claims to be, in this case, a DNS query with its accompanied query response. Less adequate firewalls and network filters may only recognise traffic on UDP port 53 and pass it on as DNS traffic.
DNS queries are painfully slow ways to exfiltrate data and attackers might want to probe the network to see if more suitable protocols like HTTPS, FTP, or SFTP could be used. By trying these protocols, the attacker risks being discovered since many organisations use proxies to control and monitor network traffic. If probes are unsuccessful, the fallback option is eventually DNS tunnelling.
To pass through firewalls as a legitimate DNS query, the DNS packets must reassemble actual DNS queries. This means the data must be encoded in a valid character set like base64 or hex and inserted in the QNAME field of the DNS query packet. The QNAME field can only be 256 bytes long and must comprise a series of labels of a maximum size of 64 bytes. Since the attacker wants the query to arrive at its own controlled DNS servers, the attacker needs at least two labels to accomplish that feat. Each label consists of one length byte and up to 63 bytes of data. This indicates how much (little) data can be exfiltrated by a single DNS query and how many queries are needed to exfiltrate more considerable amounts of data.
Command and Control (C2)
A Command and Control channel is based on the same principle as DNS exfiltration, except it uses the query response to download data onto a compromised host or network. Once the malware has infected a host, it will try to check in with its “home base” to receive instructions and/or download additional code to expand its foothold further. Since the query response packet can be much larger than the query packet, it can host more data.
Initially, the DNS UDP packet was limited to 512 bytes, which was enough for the original specifications of the DNS protocol. However, the Internet grew and so did the demand for larger DNS query responses, which led to fragmented responses. To avoid fragmented packets, which hackers exploited in the 90’s, the DNS needed a way to accommodate larger responses. Specifically DNSSEC Resource Record Signatures and other DNSSEC-related data require larger packet sizes. Thanks to the introduction of EDNS0 (RFC 2671 and RFC 2673) in 1999, which was later obsolete by ENDS(0) (RFC 6891) in 2013, the DNS now handles larger packet sizes over UDP.
Needless to say, for every improvement made to the DNS protocol, hackers have found ways to abuse these improvements.
The larger DNS query response packets don’t replace better-suited file transfer protocols, as described in the Exfiltration section, but if that option fails, the C2 channel can accommodate the malware’s needs.
The amount of data that can be transported inside a DNS query response depends very much on the query. For example, the TXT record can contain multiple strings with a length of 255 bytes (RFC 4408), which makes it suitable for hiding encoded data in the answer. In addition, extra data can be encoded in a similar fashion in the authority and additional fields.
Mitigations and countermeasures
Threat actors usually have a large infrastructure in place to take advantage of the techniques mentioned in this article. It is not unusual for them to register thousands of domain names in advance, some of them appearing as legit organisations with websites that appear unsuspicious. A newly registered domain name that almost immediately gets thousands of DNS queries will set off alarm bells everywhere.
Monitoring DNS traffic (predominantly queries and responses) can seem monumental, especially for larger organisations where DNS queries can be counted in the millions per hour. But fear not. There are lots of solutions on the market addressing these issues.
Validating resolvers is also important. The amount of data the Base64 encoded RRSIG Signature field can carry is, of course, something that an attacker would want to exploit for data transport. But with a validating resolver, the make-up Signature wouldn’t match the owner’s name, and the query would fail.