Summary

Domain fronting is a network technique that can be used for both censorship circumvention and malicious purposes by hiding the true destination of web traffic behind a legitimate domain, posing risks and requiring new security measures.

Abstract

Domain fronting is a sophisticated method that exploits the use of different domain names at various layers of communication within HTTPS to conceal the actual endpoint of internet traffic. While it can be employed for benign purposes, such as bypassing censorship, it is also a tool for threat actors to obscure their command and control (C2) communications. This technique leverages the same content delivery network (CDN) for both a legitimate and a covert domain, allowing traffic to appear as if it's destined for the legitimate domain while actually being routed to the hidden one. The awareness of domain fronting has led to its use by organizations like Signal for privacy purposes and by state-sponsored threat groups like APT29. As a response, major CDN providers like Microsoft Azure, AWS, and Google have implemented measures to prevent this technique from being abused, and security firms have developed tools to detect and block domain fronting attempts.

Opinions

The author suggests that proxying, while traditionally seen as a method for securing traffic, can also be used maliciously to hide or reroute traffic.
There is an acknowledgment that domain fronting can be a double-edged sword, with legitimate uses for privacy and censorship avoidance, as well as illegitimate uses for concealing malicious activities.
The technique's reliance on CDNs that host both the legitimate and covert domains is seen as a key enabler for domain fronting.
The author implies that the responsibility for mitigating domain fronting lies with CDN providers and organizations, who must implement advanced security measures such as TLS decryption and inspection.
There is an optimistic view that despite the challenges posed by domain fronting, the security community is actively developing and deploying countermeasures to protect against its misuse.

What’s Domain Fronting and how it’s a risk to your environment

Proxying can be good, think of IT admins securing their traffic through vendors’ SASE services, or regular Secure Web Gateways for full traffic inspection. So, Proxy is Good!

We also know that proxy can be used to hide traffic, users could leverage web proxies to access censored content behind a protected (or monitored) network. Ok, so, actually, Proxy is bad?

These are both plain old examples of proxying in networks, but, what if you cannot identify proxied traffic? What if the proxying is hidden behind a legitimate web domain (service)?

This is Domain Fronting. Let’s explore this.

./what

One of the first official reports of this technique is from early 2015, from this paper. It describes the technique from a censorship circumvention perspective:

Domain fronting works at the application layer, using HTTPS, to communicate with a forbidden host while appearing to communicate with some other host, permitted by the censor. The key idea is the use of different domain names at different layers of communication. One domain appears on the “outside” of an HTTPS request — in the DNS request and TLS Server Name Indication — while another domain appears on the “inside” — in the HTTP Host header, invisible to the censor under HTTPS encryption.

Some services used the technique as such, Signal leveraged the technique and chose CDN providers that allowed its use, as reported here.

Others have defined the technique from an attacking perspective — with clearer naming of the layers being exploited, one example would be this description, from Microsoft:

Domain fronting is a networking technique that enables a backend domain to utilize the security credentials of a fronting domain. For example, if you have two domains under the same content delivery network (CDN), domain #1 may have certain restrictions placed on it (regional access limitations, etc.) that domain #2 does not. By taking the valid domain #2 and placing it into the SNI header, and then using domain #1 in the HTTP header, it’s possible to circumvent those restrictions.

This technique can be found in MITRE ATT&CK, T1090:

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.

Notice how these last definitions state clearly that the technique relies on exploitation of domains behind the same CDN provider.

This is a requirement for Domain fronting to occur. And this is where protection can be enforced.

./uses

When you access the paper from 2015, you can see how it mentions “censorship avoidance” as a goal of this technique. And indeed, this is one of the use cases of it.

However, threat actors have exploited it as a way to hide their communication with C2.

./maliciousUse

This technique has been seen in the wild many times, a report from Mandiant from 2017 details how it was used by APT29 (cozy bear) even before the technique became known.

This is a snapshot of the analysis by Mandiant on their use of the technique:

The malicious use lies behind an artifact on the victim’s machine that communicates with the covert domain “proxy”, as described by the paper (though it mentions “client” in the scenario of censorship circumvention):

Circumvention is achieved when the client reaches the proxy, because the proxy grants access to any other destination. The client and proxy cooperate with each other.

In more details, this is what would happen according to the original paper from 2015:

Of course, among the pre-requisites for this technique to be put in effect, is for the infrastructure to allow it…

./curbYourEnthusiasm

Well, reality is, proxying is a glass half full/empty kind of situation. :)

Out of this new technique, there’s a need to come up with newer protection mechanisms, in the layer of services beyond exploited, that is, the CDN.

According to MITRE these are mitigation options:

Inspect HTTPS traffic leaving your organization’s perimeter. This is also known as TLS decryption or inspection.
If TLS inspection is in place, the HTTP Host field of the HTTP header can be checked and matched to the Server Name Indication (SNI) or against a deny/allow list of domain names. The caveat, in this case, is that we are using legitimate Microsoft Azure domain names.

From a CDN perspective, here’s what has been done so far:

Microsoft has committed to hinder attempts to use this technique within Azure.

The feature went GA on April 29th 2022 as announced here.

Plus, some SWG can help:

Zscaler can detect and block these attempts from protected endpoints.

./eof

This is domain fronting and how it can be used maliciously — and even as a censorship circumvention method for that matter.

Learn more about my Cloud and Security Projects: https://linktr.ee/acamillo

Consider subscribing to Medium (here) to access more content that will empower you!

Thank you for reading and leave your thoughts/comments!

./references

Scattered throughout the doc.

Securing our approach to domain fronting within Azure — Microsoft Security Blog