Blog Post

Finding the Needle in Haystack: Threat Hunting for Attacker Activity within DNS over HTTPS(DoH)

Introduction

DNS over HTTPS was introduced to protect the privacy and prevent manipulation of DNS data by utilizing HTTPS to encrypt it. The protocol offers increased privacy for users but presents new challenges for enterprise security teams and new opportunities for adversaries. As DNS is a backbone of the inter-connected world, it has become a popular choice of adversaries to carry out adversarial behavior such as “Exfiltration Over Alternative Protocol” and “Command and Control” or both. And while this is one of the slowest techniques available to the attacker, it has the advantage of stealth given its ease to blend in with the large volume of legitimate DNS traffic on a typical network. However, threat hunting for attacker activity within DNS over HTTPS (DoH) is not a lost cause as we will show in this article.

Technical Details

To accomplish exfiltration over traditional DNS or DoH, an adversary needs a domain name that they can control and the domain nameserver (NS) should point to the C2 server.

For the sake of understanding let’s see how a traditional C2 works through DNS:

Packet flow in case of traditional C2 over DNS-DNS over HTTPS ThreatFigure 1: Packet flow in case of traditional C2 over DNS

As figure 1 shows, an infected computer periodically polls for the commands to run, and the response is encoded in a series of A, AAAA, or TXT records which are sent to the attacker-controlled nameserver and eventually decoded at the server-side.

The concept is relatively similar for DoH with the difference being the usage of open DoH providers for lookups e.g. Google, Cloudflare, Quad9, etc. Figure 2 depicts the C2 over DoH.Packet flow in case of C2 over DoH-DNS over HTTPS Threat

Figure 2: Packet flow in case of C2 over DoH

Let’s dive into the individual steps in this process:

Step 1: The victim computer sends a domain request to an internal DNS resolver for one of DoH providers, say for example https://dns.google.com

Step 2: It is very rare in any organization for the domain google.com or its subdomains to be filtered.

Step 3: The internal DNS server request then goes to https://dns.google.com

Step 4: DoH uses traditional DNS to resolve a name.

Step 5: DoH responds with an answer to the DoH client.

As you can clearly see, a security team looking to monitor C2 over DNS can no longer rely on sinkholing all DNS activity. Instead, we now have added complexity of encapsulation over HTTPS and the DNS request itself being proxied through dns[.]google[.]com or one of the many other open DNS providers.

Proof of Concept (PoC)

We will use two tools to demonstrate the above process. They are:

GoDoH C2 framework has two components. One is the Agent and the other is the C2(Server). The GoDoH framework provides a command-line switch to run GoDoH in respective modes. The GoDoH Agent runs on the victim’s computer and is responsible for receiving commands from the GoDoH C2(Server). It then decodes, processes, and sends responses back to the C2 Server. A successful connection and data transfer between the agent and C2 server are shown in Figures 3 and 4 below.

GoDoH C2 using Google as a DoH provider-DNS over HTTPS Threat

Figure 3: GoDoH C2 using Google as a DoH provider

GoDoH Agent using Google as DoH Provider-DNS over HTTPS Threat

Figure 4: GoDoH Agent using Google as DoH Provider

If we look at the actual network packets in the interaction between the agent and C2 server (Figure 5), we can observe that there is an outbound request sent to the Google DoH provider and after a successful connection, all the subsequent traffic is over TLS. This connection is used to run commands on victim systems by an adversary.

GoDoH Agent - Server Communication Packet Flow-DNS over HTTPS Threat

Figure 5: GoDoH Agent – Server Communication Packet Flow

To use Cobalt Strike for DoH capabilities we need a tool called TitanLdr. This tool is required because by default Cobalt Strike doesn’t support DoH. TitanLdr is a user-defined reflective loader that hooks the Cobalt Strike beacon’s import address table(IAT) to replace the API call responsible for making traditional DNS queries with a function that makes DoH queries. The code can be seen in DnsQuery_A.c. TitanLdr beacons to a randomly chosen hard-coded DNS over an HTTPS server. The hard-coded DoH server names can also be found in DnsQuery_A.c.

DNS over HTTPS servers used by TitanLdr-DNS over HTTPS Threat

Figure 6: DNS over HTTPS servers used by TitanLdr

To get going we need to compile TitanLdr and import the titan.cna aggressor script into Cobalt Strike and we are all set.

Next, we configure a DNS listener. Once the beacon is running on the victim system, we will get the callback and all the subsequent communication would be performed over DoH (Figure 7). This traffic flow corresponds to the beacon activity based on the tasks executed on the infected system.

Figure 7: Packet flow in case CS DoH

In our proof of concept, we used the DNS beacon to execute a few tasks such as process list, token stealing of process explorer(pid 360) etc. (Figure 8) Figure 8: Callback by beacon and task execution over DoH beacon

Threat Hunting / Detection

Fortunately, the Arista NDR platform has a unique ability to chain multiple network events together using recursive lookups. This is like running a filter on all network traffic, then using those results to perform follow-up queries. These can then be presented as a Situation that automates the typically manual investigative process involved once you find a beacon like this on your network (Figure 9).

Stage 1: In stage 1 an Arista NDR model named “C2: HTTP Cobalt Strike direct to IP” detects the use of Cobalt Strike for DoH exfiltration.

Stage 2: Stage 2 is detected by a model named “Compliance: DNS over HTTPS” that triggers since the traffic contains domains which provide DoH capabilities.

Figure 9: Situation demonstrating discovery of a DoH C2 beacon (stages 1 and 2)

Stage 3: Stage 3 detects traffic flow between a Windows computer and opendns.com for the first time. By itself this would not be flagged as suspicious but when it is put in the context of the stage 1 detection of a Cobalt Strike Beacon traffic flow, it becomes a lot more interesting.

Stage 4: Similarly, in stage 4 the platform detects traffic flow between a Windows computer and quad9.net for the first time. Again, this adds further corroborating evidence to the Cobalt Strike Beacon traffic flow.

Figure 9: Situation demonstrating discovery of a DoH C2 beacon (stage 3)

Conclusion

Arista NDR identifies DoH exfiltration attempts through models that chain together behaviors such as the use of CobaltStrike on the network followed by a DoH connection from the same device. This ability to chain network behaviors over time allows the Arista NDR platform to detect threats like this without creating a lot of noise for the security team by simply flagging every DoH connection. If you would like to know more about detecting the abuse of DoH for data exfiltration please contact us.

Subscribe!

If you liked what you just read, subscribe to hear about our threat research and security analysis.

Raghvendra Mishra
Raghvendra Mishra

Threat Research Specialist, Awake Labs