|Tactic||Command and Control|
|Platform||Linux, Windows, macOS|
|Data Sources||SSL/TLS inspection, Packet capture|
|Contributors||Matt Kelly, @breakersall|
Domain fronting takes 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 The technique 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.
- APT29 has used the meek domain fronting plugin for Tor to hide the destination of C2 traffic.2
- meek uses Domain Fronting to disguise the destination of network traffic as another server that is hosted in the same Content Delivery Network (CDN) as the intended desitnation.
If it is possible to inspect HTTPS traffic, the captures can be analyzed for connections that appear to be Domain Fronting.
In order to use domain fronting, attackers will likely need to deploy additional tools to compromised systems.32 It may be possible to detect or prevent the installation of these tools with Host-based solutions.
If SSL inspection is in place or the traffic is not encrypted, the Host field of the HTTP header can be checked if it matches the HTTPS SNI or against a blacklist or whitelist of domain names.1