Detecting DNS-over-HTTPS C2 Evasion: When Threat Actors Encrypt Their DNS

DNS has been a detection mainstay for blue teams for good reason: it’s historically plaintext, logged at the recursive resolver, and adversaries have long used it for C2 communication in ways that leave detectable footprints. DNS-over-HTTPS (DoH) disrupts this. When an adversary uses DoH, their DNS queries are encrypted inside HTTPS traffic sent to a known DoH provider — Cloudflare (1.1.1.1), Google (8.8.8.8), NextDNS, or a purpose-built resolver — and your DNS logs see nothing.

Several active threat actors have integrated DoH into C2 frameworks. GreenCharlie (a Mint Sandstorm subgroup) has used DoH for initial C2 resolution. The Bandcamp RAT (used by multiple Russia-linked actors) documented DoH resolver usage. Commercial C2 platforms including newer Sliver configurations support DoH. The pattern is expanding as defenders improve DNS monitoring coverage.

Why DoH is a Detection Problem

Traditional DNS monitoring works because queries pass through your recursive resolver and your DNS logs capture the query, response, and requesting IP. You can alert on DGA patterns, known malicious domains, unusual TLDs, or high-frequency subdomain queries.

DoH moves DNS resolution out of your network. Queries are sent as HTTPS POSTs or GETs to a DoH resolver endpoint — indistinguishable from normal HTTPS traffic at the packet level. Your DNS forwarder never sees the query. Your DNS logs show nothing. The only artefacts are:

1. A TLS connection to a known DoH provider’s IP or SNI
2. POST requests to a DoH endpoint path (/dns-query)
3. Unusual process behaviour — a process that should never make DNS queries directly establishing HTTPS connections to resolver infrastructure

Detection Approach 1: Block and Alert on DoH Provider IPs

The most reliable primary control is to block DoH at the network layer, forcing DNS queries back through your resolver. If you block known DoH provider IP ranges and monitor for attempts to reach them, you get detection coverage and an enforcement mechanism simultaneously.

Known DoH endpoints to monitor and block:

Adversary-operated DoH resolvers will not be on this list. But most adversaries using DoH start with commodity providers before investing in private resolver infrastructure. Blocking/alerting on known providers catches the majority of cases and raises the cost for the rest.

Sigma rule — outbound DoH to known resolvers (network telemetry):

title: Outbound DNS-over-HTTPS to Known DoH Resolvers
id: 8e3a7c91-2b4f-4d89-a1c3-f6e5d2b7a940
status: experimental
description: Detects HTTPS connections to known DoH resolver IPs, which may indicate C2 evasion via encrypted DNS
author: SOC Analyst Hub
date: 2026/07/23
tags:
  - attack.command_and_control
  - attack.t1071.004
  - attack.t1090
logsource:
  category: firewall
  product: generic
detection:
  selection:
    dst_ip:
      - '1.1.1.1'
      - '1.0.0.1'
      - '8.8.8.8'
      - '8.8.4.4'
      - '9.9.9.9'
      - '149.112.112.112'
      - '45.90.28.0/24'
      - '45.90.30.0/24'
      - '194.242.2.2'
    dst_port: 443
  filter_expected:
    # Exclude your org's explicitly approved DoH clients (e.g. managed browsers)
    src_workstation_role: 'managed_browser_fleet'
  condition: selection and not filter_expected
falsepositives:
  - Browsers with DoH enabled by default (Chrome, Firefox) — suppress via policy and filter
  - Legitimate managed DoH deployments
level: medium

Detection Approach 2: Process-Level DNS Behaviour Anomalies

When DoH is used by malware, an unusual process establishes the DoH HTTPS connection. Network telemetry correlated with process telemetry provides high-value detections.

Key anomalies to alert on:

• Non-browser processes making HTTPS connections to known DoH IP addresses
• Processes in %TEMP%, %APPDATA%, or unusual paths establishing connections to port 443 for any DoH resolver IP
• Newly spawned processes with network connections exclusively to DoH resolvers (no other outbound connections)

KQL for Microsoft Defender (DeviceNetworkEvents):

