LiveActive security incident?Get immediate response
MITRE ATT&CK® Technique

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.

EnterpriseT1090.004Sub-techniqueObject v1.2Modified
Discuss defensive coverageBack to ATT&CK
Glexia's Take · Automated analysis

Security context for executives and security teams

Automation confidenceMedium

T1090.004: Domain Fronting describes 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. (Citation: Fifield Blocking Resistent Communication through domain fronting 2015) 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 spe...

Executive priority

T1090.004: Domain Fronting is an official MITRE ATT&CK technique. Glexia treats it as defensive behavior context for prioritizing monitoring, control validation, and response planning without using the object by itself as an attribution claim.

Technical view

Security teams should validate T1090.004: Domain Fronting by reviewing the official ATT&CK relationships, mapped tactics (command-and-control), supported platforms (Linux, macOS, Windows, ESXi), and available local telemetry before making detection or mitigation decisions.

Likely telemetry

  • Official ATT&CK relationships and object metadata
  • Network, endpoint, and security-tool telemetry

Detection direction

  • Validate whether T1090.004: Domain Fronting appears in your detection coverage and tabletop scenarios.
  • Use the object to align executive risk language with SOC, incident response, and detection engineering work.
  • Do not treat ATT&CK relationship context as attribution without corroborating evidence.

Mitigation priorities

  • Map the object to existing controls and identify missing telemetry or response ownership.
  • Prioritize mitigations that reduce exposure on the listed platforms and tactics.
  • Review adjacent ATT&CK relationships before changing policy, detections, or reporting language.
Additional notes and limits

Baseline Glexia take generated from the official MITRE ATT&CK STIX object, source hash, tactics, platforms, and detection fields. It is safe to replace with a richer model-generated take for the same source hash later.

This baseline take is source-grounded and schema-validated, but it does not include environment-specific telemetry, incident evidence, or threat-intelligence corroboration.

Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.

Official MITRE ATT&CK definition

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.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

ATT&CK relationship table

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.

2 rows
DomainIDNameRelationship / procedure
EnterpriseT1172Domain FrontingDomain Fronting revoked by this object.
EnterpriseT1090ProxyThis object subtechnique of Proxy.
Associated objects

Groups, software, and campaigns

GroupEnterprise

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]

MalwareEnterprise

S0649: SMOKEDHAM

SMOKEDHAM is a Powershell-based .NET backdoor that was first reported in May 2021; it has been used by at least one ransomware-as-a-service affiliate.[1][2]

Windows
MalwareEnterprise

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]

LinuxmacOSWindows
ToolEnterprise

S0175: meek

meek is an open-source Tor plugin that tunnels Tor traffic through HTTPS connections.

LinuxWindowsmacOS
ToolEnterprise

S0699: Mythic

Mythic is an open source, cross-platform post-exploitation/command and control platform. Mythic is designed to "plug-n-play" with various agents and communication channels.[1][2][3] Deployed Mythic C2 servers have been observed as part of potentially malicious infrastructure.[4]

WindowsLinuxmacOS
Relationship explorer

All related ATT&CK context

mitigates · MitigationM1020: SSL/TLS InspectionEnterpriseuses · GroupG0016: APT29Enterpriseuses · MalwareS0649: SMOKEDHAMEnterpriseuses · MalwareS0154: Cobalt StrikeEnterpriseuses · ToolS0175: meekEnterpriseuses · ToolS0699: MythicEnterpriserevoked by · TechniqueT1172: Domain FrontingEnterprisesubtechnique of · TechniqueT1090: ProxyEnterprisedetects · Detection StrategyDET0196: Domain Fronting Behavior via Mismatched TLS SNI and HTTP Host HeadersEnterprise
Mitigations

Mitigation direction

MitigationEnterprise

M1020: SSL/TLS Inspection

SSL/TLS inspection involves decrypting encrypted network traffic to examine its content for signs of malicious activity. This capability is crucial for detecting threats that use encryption to evade detection, such as phishing, malware, or data exfiltration. After inspection, the traffic is re-encrypted and forwarded to its destination. This mitigation can be implemented through the following measures:

Deploy SSL/TLS Inspection Appliances:

- Implement SSL/TLS inspection solutions to decrypt and inspect encrypted traffic. - Ensure appliances are placed at critical network choke points for maximum coverage.

Configure Decryption Policies:

- Define rules to decrypt traffic for specific applications, ports, or domains. - Avoid decrypting sensitive or privacy-related traffic, such as financial or healthcare websites, to comply with regulations.

Integrate Threat Intelligence:

- Use threat intelligence feeds to correlate inspected traffic with known indicators of compromise (IOCs).

Integrate with Security Tools:

- Combine SSL/TLS inspection with SIEM and NDR tools to analyze decrypted traffic and generate alerts for suspicious activity. - Example Tools: Splunk, Darktrace

Implement Certificate Management:

- Use trusted internal or third-party certificates for traffic re-encryption after inspection. - Regularly update certificate authorities (CAs) to ensure secure re-encryption.

Monitor and Tune:

- Continuously monitor SSL/TLS inspection logs for anomalies and fine-tune policies to reduce false positives.

Change history

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.

ATT&CK release
19.2
Object version
1.2
Created
Modified
Raw hash
59928c28b2cc9fa2...
Imported snapshots across ATT&CK releases(2)
ReleaseBundle importedObject versionModifiedStatusRaw hash
19.21.2Current bundle59928c28b2cc…
19.11.2Older bundle59928c28b2cc…
Raw source

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.

Open mirrored raw JSONOpen MITRE-hosted copy
Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [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.

  2. [2]
    mitre-attackT1090.004
    Open source URL
Source and licensing

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.

Official MITRE ATT&CK siteOfficial STIX data repositoryMITRE ATT&CK terms of use