Domain fronting is a technique in which a client conceals the true intended destination of an HTTPS request from censors and network security filters by “fronting” the request with a TLS connection to a different domain than that set in the request’s host header, both hosted on the same CDN service. In layman terms, an attacker hides an HTTPS request to a bad site inside a TLS connection to a good site.

It is usually performed by using a domain name in the SNI extension field of the TLS header that is different from that in the HTTPS Host header field. Whenever a request to a domain is performed in the browser or other TLS client, the first thing that happens is establishing the network connection where TLS negotiation starts based on the hostname used to initiate the connection. The HOST header in the application layer traffic is only parsed and looked after all the lower layers are established. 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.

There are two aspects involved here: Hostname for the connection must match the SSL certificate and Web server or CDN should know how to serve the content for the alternate hostname for the actual desired service.

Figure 1: Client and CDN Server interaction during Domain Fronting

Industry Analysis

Domain Fronting is leveraged by multiple services for legitimate usage and at Zscaler Cloud we have seen it primarily being leveraged in Technology, Manufacturing and Finance & Insurance sectors. Below is a snapshot of the weekly average request volume that was observed for various sectors for the past month.

Figure 2: Average weekly Request Volume for different Industry sectors

Uses and Abuse of Domain Fronting

This technique has been extensively used to bypass censorship filters. Some CDNs have disabled support for Domain Fronting as they were used for serving malicious content. Major service providers like Google, Amazon, Telegram, etc. have disabled this support fearing that they might have their entire infrastructure blocked inside a country wanting to block one or more applications.

Adversaries have been abusing domain fronting to take advantage of routing schemes in Content Delivery Networks (CDNs) hosting multiple domains to obfuscate the intended destination of HTTPS traffic. This is to set up a command and control (C2) channel for bypassing defensive techniques/tools that filter based on the reputation of the hostname used in initiating the connection request only instead of the one used in the HOST header of the subsequent requests in that session.

Abuse of CDNs

Azure, CloudFlare and Discord CDNs provide different kinds of services to host and deliver content. They are actively abused by the bad guys to serve malicious content. Coupled with Domain Fronting attacks, this creates a lethal attack vector to bypass the security defenses of a target enterprise network.

Here are some of the recent domains/urls observed serving malicious content hosted on these CDNs.

Figure 3: Malicious and Phishing Domains from Microsoft’s Azure CDN

Figure 4: URLs from Discord CDN serving malware

Figure 5: Malicious and Phishing Domains from CloudFlare CDN (trycloudflare)

Figure 6: Malicious and Phishing Domains from another CloudFlare CDN (workers.dev)

Case Study

As mentioned previously we have observed a few scenarios where CDNs are being abused. For example, consider this script hosted on Azure CDN at bingadssmartpage[.]azureedge[.]net/pages/coinbaselogin/config_-114304204234220470.js. If this domain has a known bad reputation, domain fronting can be leveraged to bypass simple SNI-based filters by creating a TLS connection to portal[.]msrc[.]microsoft[.]com as the front domain, requested in the SNI extension, and passing bingadssmartpage[.]azureedge[.]net as the value of the HOST header. In the below snapshots, this abuse can be observed clearly. The client first connects to portal[.]msrc[.]microsoft[.]com on port 443 and verifies the server certificate. After that the actual domain is used as part of the headers in the HTTP GET Request (HOST:bingadssmartpage[.]azureedge[.]net). And the response/script from the server by the client.

Figure 7: Curl Request demonstrating Domain Fronting

Figure 8: Javascript Response from the CDN after leveraging Domain Fronting

Conclusion

As domain fronting abuses legitimate or high-reputation domains to remain undetected by defenders, a legitimate site hosted on CDN can be leveraged by the bad actors to access other sites after the TLS connection is established. The owners of good reputation sites cannot prevent their hostnames being abused for this activity. Furthemore, the hosts of the reputable sites may not even be aware of the abuse, as the respective HTTPS traffic logs will be associated with the bad actor's account.

