Customers frequently ask me about malware that uses domain fronting and how to detect it. Simply put, domain fronting is when malware or an application pretends to be going to one domain but instead is going somewhere completely different. (Mitre ATT&CK - T1172)
The goal of domain fronting is to have the analysts believe that the connection is being a made to a safe site while the true destination is in fact somewhere completely different.
Let’s look at a piece of malware that uses this method. This is a PowerShell Empire sample:
In the configuration information of this file, we see a URL that will be requested, which is also Base64 encoded. The URL decodes to https://ajax.microsoft.com:443 as seen below:
So, this script will initiate a connection to ajax.microsoft.com:443, and appear to request /login/process.php. However, because the Host: header is pointing to content-tracker.*******.net, the request will actually go to https://content-tracker.*********.net/login/process.php instead.
You may be thinking that all you have to do in order to detect examples of domain fronting is to look for discrepancies between the requested URL and the domain/IP in the Host: header. However, there are some complexities to deal with. Most of the time the initial connection is SSL encrypted, so you are limited to artifacts related to SSL traffic, unless you have SSL inspection technology in place. Another consideration is if whether a proxy is involved in this connection or not.
In order to describe what the analyst would see if SSL inspection technology is in place, let us use a Man-In-The-Middle proxy to inspect this traffic in its clear-text form. SSL Inspection technologies are extremely useful for this and other scenarios where malware communicates over SSL, and it is something that we highly recommend that you deploy in your organization.
Let us introduce two terms here to clarify the elements of this technique as we describe how to hunt for it:
Fronting Domain (ajax.microsoft.com)
Fronted Domain (content-tracker.*********.net)
Here we see the Fronting Domain request, which is also the only thing you would see if you were only relying on proxy logs. The Domain Fronting domain (ajax.microsoft.com in this case) is also what the proxy would use for URL Filtering checks. The proxy logs would not actually see the “Fronted Domain”. For all intents and purposes this would be a legitimate request to a Microsoft site.
However, the response is anything but what you would expect from the site. Namely, instead of some HTTP content the site returns an encoded blob of data that decodes into more PowerShell code.
How do I know, it was more PowerShell code, that was easy, I simply replaced the follow-up execution with the output to a file as seen below:
Then opening the resulting stage2.ps1 file, you can see to contains additional PowerShell code that is highly obfuscated.
Let us go back one step and discuss another key aspect regarding Domain Fronting. Namely, the SSL certificates used during this communication. The SSL certificates are legitimate Microsoft signed certificates, since the initial connection is indeed to ajax.microsoft.com. This certicate is tied to many Microsoft domains and Microsoft CDN Domains.
We could try to de-obfuscate the stage2.ps1 PowerShell script but there really is no need, since by looking at the subsequent request of the malware on the proxy we can get an idea of what it does. Its initial check-in posting back victim information again in an encrypted binary blob of data.
Additionally, this particular strain of malware also seems to do a legitimate call to the ajax.microsoft.com site as shown below. While not at all relevant for domain fronting, it is important for the analysts to be aware as to why they might see both legitimate and malicious requests mixed together. The analyst will notice that the "Host:" header will match the requested domain in legitimate requests.
The response from the legitimate site is also completely different and starts a redirect chain that we will show below:
And finally, the legitimate page for Microsoft Ajax Content Delivery Network.
Now that we have described in detail the sequence of requests, let us see how this all looks from the Netwitness Packet perspective. There are two cases, one where there is no proxy and one where there is one.
Traffic Analysis – SSL Only
Let’s start with the traffic without a proxy. I have isolated only the relevant events in a separate collection to facilitate the analysis. I will also point out how some of these indicators can be spotted in larger traffic patterns.
In the example below, the indicators are separated in two sessions: a DNS request and an SSL connection. You can see that the DNS request is for one domain name, while the SSL session displays what is referred to as the SNI, which does not match the DNS request.
For the legitimate traffic, the DNS request and the SSL SNI value both match. These are both extracted into the alias.host key.
So, how can you detect this type of behavior? It is not easy, especially on high volume environments. However, a starting point is to look for are alias.host values that only show one of the service types (DNS or SSL), but not both. Legitimate traffic will likely have both as shown below:
You should not expect these values to be balanced or equal as DNS is often cached, but you should expect to see both types of service. Some environments at times do not capture DNS due to volume, but to be successful it is critical to have both.
For the malicious traffic each domain will only have one type of traffic (i.e. DNS or SSL). This detection criteria is not an exact “science” as you could easily have only DNS for all sorts of other types of traffic that are not domain fronting. The Fronting Domain will have the DNS traffic, while the Fronted Domain will have the SSL sessions.
Since the traffic is split between sessions on the packet side, we would need to use an ESA rule to detect this type of activity.
Traffic Analysis – Proxied Requests
For explicit proxied traffic things are slightly easier, as all the traffic is contained in a single session. We see the "raw" payload of one such session below. It can seem confusing at first, but Netwitness identifies this traffic as HTTP. This is correct since this part of the traffic is indeed HTTP.
Since we have all the pieces in one session here, the detection is easier. But how can we do it for high data volumes. In this case the HTTP session will have two different hostnames. While this is at times common for pure HTTP traffic due to socket re-use, it is uncommon for HTTPS/SSL traffic as the standards advise against it for privacy/security purposes, among other reasons.
This shows a possible solution to detect this type of traffic with a simple App rule that could identify traffic HTTP with 2 unique alias.host values and the presence of a certificate.
In summary, domain fronting is a technique used by attackers/red teams with the intent of either circumventing network policies (URL filtering), or hiding in plain sight, as the analysts are more likely to see/notice the legitimate domains than the malicious ones and assume this activity as safe/legitimate. However, this type of activity still has a certain footprint that we have described. Hopefully the information provided here will help you all improve your defenses against this technique.
Thank you,
Rui
3 Comments
