T1090.004: Domain Fronting
Adversaries may take advantage of routing schemes in Content Delivery Networks (CDNs) and other services which host multiple domains to obfuscate the intended destination of HTTPS traffic or traffic tunneled through HTTPS. [1] Domain fronting involves using different domain names in the SNI field of the TLS header and the Host field of the HTTP header. If both domains are served from the same CDN, then the CDN may route to the address specified in the HTTP header after unwrapping the TLS header. A variation of the the technique, "domainless" fronting, utilizes a SNI field that is left blank; this may allow the fronting to work even when the CDN attempts to validate that the SNI and HTTP Host fields match (if the blank SNI fields are ignored).
For example, if domain-x and domain-y are customers of the same CDN, it is possible to place domain-x in the TLS header and domain-y in the HTTP header. Traffic will appear to be going to domain-x, however the CDN may route it to domain-y.
Analyst context for executives and security teams
Domain fronting matters because command-and-control traffic can appear to be destined for a legitimate CDN-hosted domain while being routed to a different destination after TLS is established. For leaders, the risk is not just “encrypted traffic”; it is the possibility that normal-looking HTTPS to shared cloud/CDN infrastructure can hide adversary communications across Linux, macOS, Windows, and ESXi environments.
Executive priority
Prioritize this as a network visibility and incident-readiness issue. Organizations that rely only on domain reputation, firewall allowlists, or high-level HTTPS destination logging may miss the mismatch between the TLS SNI value and the HTTP Host header that defines this behavior. Security leaders should ask whether encrypted outbound traffic inspection, proxy logging, and exception governance provide enough evidence to validate suspicious CDN-routed command-and-control activity without disrupting business-critical web services.
Technical view
This is an ATT&CK command-and-control sub-technique under Proxy (T1090). The key validation point is whether defenders can compare the TLS SNI field with the HTTP Host header, including cases where SNI is blank for domainless fronting. The related detection strategy DET0196 specifically focuses on domain fronting behavior via mismatched TLS SNI and HTTP Host headers. Because ATT&CK does not provide official detection text for this object, SOC and detection engineering teams should validate visibility through network security monitoring, SSL/TLS inspection where approved, proxy records, and alert logic that accounts for shared CDN infrastructure and legitimate business traffic.
Likely telemetry
- TLS handshake metadata, especially SNI values
- HTTP request metadata, especially Host headers
- Proxy and secure web gateway logs
- SSL/TLS inspection logs where legally and operationally approved
- Network flow records showing outbound HTTPS destinations and volumes
Detection direction
- Validate whether monitoring can observe both TLS SNI and HTTP Host header values; without both, this technique may be difficult to confirm.
- Tune for mismatched or blank SNI values paired with HTTP Host headers, consistent with DET0196, while accounting for legitimate CDN and enterprise application behavior.
- Do not rely only on domain reputation or apparent TLS destination, because the visible front domain may not represent the routed backend destination.
- Correlate suspicious network behavior with endpoint context and known command-and-control tooling relationships, including Cobalt Strike, Mythic, meek, and SMOKEDHAM, without assuming their presence from network indicators alone.
- Establish false-positive review paths for business applications using CDNs or complex proxy/CDN routing so detection does not create excessive operational noise.
Mitigation priorities
- Assess where SSL/TLS inspection is appropriate, using the related M1020 mitigation, while considering privacy, legal, performance, and certificate-handling constraints.
- Prioritize inspection and richer logging for higher-risk egress paths, unmanaged outbound access, and systems where command-and-control risk would materially affect operations.
- Review proxy, firewall, and secure web gateway policies to ensure exceptions for CDN traffic are documented, risk accepted, and monitored.
- Maintain incident response playbooks for suspicious encrypted outbound traffic that include endpoint containment decisions, proxy log review, and network evidence preservation.
- Use this technique to test whether compliance evidence demonstrates actual encrypted traffic governance rather than only the existence of perimeter controls.
Analyst notes and limits
ATT&CK relationships show this technique is used by APT29 and by software including Cobalt Strike, meek, SMOKEDHAM, and Mythic. Those relationships provide useful threat-modeling context, but they should not be treated as proof of current activity in any environment. The revoked T1172 Domain Fronting object now maps to this sub-technique, so teams should align older references to T1090.004.
The official ATT&CK object does not include detection text or procedure-level detail in the supplied fields. Local confirmation depends on whether the organization collects TLS, HTTP, proxy, and inspection telemetry with enough fidelity to compare SNI and Host values. Detection and mitigation feasibility will vary based on CDN usage, encryption inspection policy, privacy requirements, and business-critical web traffic patterns.
Domain Fronting
Adversaries may take advantage of routing schemes in Content Delivery Networks (CDNs) and other services which host multiple domains to obfuscate the intended destination of HTTPS traffic or traffic tunneled through HTTPS. [1] Domain fronting involves using different domain names in the SNI field of the TLS header and the Host field of the HTTP header. If both domains are served from the same CDN, then the CDN may route to the address specified in the HTTP header after unwrapping the TLS header. A variation of the the technique, "domainless" fronting, utilizes a SNI field that is left blank; this may allow the fronting to work even when the CDN attempts to validate that the SNI and HTTP Host fields match (if the blank SNI fields are ignored).
For example, if domain-x and domain-y are customers of the same CDN, it is possible to place domain-x in the TLS header and domain-y in the HTTP header. Traffic will appear to be going to domain-x, however the CDN may route it to domain-y.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1172 | Domain Fronting | Domain Fronting revoked by this object. |
| Enterprise | T1090 | Proxy | This object subtechnique of Proxy. |
Groups, software, and campaigns
G0016: APT29
APT29 is threat group that has been attributed to Russia's Foreign Intelligence Service (SVR).[1][2] They have operated since at least 2008, often targeting government networks in Europe and NATO member countries, research institutes, and think tanks. APT29 reportedly compromised the Democratic National Committee starting in the summer of 2015.[3][4][5][6]
In April 2021, the US and UK governments attributed the SolarWinds Compromise to the SVR; public statements included citations to APT29, Cozy Bear, and The Dukes.[7][8] Industry reporting also referred to the actors involved in this campaign as UNC2452, NOBELIUM, StellarParticle, Dark Halo, and SolarStorm.[9][10][11][12][13][14]
S0154: Cobalt Strike
Cobalt Strike is a commercial, full-featured, remote access tool that bills itself as “adversary simulation software designed to execute targeted attacks and emulate the post-exploitation actions of advanced threat actors”. Cobalt Strike’s interactive post-exploit capabilities cover the full range of ATT&CK tactics, all executed within a single, integrated system.[1]
In addition to its own capabilities, Cobalt Strike leverages the capabilities of other well-known tools such as Metasploit and Mimikatz.[1]
S0175: meek
meek is an open-source Tor plugin that tunnels Tor traffic through HTTPS connections.
S0699: Mythic
S0649: SMOKEDHAM
All related ATT&CK context
Mitigation direction
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.2 | Current bundle | 59928c28b2cc… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
Fifield Blocking Resistent Communication through domain fronting 2015
David Fifield, Chang Lan, Rod Hynes, Percy Wegmann, and Vern Paxson. (2015). Blocking-resistant communication through domain fronting. Retrieved November 20, 2017.
Open source URL -
[2]
mitre-attack T1090.004Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.