By Threat Intelligence Team

This research aims to present discussions about DNS over HTTPS (DoH) and how tools that offer this feature can expose corporate networks to risks and threats that abuse the protocol to conduct attacks.

1. Introduction

  • This protocol aims to provide greater privacy to users browsing the Internet. Tempest’s Threat Intelligence team has observed the growth of DoH providers and their usage over the years.
  • Since its proposal, the suggested standard documented in RFC8484 has received a lot of criticism from network administrators as well as security and infrastructure organizations.
  • Currently, the most popular web browsers, such as Google Chrome and Mozilla Firefox, support the use of the protocol.
  • Microsoft has inserted features in test versions of Windows 10 to enable the use of DoH.
  • Cybersecurity experts have presented experiments over the past few years that highlight the concerns and risks for those using the protocol.
  • The past year featured incidents that raised “red flags,” showing that attackers can misuse the infrastructure of legitimate public DoH providers to distribute malware and disguise malicious domains.

2. Definition and function

Several networking professionals discuss DNS protocol exploits as a transparency problem. Throughout the entire communication path from the requester to the DNS server that will indicate the destination of the access, any intermediary is aware of the information on both sides of the negotiation.

This means that every point in the communication process can see the content of the query and can identify which website the user is looking for, as well as being able to partially or entirely recover the requester’s IP address. A malicious agent could inappropriately take possession of this information, share it, or even change DNS traffic data.

The DoH, strongly advocated by Mozilla[1], suggests a change in the request process for name resolution. A standard proposed by the Internet Engineering Task Force (IETF) in 2018, the DoH (DNS over HTTPS, RFC8484[2]) applies a new way to send DNS queries and get DNS responses (RFC1035) over HTTP (RFC7540) using HTTPS connections (RFC2818).

Through this work, still in progress, the standard regulates how to format and maintain a service with greater privacy beyond the common name negotiation mechanisms. The protocol chaining must be able to receive resource requests (URIs) from web clients using DoH and translate the request to the desired resource address (URL). In other words, a DoH resolver uses URIs made available by the DoH server to perform a DNS request.

Through a web browser, any DNS request would first be resolved internally (Figure 1) if there is a trusted resolver already in use. This message exchange would be done without TLS encryption. Once the browser receives a response and starts requesting data from a public network, DNS queries in sequence are exchanged over port 443. The encrypted message traffic would be carried over an HTTPS connection to a DoH resolver, which would mediate the communication with the user to the destination content. This process can be considered homonymous to the secure HTTP standard, where only the client and the server are able to decrypt the message content.

Figure 1 – Representation of a DoH request through a browser and an HTTPS connection. Source: Mozilla. Image: Tempest.

2.1. Purpose of the RFP

The proposal’s goal in the RFP is to attach mechanisms that are capable of encrypting DNS requests to provide greater privacy and prevent users from man-in-the-middle attacks, which are at the heart of many current problems with DNS abuse.

2.2. Who’s Using It

In February 2020[3], Mozilla adopted the use of DoH as the default for Firefox users in the USA. This action was taken within a project aimed at improving DNS privacy in the browser already in 2018 when the RFC was proposed. Since version 62[4], it’s already possible to use this feature.

As of September 2020[5], Google announced that Chrome version 85 would start using DoH as a default on personal computers and Android devices. Currently, if the original provider of the content accessed by any user supports the protocol, it will automatically switch to DoH. This mechanism is also applied if DNS over TSL (DoT) support exists.

Microsoft added[6] support for DoH in the Insider version of Windows 10 in May 2020. According to the publication, the feature can be enabled through the Windows registry editor. These and other companies considered Big Techs are getting closer and closer to using and supporting the protocol more broadly. Each company has advocated the implementation in its own way, but all emphasize that their offering is justified by increased browsing privacy for any user over the Internet.

3. Overview

In this section, some of the already existing DNS monitoring and security problems will be discussed and related to points in the DoH proposal. Some proofs of concept (PoC) are mentioned, as well as threats that have abused the protocol to carry out attacks.

3.1. DNS Tunneling

