Your DNS Is Hiding in HTTPS — This Is Why It Matters
DNS over HTTPS (DoH) encrypts DNS queries inside HTTPS on port 443, making them invisible to traditional port 53 DNS monitoring and bypassing enterprise DNS security controls. Threat actors abuse DoH by embedding DoH clients in malware to resolve C2 domains via public resolvers, exfiltrate data through DNS tunneling wrapped in HTTPS, and bypass content filtering and blocklists. The article recommends a controlled DoH architecture where endpoints are steered to approved enterprise resolvers, unauthorized public DoH providers are blocked, and DNS telemetry is correlated with HTTPS metadata for detection.
Detection / Hunteropenrouter
What Happened
DNS is the system that translates website names into IP addresses. Traditionally, these queries were sent in plain text, which meant anyone on the network could see or tamper with them. A newer protocol called DNS over HTTPS (DoH) encrypts these queries inside regular web traffic, protecting user privacy. However, this same encryption also hides DNS activity from corporate security tools that monitor for malicious domains. Attackers are taking advantage of this by building DoH into their malware to secretly contact command servers and steal data, all while looking like normal web browsing. Organizations that rely on older DNS monitoring are affected, as their tools cannot see encrypted DNS traffic. This matters because security teams lose visibility into which domains their systems are contacting, weakening their ability to block threats. Instead of blocking DoH entirely, organizations should route all encrypted DNS through approved internal resolvers, block unauthorized public DoH services, and combine DNS logs with network traffic analysis to detect suspicious patterns.
Key Takeaways
- DNS over HTTPS (DoH) encrypts DNS queries inside HTTPS on port 443, making them indistinguishable from normal web traffic and invisible to legacy port 53 DNS monitoring.
- Threat actors abuse DoH for stealth C2 resolution, DNS tunneling exfiltration, and bypassing enterprise DNS security controls, blocklists, and content filtering.
- Godlua and PsiXBot are documented malware families that embed DoH clients to resolve C2 domains via public resolvers like Google and Cloudflare, bypassing enterprise DNS logs.
- Simply blocking DoH is unsustainable as Windows 11, major browsers, and mobile platforms increasingly default to encrypted DNS; NIST SP 800-81r3 now requires FCEB agencies to use encrypted DNS where supported.
- The recommended approach is controlled DoH: steer endpoints to approved enterprise resolvers, block unauthorized public DoH providers, and correlate DNS logs with HTTPS metadata in a SIEM.
Affected Systems
- Windows 11 endpoints with opportunistic DoH upgrades
- Enterprise networks relying on port 53 DNS monitoring, RPZ rules, and DNS-based content filtering
- Browsers supporting DoH (Chrome, Edge, Firefox)
- Mobile platforms with encrypted DNS defaults
- Remote workers and BYOD devices outside enterprise network control
Vulnerabilities (CVEs)
None identified.
Attack Chain
- Initial Access: Malware embeds a DoH client or uses standard HTTP libraries to communicate directly with external DoH resolvers over HTTPS/443
- C2 Resolution: Malware resolves C2 domain names via DoH to public resolvers (e.g., Google dns.google, Cloudflare 1.1.1.1), bypassing enterprise DNS resolvers and port 53 monitoring
- Exfiltration: Data such as credentials and files is encoded into DNS queries and wrapped inside DoH requests to attacker-controlled domains via external resolvers
- Defense Evasion: DoH traffic blends into normal HTTPS sessions, bypassing DNS blocklists, RPZ rules, content filtering, and SIEM DNS logs that only capture plaintext port 53 traffic
Detection Availability
- YARA Rules: No
- Sigma Rules: No
- Snort/Suricata Rules: No
- KQL Queries: No
- Splunk SPL Queries: No
- EQL Queries: No
- Other Detection Logic: No
The article provides detection methodology and hunting workflows (correlating resolver logs with HTTPS metadata, flagging connections to known DoH providers) but does not include any formal detection rules or query syntax.
Detection Engineering Assessment
| Dimension | Rating | Rationale |
|---|---|---|
| EDR Visibility | Medium | EDR can detect process-to-network anomalies such as non-browser processes or unsigned binaries contacting known DoH provider IPs. However, EDR cannot inspect the DNS payload inside encrypted HTTPS without TLS inspection capabilities. |
| Network Visibility | Medium | Firewalls, proxies, SWGs, and NDR tools can identify HTTPS connections to known DoH provider IPs and hostnames via destination IP, SNI, and proxy log metadata. TLS inspection is required to see DoH-specific paths like /dns-query. Without TLS inspection, only session metadata is visible. |
| Detection Difficulty | Hard | DoH traffic is designed to blend with normal HTTPS on port 443. Detecting abuse requires correlating DNS resolver logs with HTTPS metadata to identify endpoints that have no matching resolver activity but show HTTPS connections to known DoH providers. Behavioral detection on top of metadata is needed since payload inspection requires TLS inspection, which is not always deployed. |
Required Log Sources
- Enterprise DNS resolver logs (query logs from approved resolvers)
- Firewall logs (outbound HTTPS connection metadata)
- Proxy/SWG logs (destination IPs, SNI hostnames)
- NDR logs (session metadata, behavioral patterns)
- EDR process-to-network correlation logs
- SIEM centralized DNS and HTTPS log correlation
Hunting Hypotheses
| Hypothesis | Telemetry | ATT&CK Stage | FP Risk |
|---|---|---|---|
| Endpoints making repeated HTTPS connections to known public DoH resolver IPs (such as Google 8.8.8.8/8.8.4.4 or Cloudflare 1.1.1.1) with little or no corresponding activity in enterprise DNS resolver logs may be bypassing the approved DNS control plane. | Firewall/proxy outbound HTTPS logs correlated with enterprise DNS resolver query logs in SIEM | C2 / Defense Evasion | Medium — legitimate applications or browsers with DoH enabled by default may trigger this if enterprise DoH policy is not yet enforced. |
| Non-browser processes or unsigned binaries making HTTPS connections to known DoH provider hostnames may indicate malware embedding a DoH client for C2 resolution. | EDR process-to-network correlation logs, binary signature verification | C2 | Low to Medium — some legitimate system services or update agents may use DoH, but non-browser processes doing so are uncommon. |
| High-frequency, low-volume HTTPS sessions to a single DoH provider hostname or a small set of associated IPs from back-end servers or unusual hosts may indicate a hard-coded DoH resolver used for C2 or tunneling. | NDR session metadata, proxy logs, firewall connection logs | C2 / Exfiltration | Medium — approved enterprise DoH resolvers may show similar patterns; context of destination and source role is needed to differentiate. |
| If TLS inspection is available, HTTP requests containing the /dns-query path to non-approved destinations may indicate unauthorized DoH usage. | TLS inspection proxy logs, SWG deep inspection logs | Defense Evasion / C2 | Low — the /dns-query path is specific to DoH endpoints; approved enterprise DoH resolvers should be allowlisted. |
| DNS queries with high-entropy or oddly formed subdomain labels that correlate with HTTPS sessions to external DoH providers may indicate DNS tunneling exfiltration over DoH. | Enterprise resolver logs (if traffic passes through), NDR behavioral analytics, SIEM correlation of DNS and HTTPS logs | Exfiltration | Medium — some legitimate services use long subdomain labels; entropy analysis alone produces false positives without behavioral context. |
Control Gaps
- Legacy DNS monitoring tools that only inspect port 53 cannot see DoH traffic on port 443.
- DNS blocklists, RPZ rules, and content filtering applied at enterprise resolvers are bypassed when endpoints use external DoH resolvers directly.
- SIEM DNS logs no longer reflect all domain resolution activity if endpoints resolve via external DoH providers.
- Network security tools without TLS inspection cannot inspect DoH payloads or identify /dns-query paths.
- Unmanaged or BYOD devices roaming outside the enterprise network bypass DNS policy enforcement entirely.
Key Behavioral Indicators
- HTTPS connections to known public DoH provider IPs (8.8.8.8, 8.8.4.4, 1.1.1.1) from managed endpoints with no matching enterprise resolver activity
- Non-browser processes contacting known DoH provider hostnames (dns.google, cloudflare-dns.com, 1.1.1.1)
- High-frequency, low-volume HTTPS sessions to a single DoH provider destination from back-end servers or unusual hosts
- HTTP requests containing /dns-query path visible via TLS inspection to non-approved destinations
- Endpoints with DNS resolver log silence but active outbound HTTPS sessions (resolver-HTTPS mismatch)
- Unsigned or newly seen binaries initiating HTTPS connections to known DoH resolver infrastructure
False Positive Assessment
Medium — legitimate applications, browsers, and operating systems increasingly use DoH by default for privacy. Detection based on connections to public DoH providers will generate false positives in environments where DoH policy is not yet enforced or where users legitimately use encrypted DNS. Behavioral indicators such as resolver-HTTPS mismatch and non-browser process DoH usage reduce false positives but require context about the endpoint's role and approved configuration.
Recommendations
Immediate Mitigation
- Verify against your organization's incident response runbook and team escalation paths before acting. Consider identifying endpoints making direct HTTPS connections to known public DoH providers (Google 8.8.8.8/8.8.4.4, Cloudflare 1.1.1.1) by reviewing firewall, proxy, or NDR logs.
- Consider correlating enterprise DNS resolver logs with outbound HTTPS metadata in your SIEM to flag endpoints with resolver-HTTPS mismatches indicating DoH bypass.
- If your firewall or SWG supports it, consider blocking outbound connections to known public DoH resolver IPs and hostnames from managed endpoints, except for approved enterprise DoH resolvers.
- Evaluate whether TLS inspection can be selectively enabled to detect /dns-query paths to unauthorized destinations.
Infrastructure Hardening
- Consider architecting a controlled DoH model where encrypted DNS is allowed only through designated enterprise resolvers and all other DoH paths are blocked at the firewall or SWG.
- If applicable, use Group Policy on Windows 11 to set known DoH servers or disable opportunistic DoH upgrades.
- Consider deploying enterprise browser policies for Chrome, Edge, and Firefox to specify allowed DoH providers and prevent silent switching to public resolvers.
- Evaluate blocking DoT at TCP port 853 and DoQ at UDP port 853 at the firewall, as recommended by NIST SP 800-81r3.
- If you support remote workers or BYOD, consider deploying lightweight DNS agents or ZTNA solutions that enforce DNS policy regardless of network location.
- Consider implementing certificate-based authentication for enterprise DoH endpoints to prevent unauthorized resolver use.
User Protection
- Consider deploying a DNS security layer that applies threat intelligence, domain risk scoring, and machine learning to DNS queries in real time.
- If supported by your tooling, consider using mobile device management to prevent users from manually configuring non-approved encrypted DNS services on managed mobile devices.
- Evaluate whether DNS-layer security services that follow the user rather than the network perimeter are appropriate for your off-network workforce.
Security Awareness
- Consider educating IT and security teams on the visibility gap created by DoH and the difference between DoT (port 853), DoH (port 443), and DoQ (UDP 853).
- If applicable, roll into existing awareness programs a note that browsers and operating systems may silently enable DoH, bypassing corporate DNS controls.
- Consider documenting the organization's approved DoH resolver policy and communicating it to network administrators and endpoint management teams.