let DoHIPs = datatable(IP:string)[
    "1.1.1.1", "1.0.0.1", "8.8.8.8", "8.8.4.4",
    "9.9.9.9", "149.112.112.112", "194.242.2.2"
];
DeviceNetworkEvents
| where Timestamp > ago(24h)
| where RemotePort == 443
| where RemoteIP in (DoHIPs)
| where InitiatingProcessFolderPath !has "\\Program Files"
    and InitiatingProcessFolderPath !has "chrome.exe"
    and InitiatingProcessFolderPath !has "firefox.exe"
    and InitiatingProcessFolderPath !has "msedge.exe"
    and InitiatingProcessFolderPath !has "brave.exe"
| summarize 
    ConnectionCount = count(),
    ProcessPaths = make_set(InitiatingProcessFolderPath),
    RemoteIPs = make_set(RemoteIP)
    by DeviceName, InitiatingProcessFileName, InitiatingProcessAccountName
| where ConnectionCount >= 3
| sort by ConnectionCount desc

Detection Approach 3: DNS Request Volume Drops with Sustained HTTPS Egress

A behavioural pattern specific to DoH adoption in malware: when a host switches from normal DNS to DoH, its DNS query volume drops to near zero while HTTPS traffic to a small number of IPs continues. This is detectable through baselining.

For endpoints that previously generated typical DNS query volumes (50-500 queries/hour), a sudden drop to near zero — combined with sustained HTTPS connections to DoH resolver IPs — is a strong indicator. Most corporate devices do not legitimately disable DNS except when a browser policy has been explicitly configured.

KQL to detect zero-DNS hosts with DoH connections:

let DoHIPs = datatable(IP:string)[
    "1.1.1.1", "1.0.0.1", "8.8.8.8", "8.8.4.4",
    "9.9.9.9", "149.112.112.112"
];
let LookbackPeriod = 6h;
// Hosts with DoH connections
let DoHHosts = DeviceNetworkEvents
| where Timestamp > ago(LookbackPeriod)
| where RemoteIP in (DoHIPs) and RemotePort == 443
| distinct DeviceName;
// Hosts with very low DNS query volumes in same period
let LowDNSHosts = DeviceNetworkEvents
| where Timestamp > ago(LookbackPeriod)
| where RemotePort == 53
| summarize DNSQueryCount = count() by DeviceName
| where DNSQueryCount < 10;
// Find the intersection
DoHHosts
| join kind=inner LowDNSHosts on DeviceName
| project DeviceName, DNSQueryCount

Detection Approach 4: SNI and JA3 Fingerprinting

DoH traffic to commodity providers can sometimes be distinguished from normal HTTPS by its TLS characteristics. The DoH application sends short, high-frequency HTTPS requests in a distinct pattern — a POST to /dns-query with a small payload is different from typical browser page load traffic.

If you have SSL inspection or network flow visibility (not packet decryption), look for:

• High-frequency short HTTPS sessions (DoH is request/response per query, not a persistent connection)
• POST requests to /dns-query endpoints in HTTP/2 or HTTP/3 traffic (visible without decryption via SNI)
• Certificate subjects matching DoH provider infrastructure

Tuning and False Positive Management

The primary source of false positives is browsers. Chrome, Firefox, Edge, and Brave all support DoH and may enable it by default or on user request. Suppress these through:

1. Group Policy / MDM: Disable DoH in managed browsers via policy (DnsOverHttpsMode = off). This gives you a clean baseline.
2. Application allowlist: Filter known browser processes from process-level alerts.
3. Endpoint exceptions: Explicitly approved DoH deployments (e.g. privacy-conscious managed fleet configurations) should be enumerated and filtered.

After policy enforcement, any remaining DoH connections from non-browser processes are high-fidelity signals worth investigating.

What to Do When You Find It

DoH usage in a non-browser process is a significant indicator of compromise. The process using DoH is likely:

• Resolving C2 infrastructure without appearing in DNS logs
• Preparing to beacon to a C2 server whose IP is returned by the DoH query

Immediate response steps:

1. Isolate the host if the DoH connection is from an unsigned or unusual process
2. Pull the full process tree — what spawned the DoH-using process, and what did it spawn
3. Capture the process binary for analysis
4. Review other network connections from the same process and endpoint for C2 beaconing
5. Check for persistence mechanisms (scheduled tasks, registry run keys, services)

DoH is a detection bypass, not an intrusion vector. By the time an adversary is using DoH on an endpoint, they have already achieved execution. The DoH detection is a pivot point into a wider IR investigation.