Leakage techniques via alternative protocols aren’t new when it comes to cyber threats. Malicious actors have extensively abused DNS for quite some time as a command and control (C2) communication channel aimed at data extraction. Attacks known as DNS Tunneling[7] are one of the means adversaries use to encapsulate data from a protocol and send queries and responses through DNS to their servers. The malicious traffic captured in these attacks usually includes payloads that can be added to what is running inside a DNS server to control it remotely[8].

One of the problems discussed about the use of DoH is that it allows malicious agents to convey encapsulation and dynamic resolution techniques[9] to abuse HTTPS endpoints and pass themselves off as benign traffic. On top of this, the encrypted data brings an added difficulty for common security mechanisms that already monitor DNS.

3.2. DoHC2

In 2018, at the MITRE ATT&CKcon, David Middlehurst, a representative from Trustwave’s security team, presented research on techniques that can be used for malicious purposes in payload delivery and C2 server communication. In his framework (Figure 2), the researcher demonstrated how to use endpoint signatures for an attack to pass itself off as ordinary traffic through DoH abuse.

Figure 2 – Diagram of the victim sending communications to Cobalt Strike. Image: TrustWave.

The PoC[10], aliased DoHC2, is based on the use of the Cobalt Strike tool[11], commonly used by red team teams and cybercriminals. By creating an external C2[12], a Beacon was instanced to simulate adversary operation and communicate with the DoH server.

The diagram presented demonstrates the path implemented in the attack. This model allowed the code inserted in the C2 commands and the communication traffic with the victim to be observed only as common traffic (Figure 3) by the ISP.

Figure 3 – Demonstration of the Beacon making requests to the DoH provider. Source: TrustWave.

The research also highlighted that at least one DoH provider executed a call to a resolver that shared the initial host’s IPv4 address with other services when performing the requests. This means that abuse of DoH can also be tied to another technique known as domain fronting.

3.2.1.  The resurgence of Domain Fronting

This is a technique used[13] by adversaries exploiting routing schemes managed by a content delivery network (CDN). By adopting different domain names for each layer of HTTPS communication, it’s possible to obfuscate the intended destination of the traffic, hiding the malicious site information. This is accomplished by using different domain names in TLS and also HTTP data headers. If the domains are provided by the same CDN (Figure 4), a user is redirected to the malicious domain by unpacking the request header data.

Figure 4 – Diagram of the technique exploitation. Image: Kaspersky.

The controversies of some security incidents caused Google and Amazon to remove the features that enabled domain fronting in their services. In 2018[14], Google announced that Google App Engine would no longer support domain fronting, and AWS made very similar changes on CloudFront, making the application of the technique, at first, impractical.

3.3. goDoH

Leon Jacobs from SensePost published in October 2018[15] a PoC that implements a data leak mechanism via DoH, exemplifying how the process of DNS overlay over HTTPS works. The researcher makes an analogy to using a JSON API capable of performing simple HTTP requests through a provider like Google to perform DNS lookups. According to Jacobs, legitimate domains could forward traffic to a C2 and avoid blocking and screening by security mechanisms. For him, this would be a new way to bypass the control of a CDN and perform domain fronting.

This is demonstrated through a tool entitled goDoH. In his experiment, a framework was used that focuses on monitoring DNS traffic (Figure 5) with an internal resolver and an application firewall. In this model, the security configuration of the internal DNS and the firewall are able to filter and act on the flow of DNS requests, following the traditional framework that exists in many organizations.

Figure 5 – Traditional structure, the first part of the experiment. Image: SensePost.

From this diagram, the research transfers the resolution of DNS requests to a DoH provider (Figure 6).

Figure 6 – Modification performed on the DNS server, directed to a DoH provider. Image: SensePost.

The presented structure already brings a discussion point about how this change impacts the monitoring of DNS traffic flow. From what is presented, the DNS trust factor is undefined, as it is no longer treated as a specific protocol. Internal filters such as proxies and DNS resolvers cannot interpret requests to the new provider. HTTPS requests encapsulating the DNS query contain a URL to a generally trusted domain. A Google DoH server, for example, can be used to avoid traditional monitoring frameworks.

