DNS over HTTPS as a covert Command and Control channel

DNS is known as one of the most fundamental and important protocols of the TCP\IP stack. We rely on DNS for the most basic online activities (like watching cat videos on Instagram).

Despite its importance, DNS (designed in the ‘80s) was developed with no security or privacy in mind. It has remained plaintext over the UDP transport protocol, allowing anyone ― from ISPs, threat actors, or government entities — to track, monitor, or intercept browsing activities and behaviors.

More recently, attempts have been made to improve DNS to meet modern security standards. These protocols include domain name system security extensions (DNSSEC), DNS over HTTPS (DoH), and DNS over TLS (DoT).

DNSSEC is a security extension to DNS. Using specifically defined DNS resource records, DNSSEC adds cryptographic signatures for responses from the authoritative DNS servers. This solution addresses the data integrity and authenticity issue, allowing validation of the response source. Unfortunately, and despite all efforts, it has not yet been deployed at a desirable rate.

DoH and DoT attempt to address confidentiality issues. The idea is to add an encryption layer (TLS) to the DNS traffic between the local application and the recursive DNS resolver. While DoT suggests a designated TCP port 853 for the DoT, DoH uses the existing HTTPS protocol.

Although DoH is an amazing technological and privacy advancement for consumers, it may pose serious risks and threats to organizations.

DoH — DNS over HTTPS

DoH, introduced in 2018 (RFC 8484), is the most widely adopted of these protocols as it uses the HTTPS (specifically, TLS) application layer to encrypt data in transit ― in this case, DNS queries. It was designed as a solution for web applications and first implemented by Firefox in 2019. Later, DoH support was added to most browsers. With DoH, rather than querying the configured DNS server, DNS traffic will be encrypted in transit and sent in the form of HTTPS with GET/POST requests to the DNS resolver supporting DoH (usually a public DoH provider). It, therefore, encrypts only the “last mile” DNS traffic ― between the end user's browser and the DoH provider.

This means that the DoH provider listens to HTTPS\443, and in some cases, HTTP\80 (but then does not use the TLS layer), handling DNS-web requests.

Figure 1 - DoH vs standard DNS

From the client side , for now, DoH is configured at the application level (usually browser) that takes control of DNS settings from the operating system, which is traditionally responsible for DNS configuration (DC's DNS, the organizational gateway, Google, etc). Starting with Windows 11/ Windows Server 2022, DoH can be configured in the operating system level as well.

Because the provider's domain would need to be resolved, this would be the only observed “traditional” DNS query — you probably see where we're going with this.

DoH impact on corporate security

In a corporate environment, controlling the DNS is almost mandatory. Directly addressing an external public service for DNS resolving may cause more concern than benefit and lead to the following:

• Bypassed DNS layer-based security defenses (blacklisted domains) that could previously be blocked in the DNS resolving stage, now can only be blocked after DNS resolving at the proxy gateway.
• Internal domain zones that must only be internally visible may be exposed to the public if resolving is requested from an external service.
• Behavioral DNS-based defenses are not possible anymore.
• This channel becomes a perfect private channel for malicious use, evading detection by using third-party DoH servers.

For these reasons, in general, browsers in managed environments either (1) disable the DoH option by default, (2) allow disabling the DoH configurations using with GPO control-related settings, or (3) by/ providing the option to set canary domains that disable this feature. Despite these precautions, it is still sometimes possible for the user to override these settings.

Command and control (C2) over DoH

The well-known DNS exfiltration method transmitting data via subdomain queries is now private.

In fact, the public DNS providers can now be used as a kind of a free domain fronting service for malicious activity over DNS. If a threat actor's C2 channel is DNS only, by using the DoH protocol, a malicious domain could stay encrypted ― the destination of the communication seen from the network would be the DoH service provider and not the true final destination.

To investigate this further, the Varonis Threat Labs tested an open-source tool published in 2019 that allows C2 communications over DoH. It is safe to say that this threat is, in fact, valid and impactful.

The following image is an intercepted DoH response to a DNS exfiltration attempt. The malicious domain controlled by the attacker can be seen along with data attached as its subdomain:

Figure 3 - DNS-over-HTTP request and response (Fiddler)

This time, unlike the traditional DNS exfiltration, the destination resolved by the configured local DNS server is a publicly available DoH resolver address — in this case, “dns.google.com.” However, because anyone can run their own DoH server, there are many other lesser-known DoH resolvers. The traffic will then proceed over HTTPS, where again the destination shown is the first hop ― the DoH provider ― that never directly communicates to the malicious server:

Figure 4 - C2 over DoH using GoDoH

In the traffic above, the FQDN being queried can be seen in the GET URL parameters, but may be transferred via POST as well, in which case the data would then reside in the HTTP body. The destination host remains the DoH service provider.

For example, using Cloudflare,'s a DoH provider front for communicating with a C2 domain, threat actors could potentially mask their covert channels and domains from detection, as the DNS requests are encapsulated within the “payload” (HTTP request body) containing the malicious domain or in the URL (HTTP GET parameters), both encrypted.

To summarize, enterprises should be aware that disabling DoH via GPO in-org browsers is not enough. Without taking further measures, any other browser application or malicious payload may now communicate privately via the encrypted DoH channel.

Recommendations

What can we look for?

1. Monitor HTTP communication with public DoH providers ― if you see DoH providers it means that something might be going on.
2. Enable controls to detect patterns of HTTP activity characterized by low volume payloads during long sessions (which could indicate communication with a rogue DoH server).