DNS over HTTPS (DoH) is a protocol to perform remote resolution of the Domain Name System (DNS) over the HTTPS protocol. The proposed standard was published as RFC 8484 (October 2018) by the IETF.
The main objective of this protocol is to increase user privacy and security by preventing eavesdropping and manipulation of DNS data by intermediate attacks (MiTM) by using the HTTPS protocol to encrypt data between the DoH client and the DoH-based DNS resolver.
In short, DoH is really simple. Instead of going to port 53 of a DNS server and asking for a name through a UDP or TCP packet, DoH standardizes the construction of a GET or POST to an HTTPS domain, so the answer will be a json with the A and AAAA records (the RFC does not specify other records) with the IP.
For example, we can test the different DoH services quickly:
$ curl -H ‘accept: application/dns-json’ ‘https://mozilla.cloudflare-dns.com/dns-query?name=example.com&type=A’
{“Status”: 0,”TC”: false,”RD”: true, “RA”: true, “AD”: true,”CD”: false,”Question”:[{“name”: “example.com.”, “type”: 1}],”Answer”:[{“name”: “example.com.”, “type”: 1, “TTL”: 5859, “data”: “93.184.216.34”}]}
But protocol is a double-edged sword… ⚔️
DoH offers a new opportunity for users privacy, but also another opportunity for malware developers.
The malware usually reaches the command and control (C2) servers under the control of the attacker to extract stolen data or request instructions. Organisations commonly maintain DNS blacklists of known malicious domains. If a DNS request is directed to one of these domains, an alert will be immediately activated. However, if DNS requests are encapsulated and encrypted using DoH, these requests will no longer be so easily identified and this can be a new problem for security teams.
And the malware evidently did not take long to incorporate this technique ?
Several Netlab security researchers discovered and reported the first samples of malware used by DoH on July 1, 2019. Specifically, the Godlua malware in the second and third phases used DNS over HTTPS to obtain the address of its C2.
The DNS TXT record was stored in the Lua byte code file (start.png) in flat text. Disassembling it:
The malware then sent a DoH request to resolve that DNS TXT:
The response was an encrypted DNS TXT record:
Which in flat text returned:
{“u”:”http:\/\/img1.cloudappconfig.com\/%s.png”,”c”:”img1.cloudappconfig.com::43.224.225.220:”}
Another malware identified in September 2019 using DoH was PsiXBot, of general use in Windows but which became especially media-friendly because in its latest versions it introduced a module that activated the webcam and microphone if pornography was played on the victim’s computer.
This Trojan contained hardcoded command and control (C2) domains encrypted with RC4 which it retrieved using Google’s DoH service.
For example, requests and responses like this were observed:
All C&C servers observed used HTTPS with Let’s-Encrypt certificates and there were indicators showing the possible use of a fast-flux botnet.
And more recently, at the end of July 2020, Kapersky officially identified the first actor to incorporate DoH in their attacks. This was the Iranian group Oilrig (APT34) and it did so using the open source tool DNSExfiltrator, which it used to handle data and move it laterally across internal networks and then exfiltrate it to an external point.
Measures you can take against DoH attacks ?
Recent months have seen the incorporation of DoH into the cyber-threat landscape to evade the controls of many organisations. The following generic measures against this technique are recommended:
- Monitor DNS traffic through HTTPS (DoH) endpoints and, if not possible, block this type of network traffic or install internal DoH resolvers, or DNS through TLS (DoT).
- Whenever possible, inspect the underlying HTTPS traffic for indicators of DoH usage where TLS is inspected within the organisation. That is, ‘application/dns-json’, ‘application/dns-message’ content types.
- Look for possible ‘domain fronting’ indicators where the hostname of the outgoing TLS connection does not match the underlying HTTP host header.
- Apply detections based on heuristics or anomalies of packet sizes, frequency and volume, timing, etc. of outgoing traffic.
- Other detections are being considered where TLS stripping is not possible, such as collecting fingerprints of any observable SSL client behaviour using a tool such as JA3.
Main conclusions ?
By using DoH services, attackers can hide DNS queries from C2 domains. Unless SSL/TLS is being inspected using man-in-the-middle (MitM) techniques, DNS queries to the C2 server will therefore go unnoticed. A way needs to be found to protect organisations from this threat.
The biggest concern is that many companies have no record, no telemetry and no effective ways to mitigate abuse of the use of this new protocol. And there are already several malware campaigns that use DoH for C2 resolution and cover up communication through TXT logs.
Vicente Motos
Santander Global T&O
Currently working in the Santander Threat Response department focused on tactical intelligence, threat analysis and engineering. Self-taught and passionate about computer in-security and hacking for many years, I actively participate in the community and author of many technical posts.
