9 minhigh
Domain Fronting Attack: CDN Abuse & C2 Evasion Explained
Domain fronting is a network evasion technique where an attacker conceals the true destination of HTTPS traffic by using a trusted domain in the TLS SNI field while specifying a different malicious destination in the HTTP Host header, both served by the same CDN. The article details real-world abuse of Azure, Cloudflare, and Discord CDNs for C2 traffic and phishing, and describes domain hiding via ESNI as a related emerging threat. Effective defense requires full TLS inspection with SNI-Host header mismatch detection and ESNI stripping at the proxy layer.
Sens:▲ 24hConf:high
Showing defanged values
- domainbingadssmartpage[.]azureedge[.]netMalicious domain hosted on Azure CDN serving a credential phishing script disguised as a Coinbase login page; used as the hidden Host header destination in a domain fronting attack.
Detection / Hunteropenrouter
What Happened
Attackers are hiding malicious internet traffic inside connections to trusted websites by exploiting a technique called domain fronting. They connect to a legitimate, well-known website address (like Microsoft's security portal) to pass through security filters, but then secretly redirect the traffic to a malicious site hosted on the same content delivery network. This means security tools that only check the initial connection address see nothing wrong, while the actual malicious content slips through unnoticed. Organizations in technology, manufacturing, and finance have been observed using or being targeted by this technique. The best defense is to use a security gateway that decrypts and inspects all encrypted web traffic so it can compare the visible connection address with the hidden destination address and block mismatches. Organizations should evaluate whether their web filtering tools perform this level of inspection.
Key Takeaways
- Domain fronting abuses CDN routing by mismatching the TLS SNI field with the HTTP Host header, allowing C2 traffic to bypass SNI-based network filters.
- Azure, Cloudflare, and Discord CDNs are actively abused to host malicious content and serve it through trusted CDN infrastructure.
- A real-world case study shows bingadssmartpage[.]azureedge[.]net being fronted by portal[.]msrc[.]microsoft[.]com to evade reputation-based filtering.
- Domain hiding via ESNI (Encrypted SNI) is a related emerging technique that blinds SNI-dependent web filters by encrypting or omitting the SNI field entirely.
- Full TLS/SSL inspection by a Secure Web Gateway is the primary defense, enabling detection of SNI-Host header mismatches and stripping of ESNI extensions.
Affected Systems
- Enterprise networks relying on SNI-based or domain-reputation-based web filtering
- Organizations using CDN services (Azure CDN, Cloudflare, Discord CDN) for legitimate content delivery
- Technology, Manufacturing, and Finance & Insurance sectors observed leveraging domain fronting traffic
Vulnerabilities (CVEs)
None identified.
Attack Chain
- Infrastructure Setup: Attacker hosts malicious content (e.g., phishing pages, C2 scripts) on a CDN that also serves legitimate high-reputation domains (Azure, Cloudflare, Discord).
- TLS Connection: Attacker initiates an HTTPS connection to a trusted front domain (e.g., portal.msrc.microsoft.com) using that domain in the TLS SNI field to pass reputation-based filters.
- Host Header Injection: After TLS is established, the HTTP request specifies the malicious domain (e.g., bingadssmartpage.azureedge.net) in the Host header, causing the CDN to route to attacker-controlled content.
- C2/Phishing Delivery: Malicious content (JavaScript, phishing pages) is served back to the client through the trusted TLS tunnel, evading SNI-only inspection.
- Evasion via ESNI (Domain Hiding): Alternatively, attacker uses ESNI extension to encrypt or omit the SNI entirely, blinding basic web filters that rely on SNI inspection.
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
- Platforms: Zscaler ZIA Web Insights Log Viewer, Zscaler Nanolog Streaming Service (NSS)
The article describes Zscaler ZIA's built-in domain fronting detection capabilities (SNI-Host header mismatch and URL FQDN-Host header mismatch) and a 'Block Domain Fronting' enforcement setting, but does not provide portable detection rules for other platforms.
Detection Engineering Assessment
copy:
| Dimension | Rating | Rationale |
|---|---|---|
| EDR Visibility | Low | Domain fronting is a network-level evasion technique; EDR agents typically do not inspect TLS SNI vs. HTTP Host header mismatches unless they perform local SSL interception, which is uncommon. |
| Network Visibility | Medium | Network security tools with full TLS interception can detect SNI-Host header mismatches, but tools relying solely on SNI inspection (most legacy firewalls and SWGs without SSL decryption) are blind to the hidden destination. ESNI further reduces visibility for non-intercepting proxies. |
| Detection Difficulty | Hard | Detecting domain fronting requires full TLS decryption to compare the SNI with the HTTP Host header, which many organizations do not perform due to performance, privacy, or compliance constraints. ESNI-based domain hiding adds further complexity by removing the SNI signal entirely. |
Required Log Sources
- TLS connection logs with SNI field
- HTTP proxy logs with Host header and full URL
- Web gateway logs with SSL inspection enabled
- CDN access logs (if available from CDN provider)
Hunting Hypotheses
copy:
| Hypothesis | Telemetry | ATT&CK Stage | FP Risk |
|---|---|---|---|
| Consider hunting for TLS sessions where the SNI field and the decrypted HTTP Host header reference different domains hosted on the same CDN, which would indicate potential domain fronting activity. | TLS inspection proxy logs containing both SNI and decrypted HTTP Host header values | Command and Control (T1090.004) | Medium — some legitimate applications and services use domain fronting for censorship circumvention or multi-CDN routing; validate against known business-approved services before alerting. |
| Consider hunting for TLS Client Hello messages that include an ESNI or ECH extension, especially when the SNI field is absent or points to a benign domain, as this may indicate domain hiding attempts. | Network packet captures or TLS inspection logs that record TLS extension types in Client Hello messages | Command and Control / Defense Evasion (T1573.002) | Low — ESNI/ECH adoption is near zero in normal traffic; presence is notable but should be validated against legitimate privacy-focused services. |
| Consider hunting for outbound HTTPS connections to known CDN IP ranges where the SNI resolves to a high-reputation domain but the connection volume or behavior pattern is inconsistent with normal use of that domain. | Firewall or proxy logs with SNI, destination IP, byte volume, and connection frequency | Command and Control (T1071.001) | Medium — CDNs serve many domains from shared IP ranges; anomalous patterns require correlation with other signals to confirm. |
| Consider hunting for processes making HTTPS requests to CDN domains (e.g., azureedge.net, workers.dev, trycloudflare.com, discord.com CDN paths) that are not associated with known legitimate applications on the endpoint. | EDR process network connection logs with destination domain and process name correlation | Execution / Command and Control (T1071.001) | High — many legitimate applications use these CDN domains; focus on unusual process-to-domain pairings or non-browser processes making such connections. |
Control Gaps
- Firewalls and web filters that perform only SNI-based filtering without TLS decryption cannot detect or block domain fronting.
- Legacy SWGs without sufficient SSL/TLS inspection capacity will miss SNI-Host header mismatches.
- Network security tools that do not parse or strip ESNI/ECH extensions are vulnerable to domain hiding evasion.
- CDN-based reputation filtering is insufficient because the front domain is legitimate and high-reputation.
Key Behavioral Indicators
- TLS SNI field value differs from HTTP Host header value within the same HTTPS session
- TLS Client Hello containing ESNI or ECH extension alongside or instead of standard SNI
- Outbound HTTPS connections to CDN IP ranges with SNI pointing to high-reputation domains but unusual traffic patterns or volumes
- HTTP Host header referencing domains on trycloudflare.com, workers.dev, azureedge.net, or discord CDN paths not associated with known business applications
- Non-browser processes initiating HTTPS connections to CDN-hosted domains
False Positive Assessment
Medium — Domain fronting has legitimate uses for censorship circumvention and multi-CDN routing; some organizations may have business-approved services that use this technique. ESNI/ECH extensions, while rare, may appear in legitimate privacy-focused traffic. SNI-Host header mismatches can also occur with legitimate redirect and CDN routing configurations.
Recommendations
Immediate Mitigation
defender takeaway
- Verify against your organization's incident response runbook and team escalation paths before acting. Consider evaluating whether your Secure Web Gateway or next-generation firewall performs full TLS inspection and can detect SNI-Host header mismatches.
- If your SWG supports domain fronting detection or blocking, consider enabling it after assessing false positive impact on legitimate traffic.
- Consider adding known malicious CDN-hosted domains (e.g., bingadssmartpage.azureedge.net) to block lists, while recognizing this is a reactive measure that does not address the underlying evasion technique.
Infrastructure Hardening
- Consider deploying or upgrading to a cloud-based SWG with full SSL/TLS decryption capacity if your current web filtering relies solely on SNI inspection.
- If supported by your proxy infrastructure, evaluate enabling ESNI/ECH extension stripping at the TLS interception point to neutralize domain hiding attempts.
- Consider implementing egress filtering policies that restrict direct outbound HTTPS to CDN IP ranges for non-browser or unapproved applications.
- Evaluate whether your CDN provider offers domain fronting protection or allows disabling the feature for your hosted domains.
User Protection
- Consider enabling endpoint-based web filtering that can inspect decrypted content for phishing and malware, complementing network-level controls.
- If applicable, evaluate deploying browser extensions or endpoint agents that warn users when navigating to dynamically generated CDN URLs (e.g., trycloudflare.com, workers.dev).
Security Awareness
- Consider incorporating domain fronting and CDN abuse awareness into existing security training programs, emphasizing that trusted domains in browser address bars do not guarantee the content is legitimate.
- Consider reminding users to verify the full URL path when accessing financial or sensitive services, as phishing pages may be served from legitimate CDN domains with deceptive paths.
MITRE ATT&CK Mapping
MITRE ATT&CK Mapping4 techniques
Tactic
Command and Control
Tactic
Exfiltration
Additional IOCs
- Command Lines:
- Purpose: Demonstrating domain fronting by connecting to a legitimate front domain via TLS while setting the HTTP Host header to the malicious destination domain | Tools:
curl| Stage: C2 Evasion / Domain Fronting Demonstration |curl -H "Host: <hidden-domain>" https://<front-domain>
- Purpose: Demonstrating domain fronting by connecting to a legitimate front domain via TLS while setting the HTTP Host header to the malicious destination domain | Tools:
Stay currentSubscribe via RSS