While some CDN vendors have taken steps to block domain fronting directly on their infrastructure, others are still being exploited. The best defense against domain fronting in an enterprise organization is first and foremost a cloud-based SWG (Secure Web Gateway) service with unlimited TLS interception capacity. Once this prerequisite is met, the web proxy service must have the ability to detect/alert and block HTTPS requests with mismatching host headers and SNIs..

Zscaler Internet Access Detection

Zscaler detects two variations of domain fronting and records the information in the weblogs that are made available in the Admin Portal Log Viewer and for live streaming to a SIEM through the Nanolog Streaming Service (NSS):

TLS SNI mismatch with the HTTPS host header
HTTP/S URL FQDN mismatch with the HTTP/S host header (for a less common domain fronting case previously seen in clear HTTP traffic)

Figure 9: Domain fronting detection in the Web Insights Log Viewer

Zscaler Internet Access Prevention

Zscaler has previously released a feature for its customers to enable entire "Block Domain Fronting" traffic. After analyzing the domain fronting detection and the extent of FPs (false positives), enterprises should consider turning on the prevention setting.

Figure 10: Feature to Block Domain Fronting in Zscaler Administration Settings.

Note on Domain Hiding

Domain hiding is a relatively newer technique (discussed in the two recent Defcon events) with similar censorship-circumvention/security filter-bypassing intent to that of the domain fronting, but with different mechanics.

Domain hiding abuses the encrypted SNI (ESNI) TLS 1.3 optional extension proposed by Cloudflare several years ago. While ESNI may be well-intended (add one more layer of privacy to consumer web browsing), it can easily be exploited by bad guys to evade network security defenses when improperly configured or implemented. In a domain hiding attack, an adversary simply inserts the ESNI extension in addition to or instead of the SNI extension in a TLS Client Hello to a Cloudflare CDN server enabled with ESNI. The attacker can easily evade detection and policy enforcements in an enterprise organization that relies primarily on basic domain/SNI-based web filters. In essence, since basic web filters’ center of gravity is the SNI, the presence of the ESNI or the lack of the SNI can throw them off balance.

While ESNI has obviously gained little to no adoption as evident from various data points, including 1) Cloudflare’s recognition of several design flaws and announcement of a replacement draft protocol extension (Encrypted Client Hello) and 2) from Zscaler’s unique traffic analysis:

Figure 11: TLS connections with ESNI extension in a large sample set is close to 0

It is still important to call out the best defense against this threat and it relies on the same strategy that is effective in counteracting your classroom bullies - ignoring. First, as with domain fronting, you must ensure that you are performing maximum SSL interception. Second, the ESNI extension is ignored or “stripped” at the Zscaler TLS interception point and not passed to the destination server.

Figure 12: ESNI stripping with Zscaler SSL interception enabled

If both the ESNI (bad domain) and SNI (benign domain) are present, the Zscaler SSL proxy will pass only the SNI (benign domain) to the CDN server that will, in turn, respond with the certificate and content of the benign domain, defeating the circumvention attempt. If only the ESNI is present in the original client hello, neither an ESNI nor a SNI extension will be passed on to the CDN server. The CDN server will again serve a default server certificate (benign), whose CN (Common Name) will then be used to evaluate your organization’s policies, again, defeating the attack attempt. Furthermore, as you are maximizing SSL inspection, all request/response content will be scanned by the complete Zscaler security stack, regardless of the domain reputation, providing defense-in-depth.

About ThreatLabz
ThreatLabz is the security research arm of Zscaler. This world-class team is responsible for hunting new threats and ensuring that the thousands of organizations using the global Zscaler platform are always protected. In addition to malware research and behavioral analysis, team members are involved in the research and development of new prototype modules for advanced threat protection on the Zscaler platform, and regularly conduct internal security audits to ensure that Zscaler products and infrastructure meet security compliance standards. ThreatLabz regularly publishes in-depth analyses of new and emerging threats on its portal, research.zscaler.com.