How do you detect domain fronting?

The definitive signal for domain fronting is a mismatch between the TLS SNI in the ClientHello and the HTTP Host header inside the encrypted request, which requires a TLS-inspecting proxy to observe. Without decryption, fall back to behavioural and reputational signals: beacon timing to CDN edges from hosts that do not otherwise use them, sustained transfers to a CDN with no matching application, low-reputation backend Host headers behind shared CDN IPs, and the growing ECH/ESNI blind spot. Always expect some benign CDN mismatches and enrich with reputation and timing.

Detecting Domain Fronting and CDN-Hidden C2

Domain fronting routes C2 through a high-reputation CDN by putting an innocuous domain in the TLS SNI while the encrypted HTTP Host header names the real backend. Many providers have curbed it, but domainless fronting and CDN abuse persist. Detection hinges on seeing the SNI/Host mismatch — which usually means TLS inspection.

Signals at a Glance

Signal	Where	ATT&CK
TLS SNI does not match decrypted HTTP Host header	TLS-inspecting proxy	T1090.004
High traffic to a CDN edge with no corresponding app usage	Flow/proxy	T1102
Beacon timing to a CDN front domain	Proxy	T1571
Rare/odd Host headers behind a shared CDN IP	TLS-inspecting proxy	T1090.004

The SNI / Host Mismatch

The defining artifact is the mismatch between the SNI presented in the TLS ClientHello and the Host header inside the encrypted request. With a TLS-inspecting proxy you can compare them directly:

// KQL on TLS-inspection logs: SNI != Host (classic fronting)
ProxyTlsLogs
| where isnotempty(TlsSni) and isnotempty(HttpHost)
| where tolower(TlsSni) != tolower(HttpHost)
| where not(HttpHost endswith TlsSni or TlsSni endswith HttpHost)
| summarize reqs=count(), bytes=sum(SentBytes) by SrcIp, TlsSni, HttpHost
| order by reqs desc
// Expect some benign mismatches (CDN, ESNI/ECH); enrich with reputation + timing.

When You Cannot Decrypt

Without TLS inspection, domain fronting is hard to see directly. Fall back to behavioural and reputational signals:

Flag beacon-timing patterns to CDN edges (Cloudflare, Fastly, Azure, Google) from hosts that otherwise do not use those services.
Correlate large or sustained transfers to a CDN with no matching application in asset inventory.
Watch for Encrypted Client Hello (ECH) adoption on egress — it hides SNI and is a growing blind spot; where policy allows, require inspection or block ECH on corporate egress.
Hunt newly-registered or low-reputation backend domains that appear as Host headers behind shared CDN IPs.

Vetted sources

The reliable detection needs TLS inspection to compare SNI against the Host header. Where that is not possible, use proxy reputation feeds, beacon-timing analytics and CDN-usage baselining. Track ECH/ESNI rollout as an emerging blind spot in your egress monitoring.

Build Detections That Fire

Mjolnir Security helps blue teams turn threat intelligence into high-fidelity detections across endpoint, network, identity and cloud telemetry.

Detection EngineeringManaged Detection & ResponseThreat HuntingIncident ResponsePurple Teaming

Detection Engineering We build and tune detections mapped to ATT&CK from your own telemetry.
Threat Hunting as a Service Hypothesis-driven hunts for the behaviours on this page.
24/7 Incident Response Containment when a detection fires. Call +1 833 403 5875.

Written by: Mjolnir Threat Research (MTAC)  |  Published: October 12, 2026  |  Last reviewed: October 12, 2026

Signals at a Glance

The SNI / Host Mismatch

When You Cannot Decrypt

Build Detections That Fire

C2 Beaconing Detection

Detection Hub

C2 over Legitimate Services