Detecting DNS over HTTPS
What is DNS over HTTPS (DoH)
DoH secures DNS queries by encapsulating them within HTTPS traffic, leveraging encryption to mitigate interception and mitm attacks. Initiated by Google and Mozilla, and notably adopted by Firefox at first, DoH has shifted the DNS landscape towards greater privacy.
Defined in RFC 8484, DoH uses HTTP/2 or HTTP/3 for transport, carrying DNS data with the application/dns-message MIME type. This standard allows for server push capabilities, optimizing DNS resolution efficiency, but it can be modified. It is possible for a server to use a different MIME type for a custom application but this would not be compliant with the DoH standard.
Simple example flow diagram for a DNS over HTTPS request
Content received by the user device:
DNS over TLS (DoT) vs DNS over HTTPS (DoH)
DNS over TLS (DoT) stands as a counterpart to DoH, providing a parallel approach to DNS query encryption. The distinction lies in their encryption delivery mechanisms: DoT employs TLS, traditionally on a dedicated port (853), while DoH uses HTTPS, sharing port 443 with standard web traffic. The debate over the superiority of DoH or DoT often hinges on the balance between privacy and security they offer, which can be subjective and context-dependent.
I advocate for DoT due to its straightforward detectability and manageability (easily blocked or monitored at the network level), whereas privacy proponents may prefer DoH for its ability to blend with regular web traffic, offering enhanced obscurity and bypassing network restrictions. Ultimately, the choice between DoH and DoT may be best determined by the environmnet and the specific requirements and constraints of the use case at hand.
How is DoH used by malicious actors ?
C2 communications and Data Exfiltration
Multiple malwares have been observed using DNS over HTTPS for C2 communications and Data Exfiltration
- ChamelDoH
ChamelDoH is a C++ implant for Linux systems that uses DNS over HTTPS (DoH) for communication.
ChamelDoH gathers system information and can perform basic remote access tasks like file manipulation and command execution. It uses a modified base64 alphabet for DNS communication to avoid using non-alphanumeric characters, which can’t be transmitted via DNS.
Stairwell’s research discovered 10 samples of ChamelDoH, with one sample that was undetected on VirusTotal in June 2023 https://www.virustotal.com/gui/file/92c9fd3f81da141460a8e9c65b544425f2553fa828636daeab8f3f4f23191c5b/behavior
The malware encrypts its communication with AES128, and uses legitimate DoH cloud providers:
- Godlua
Godlua is an Lua-based backdoor malware using DNS over HTTPS (DoH) to secure its communication channels and targets both Linux and Windows systems. By leveraging DoH, Godlua conceals the URLs of its command-and-control (C2) servers, which are retrieved from DNS TXT records during the infection’s initial stage.
The Monitoring Impact in Enterprise Networks
DoH and DoT in Enterprise context
In a corporate environment, the use of DoH or DoT will complicate our ability to monitor for and investigate malicious activity.
To maintain visibility on C2 communications and Data Exfiltration with DoH, as i mentionned earlier, it is necessary to deploy network monitoring solutions capable of decrypting HTTPS traffic to inspect DoH queries.
My advice is to adjust your firewall and proxy settings to enable HTTPS traffic decryption and SSL inspection on trusted network areas and actively prevent any DoH traffic within these zones. Regarding DoT, either decrypt traffic on the port 853 or to completely restrict it within the trusted network areas
⚠️restrictions can inadvertently block legitimate traffic and affect applications that rely on these protocols, knowing your environment is key !
Discussions
Antony Ma initiated an interesting conversation on Reddit, you can find experiences on how various individuals and organizations are implementing SSL inspection. I am not sure about the legal implications of SSL inspection in the EU as it has to ensure that any interception of encrypted communications complies with relevant laws, regulations, and organizational policies. However, lacking at least HTTPS decryption in your critical network zones means you will be overlooking significant security threats.
Detecting DNS over HTTPS with a SIEM
Signature-Based detections of DoH traffic
While DoH encrypts the content of DNS queries, certain characteristics can still be used as signatures for detection:
- Advanced firewall and proxy solutions can employ TLS fingerprinting techniques to scrutinize the initial TLS ‘client hello’ messages. These messages can carry unique fingerprints that differentiate DoH traffic from standard HTTPS communications. They can also monitor and analyze the patterns of HTTPS request traffic focusing on the volume, frequency, and size of the packets. A high volume of requests directed at a single domain or consistent request sizes that align with typical DNS query lengths could be indicative of DoH activity. When HTTPS decryption is feasible, these solutions can directly identify and inspect the contents of a DoH request. Even without decryption capabilities, they can often infer the presence of DoH queries through behavior analysis and pattern recognition.
Examples DoH traffic Logs with Fortigate firewall
Interesting fields for detection of DoH:
- app=DNS.Over.HTTPS (the most reliable signature for Fortigate)
- service=”DNS-DoH_DoT”
- dstinetsvc=”DNS-DoH_DoT”
- protocol=”DNS-DoH_DoT”
Examples DoH traffic Logs with PaloAlto IPS (packet inspection)
Interesting fields for detection of DoH:
- app=”dns-over-https”
Examples DoH traffic Logs with Proxy Cisco WSA
Interesting fields for detection of DoH:
- category=”DoH and DoT” (correlation with the severity score is advised)
Examples DoH traffic Logs with Proxy Zscaler (with HTTPS decryption)
In this example with Zscaler we have the full requested url with the address to resolve ostpreussen[.]net.[REDACTED].ads-promo.com (in the address we have the domain refferer which is ostpreussen[.]net with the client IP address and a tracking ID in the REDACTED part)
If the request was authorized, the client would get the following response from the DoH google server:
In this case the data contains a base64 string with the malicious destination
Interesting fields for DoH signature detection:
- category=”DoH Services”
- urlcategory=”DoH Services”
Hunting for DoH requests is facilitated by having these types of signatures provided by your proxy, IDS/IPS, or firewall solutions.
When HTTPS decryption is enabled you can even parse the domain name resolved in each url automatically and have your scheduled searches detect bad reputation and malicious domain names in the url of the DoH domains.
Pattern Detections of DoH traffic
Domain and URL Tracking, this can be achieved by maintaining an updated list of domain names and URLs linked to well-known DoH providers. For organizations that may not have access to a Cyber Threat Intelligence (CTI) feed or advanced firewall or proxy capabilities with integrated signature intelligence, you can use this list of known DoH servers https://github.com/mthcht/awesome-lists/blob/main/Lists/dns_over_https_servers_list.csv for hunting potential DoH communications within your proxy, IDS/IPS and DNS logs.
To streamline the hunting process and enhance network security posture, consider delineating specific VLANs where DoH traffic is deemed unnecessary or unauthorized and should be blocked.
Simple example searches with splunk, assuming dest_host is the field containing the domain names and url the full url requested in your logs.:
- match on DoH url servers requested with splunk in your proxy logs (with HTTPS decryption enabled it’s the only log source that should give you the full url requested for an investigation):
`myproxylogs` [|inputlookup dns_over_https_servers_list.csv | fields url]
match on DoH domain names requested (when you don’t have HTTPS decryption, at least you know DoH has been used):
`myproxylogs` [|inputlookup dns_over_https_servers_list.csv | fields dest_host]
`myidslogs` [|inputlookup dns_over_https_servers_list.csv | fields dest_host]
`mydnslogs` [|inputlookup dns_over_https_servers_list.csv | fields dest_host]
For hunting without domain names or full url, we can search for the usual default uri path (subject to false positives):
url="*/resolve?name=*"url="*/resolve?*&name=*"url="*/query?name=*type=TXT*"url="*/dns-query?name=*"url="*/dns-query?*&name=*"
The usual subdomain most of the doh provider used: dest_host=doh.* (where dest_host is the field containing the domain name, you can also parse the subdomains in another field on your SIEM)
you can also search for the http_content_type application/dns-message in your proxy logs to hunt for DoH communications (if it’s compliant with the RFC)
On windows systems, we can detect when someone is adding a DoH server configuration to the supported DoH servers with powershell:
Add-DNSClientDohServerAddress * -ServerAddress *
or setting up DoH with Set-DnsClientDohServerAddress:
Set-DnsClientDohServerAddress *-DohTemplate *
set the DNS server to a DoH-capable server with netsh:
netsh interface ip set dns+ commandline contains one of the DoH providers in my list
You must re-direct all standard DNS outbound (UDP 53) to an internal server. This ensures the bootstrap address is your DNS server.
Detect DoH tools:
- greyware tools https://github.com/curl/curl/wiki/DNS-over-HTTPS#doh-tools (On linux, we can search the configuration of dnscrypt-proxy for example (/etc/dnscrypt-proxy/*)
- C2 https://github.com/sensepost/godoh
- C2 https://github.com/SpiderLabs/DoHC2
- C2 https://github.com/outflanknl/DoH_c2_Trigger
I’ll try to add them to the https://github.com/mthcht/ThreatHunting-Keywords project soon
You also have the following sigma rules availables :
- Insecure Proxy/DOH Transfer Via Curl.EXE https://github.com/SigmaHQ/sigma/blob/master/rules/windows/process_creation/proc_creation_win_curl_insecure_porxy_or_doh.yml
- DNS over Https enabled in registry https://github.com/elastic/detection-rules/blob/main/rules/windows/defense_evasion_dns_over_https_enabled.toml & https://github.com/SigmaHQ/sigma/blob/master/rules/windows/registry/registry_set/registry_set_dns_over_https_enabled.yml
Conclusion
I hope this article has provided you with valuable insights into the complexities of detecting DNS over HTTPS (DoH) within your network.
If you have additional updates for the list of known DoH servers, please feel free to contribute (i did not test all of them)
Happy hunting !