Once the goDoH components are started (Figure 7), a DNS TXT record lookup is performed for the target domain, which in the text file has the format agentidentifier.targetdomain. As soon as the server receives the query, if this is the first time the agent is performing it, the C2 registers the existence of this new identifier as an interaction flow. If there are no commands to be executed, only a default response is sent with no commands. This loop is repeated infinitely through intervals defined in the code to maintain communication.

If there are commands to be executed, encoded, compressed, or encrypted, they are sent within the lookup TXT of the response.

The DoH agent then analyzes the response from the record and interprets the action to execute the command. With the result, the output goes through an encryption process and is finally translated, with its data partitioned into pieces to be sent as a central DNS lookup record. Based on the IP address of the response data, it’s possible to indicate if this process was successful.

Figure 7 – Example of the described process of successful command execution by goDoh. Image: SensePost.

On the server-side, a flag is read to understand whether an incoming request starts a new flow, is part of a pending flow, or is the end of a flow and decides based on that what the next step should be.

After a DNS lookup flow is completed, the protocol type is checked, and action is taken (Figure 8). This can be either a command output displayed on the screen or a file download where the content is to be saved.

Figure 8 – Downloading the payload sent by the C2 via the protocol. Image: SensePost.

At the beginning of the RFP proposal, there were few providers. A query via cURL can currently list more than 40 organizations[16] that maintain multiple DoH public servers. On the library’s Wiki page, a scrape[17] is provided to scan the main providers, public and private (Table 1).

Table 1 – Most popular public DoH servers in operation. Source: cURL GitHub.

3.4. Threats

In 2019, a team from Netlab360[18] reported the discovery of a malware variant abusing the DoH protocol. Named Godlua because its source code is based on the Lua language, the backdoor acts on Linux servers, on which the attackers were exploiting a Confluence flaw (CVE-2019-3396[19] – CVSS 9.8) that allowed them to perform fake server-side requests (SSRF) through the WebDAV plugin[20]. The research showed that the malware works as a DDoS bot and one of the features existing in the samples is that Godlua performs DoH requests to retrieve TXT records from a domain containing the URL that stores information about the server used to store data and receive commands from the C2.

Again, the use of the protocol to encrypt the domain data and offer the service via a URL with the C2 information invisible to mechanisms that monitor DNS, preventing its blocking, is highlighted.

John Hammond, a researcher at HuntressLabs, reported in August 2020[21] adversaries abusing Google’s DoH providers to load malware. According to BleepingComputer[22], criminals were using fake Windows error logs to hide malicious payloads that were loaded into unauthorized scheduled tasks on Windows servers (Figure 9).

Figure 9 – Fake Windows error logs. Image: BleepingComputer.

Hammond’s analysis found a suspicious URL in the payload code. Once all tasks are executed, it’s possible to recover the suspicious URL within the malicious PowerShell code. In other words, Google’s DoH is being used to resolve a request to a suspicious domain that, when consulted, responds with a new malicious payload.

The return communication contains in the data space of the packet a signature similar to a DKIM email authentication[23]. This is a header added to the message with encrypted content that is used to verify the user and email profiles from a recipient to a domain owner. When decrypting the contents of this header, decimal representations of malicious IP addresses are found, which are used in new queries to C2 (Figure 10) as a way to decentralize the infection infrastructure. This technique was used to obfuscate information that can decipher data in network packets to analyze the content of HTTP requests.

Figure 10 – The ping command is run over one of the decrypted decimal values from the payload, returning an IP address of one of the C2 servers. Image: HuntressLabs.

The attackers have managed to inject malicious URLs into Google’s DoH TXT records that, once encrypted, appear harmless to security monitoring, and even when decrypting them, the malicious plaintext content can go undetected. Adding this to the malware’s delivery method over Windows errors added layers of complexity that helped attackers avoid detection. The researcher points out that this would go undetected by many modern antiviruses.

4. Opinions and rejection

There are several criticisms[24] from the security and network infrastructure community about the DoH and what the project actually delivers to users. Several experts have already stated that the privacy factor is not enough to ensure safe browsing. Through data about which URL is being accessed and other information loaded into HTTP or HTTPS requests (such as SNI fields), ISPs can track users, even when they can only distinguish the source and destination of the communication.

