Home/ATT&CK Technique/Domain Fronting
ATT&CK Technique

Domain Fronting

T1090.004 · command-and-control

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

LinuxmacOSWindowsESXi
◆

Actors Using This

3
russiaAPT29
united_statesEquation Group
russia_apt_sandwormIndustroyer / CrashOverride / Industroyer2
◈

Likely Attack Path

Techniques the same actors pair with this one distinctively - those showing up among actors who use this technique noticeably more than across all actors (lift > 1.15), grouped by kill-chain phase. The × is that lift multiplier; the shared-actor count is in the tooltip. A near-universal technique pairs with everything at baseline, so its list is short by design.
resource-development earlier
T1584 · Compromise Infrastructure ×1.27
initial-access earlier
T1195 · Supply Chain Compromise ×5.80T1566.001 · Spearphishing Attachment ×1.27
execution earlier
T1203 · Exploitation for Client Execution ×1.43
persistence earlier
T1133 · External Remote Services ×1.36
privilege-escalation earlier
T1548 · Abuse Elevation Control Mechanism ×2.11T1068 · Exploitation for Privilege Escalation ×1.49
lateral-movement earlier
T1021.006 · Windows Remote Management ×4.86T1021.002 · SMB/Windows Admin Shares ×1.95T1021 · Remote Services ×1.56
collection earlier
T1213 · Data from Information Repositories ×1.70
command-and-control same
T1090.003 · Multi-hop Proxy ×4.03T1090.001 · Internal Proxy ×1.71T1568 · Dynamic Resolution ×1.30
other same
T1562.001 · Disable or Modify Tools ×1.26
▣

Mitigations

1
MITRE ATT&CK mitigations - vendor-agnostic guidance for reducing exposure to this technique.
M1020SSL/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.

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.
◈

Detection Coverage

0/6 layers
Coverage across standard detection surfaces. Rows marked none have no rule of that type mapped. Some are real blind spots worth closing; others are simply not applicable to this technique (e.g. YARA matches malware files, not network behaviour).
Behavioral / log (Sigma) none
Analytics (MITRE CAR) none
Runtime / container (Falco) none
File / malware (YARA) none
Network (Suricata/Snort) none
Vuln scan (Nuclei) none
▣

Comply & Defend

NIST 800-53SC-08
D3FEND11 defensive techniques
Intelligence Graph · click any node to traverse
CVETechnique ActorTool Family
drag to reposition · click any node to traverse · button top-right enlarges
External lookups - second-class, for what we don’t hold ourselves
MITRE ATT&CKAtomic Red Teamcar (MITRE)
Vulnerabilities
CISA KEV catalog
CWE weaknesses
CAPEC attack patterns
Package vulnerabilities
Threat intelligence
Threat actors
Tools & malware
ATT&CK techniques
IOCs
Detection & defense
Sigma rules
YARA rules
Atomic Red Team tests
D3FEND countermeasures
Compliance
NIST 800-53
ISO 27001:2022
SOC 2 TSC
PCI-DSS v4.0
CIS Controls v8.1
About
All capabilities
Live statistics
Data sources
Privacy policy
Terms of service
threatengine.sh  ·  Open-source threat intelligence platform  ·  100+ authoritative sources  ·  Every fact traces to its origin