Part of the criticism addresses how the DoH ignores enterprise policies, negatively impacting administrators who use local DNS servers. The DNS protocol’s subscription method can be used to bypass filtering and security mechanisms based on DNS traffic. Similarly, adversaries can encapsulate data by using the DNS protocol to avoid detection and network filtering. This also makes it difficult for administrators to apply means to prevent hijacking attacks on their servers, as static analysis tools on the information exchanged through DNS have failed to interpret the data required for their content filtering.

APNIC (Asia Pacific Network Information Center) has published[25] an opinion piece on how the DoH evades a privacy agreement already enforced on ISPs. The DoH proposal comes with implementing new resolvers, thereby not using the existing DNS server ecosystem for network traffic control. This point was presented as a criticism stemming from the fact that new servers would maintain encryption and thus run away from the current DNS layer infrastructure, allowing an attacker to provision a DoH server for monitoring what is trafficked without the knowledge of the CDN, for example.

Finally, the discussion addresses that those responsible for proposing the DoH also agree that the protocol does not fix all user privacy and metadata leaks. The DoH proponents further stated, according to APNIC, that the goal of the project is to give the user the ability to browse any network, secure or not, with complete privacy.

5. Mitigation and Monitoring

Both DoHC2 and goDoH were used to analyze protocol usage behavior in organizations. SensePost used an HTTP proxy (Figure 11) to observe how client-server communication is translated with goDoH and encourages security teams to use the tool in their test environments.

Figure 11 – An example of goDoH C2 communication viewed through an HTTP Proxy. Image: SensePost.

Trustwave’s analysis ends with some recommendations for monitoring:

  • Block or monitor endpoint traffic over DoH services. If it’s in the organization’s interest, it’s recommended to study the implementation of internal resolvers;
  • Create routines to inspect underlying HTTP requests for indicators of DoH server communication, such as decrypted TLS content in ‘application/dns-json’ or ‘application/dns-message’ fields;
  • Create routines to leverage domain fronting recognition, where the host name of the outgoing TLS connection does not match the host in the underlying HTTP header;
  • Apply detections based on heuristics (multiple criteria/alert analysis on network traffic) or packet sizes, frequency and volume, connection time, or requests between domain and destination.

A SANS Institute research[26], published in April 2020, implemented goDoH as a delivery mechanism for a test malware in three different scenarios to analyze generated artifacts that can be used to detect malicious behavior through DoH.

This research used VMWare ESXi host-based virtual environments containing a pfSense firewall (integrated with Suricata, open-source IDS/IPS) as a gateway to the local network. In each scenario, Firefox was configured to use CloudFlare’s DoH provider. All this was observed centrally in Security Onion, an open-source Linux distribution for threat hunting, security monitoring, and log management.

In the first scenario, no additional logging for monitoring enrichment was enabled in the VM. The captured traffic allowed the identification of DNS queries through Firefox. The nature of the encrypted traffic could not be fully translated. Still, Suricata generated several alerts based on traffic monitoring from CloudFlare’s DoH provider through a policy that observes SNI (Server Name Indication) to identify DoH traffic.

In the second scenario, the experiment’s goal was to identify more indicators that ensure visibility. This was done by enabling Firefox’s HTTP traffic logging[27]. DoH queries were captured and collected from ElasticSearch. Thus, Security Onion was used to deciphering traffic data from recognized DoH queries and responses in the environment (Figure 12).

Figure 12 – Example of the analysis of data generated by Firefox monitoring. Image: SANS.

In the third scenario, a new method was used to analyze encrypted data that went beyond what was trafficked in the web browser. If the host were compromised by other malicious agents using port 443 for communication, this would be transparent to the detection of scenario 2. Therefore, a tool was used to analyze all network traffic over the port, PolarProxy. The pfSense[28] was configured to redirect all TLS traffic to PolarProxy, which decrypted the content destined for port 443 and sent a copy of the data to ElasticSearch.

It was possible to identify deviations in the size of packets negotiated between goDoH C2 and the infected host, classify the communication interval with Beacon and the C2, and also identify the malicious domain name used in the experiment (Figure 13).

Figure 13 – Example of the data analysis deciphered by monitoring all TLS traffic. Image: SANS.

6. Analyst Commentary

The DoH application has gone, from 2018 till now, from an experimental environment to being offered in web tools and large enterprise systems through widespread products in the market. The issues presented in this paper signal risks and the inevitability of a discussion about the use and monitoring of the DoH.

In a series of updates published in March of this year, Cobalt Strike 4.3[29] added support for new malleable DNS Beacon groups and DNS host indicator changes options. The most eye-catching feature is that Cobalt Strike now allows DNS Beacons[30] to specify which resolvers should be used instead of the defaults that a browser sets. This feature gives an adversary permission to configure communication through public resolvers, i.e., enabling the use of DoH providers or even malicious providers.

The research published by the SANS Institute pointed out examples of how to monitor DoH traffic present in corporate networks, and it is highly recommended that each entity apply its own analysis, reporting on how DoH is being used in its internal network and thus enabling the creation of network security policies that match the organization’s operating and working needs.

Tools that allow practical exploitation of the DoH protocol and existing criticisms emphasize that it may become a vector for carrying out more sophisticated attacks, especially if common browsers begin to offer full DoH support by default.


[1] A cartoon intro to DNS over HTTPS. Mozilla. May 31, 2018. Available at

[2] DNS Queries over HTTPS (DoH). P. Hoffman e P. McManus. October 2018. Available at

[3] Firefox continues to push to bring DNS over HTTPS by default for US users. Mozilla. February 25, 2020. Available at

[4] Improving DNS Privacy in Firefox. Mozilla. June 01, 2013. Available at

[5] A safer and more private browsing experience on Android with Secure DNS. Google. September 2, 2020. Available at

[6] Windows Insiders can now test DNS over HTTPS. Microsoft. May 13, 2020. Available at

[7] Protocol Tunneling. MITRE. March 27, 2020. Available at

[8] Application Layer Protocol: DNS. MITRE. October 21, 2020. Available at

[9] Dynamic Resolution. MITRE. October 2, 2020. Available at

[10] Playing with DNS over HTTPS (DoH). dtmsecurity Blog. November 21, 2018. Available at

[11] Cobalt Strike. MITRE. April 24, 2021. Available at

[12] ExternalC2. Ryhanson Github. November 23, 2017. Available at

[13] Proxy: Domain Fronting. MITRE. September 16, 2020. Available at

[14] As Google and AWS kill domain fronting, users must find a new way to fight censorship. TechRepublic. May 2, 2018. Available at

[15] Waiting for goDoH. SensePost. October 28, 2018. Available at

[16] Publicly available servers. cURL GitHub. April 23, 2021. Available at

[17] Scrape DoH provider URLs from cURL’s wiki page. Kimbo GitHub. April 13, 2021. Available at

[18] An Analysis of Godlua Backdoor. Netlab 360. July 1, 2019. Available at

[19] CVE-2019-3396 Detail. NIST. February 9, 2021. Available at

[20] Web-based Distributed Authoring and Versioning. Wikipedia. Available at

[21] Hiding in Plain Sight || Part 2. HuntressLabs. August 20, 2020. Available at

[22] Attackers abuse Google DNS over HTTPS to download malware. BleepingComputer. September 2, 2020. Available at

[23] Domain Keys Identified Mail. Available at

[24] DNS-over-HTTPS causes more problems than it solves, experts say. ZDNet. October 6, 2019. Available at

[25] Opinion: Centralized DoH is bad for privacy in 2019 and beyond. APNIC. October 3, 2019. Available at

[26] Dealing with DoH: Methods to Increase DNS Visibility as DoH Gains Traction. SANS Institute. April 16, 2021. Available at

[27] HTTP logging. Mozilla. Available at

[28] PfSense. PfSense Org. Available at

[29] Cobalt Strike Release Notes. HelpSystems LLC. Available at

[30] Cobalt Strike DNS Direct Egress Not That Far Away. DTMSecurity. March 3, 2021. Available at