Domain Fronting using StackPath CDN
A guide to setting up domain fronting, and exploring additional quirks that StackPath can provide.
Last updated
Was this helpful?
A guide to setting up domain fronting, and exploring additional quirks that StackPath can provide.
Last updated
Was this helpful?
is a Content Delivery Network similar to what CloudFront by Amazon Web Services, and Azure CDN, and Google's CDN provide. It allows organisations to set up a way to better optimise traffic being requested from different countries across the globe. Where possible, the CDN will attempt to serve cached resources to speed up the transaction.
Domain Fronting is a technique that's been explored over the past couple of years, more so by offensive security experts, and in some cases even used by Advanced Persistent Threat actors. This technique is generally abused through flaws in the design of the Content Delivery Network to provide a method of redirecting malicious traffic within a HTTPS encapsulated tunnel through a legitimate website to a final malicious endpoint.
To learn more about Domain Fronting, check out some of my other posts such as , , and .
StackPath CDN offers a generous 1 month free trial. However, as StackPath CDN's market share is extremely low compared to the likes of CloudFront, the number of domains that can be used to masquerade traffic is therefore reduced. That said, there are still interesting domains, and quirks that can be beneficial to the operator when utilising StackPath as a choice for Domain Fronting.
When setting up StackPath CDN, you will be asked to enter a new delivery domain. This will be the final endpoint that you would like to have data served through the CDN. For example, mymalicious.domain.com.
The rest of the options are pretty self explanatory but after the CDN host is provisioned, visit the settings section of the instance to allow for further fine tuning. See below.
You will then be led to the following page after clicking on the settings tab.
The settings tab is fantastic but we want to scroll down to the cache handling options and apply the settings as shown below to remove caching.
Caching should be removed because it is bad for command and control as we may find it difficult to control the response at a dynamic pace.
To test that the CDN is working, visit the StackPath URL defined by the service such as <randomuid>.stackpathcdn.com. If the page loads, we know the CDN is working.
We can try to perform a Domain Fronting attempt by issuing a HTTPS request to a legitimate StackPath domain, but with a host header of <randomuid>.stackpathcdn.com. See below.
If the response shows the content of your CDN as opposed to the website you are sending the request to, then we know that Domain Fronting works through that domain. I have published a StackPath CDN list of frontable Domains on my GitHub at https://www.github.com/vysecurity/DomainFrontingLists as usual.
An arbitrary host header is a lot more difficult to determine as malicious compared a threat hunter who may be performing TLS inspection on web requests and searches for *.stackpathcdn.com in the Host header.
In StackPath we can perform the same type of technique by navigating to the bottom of the settings page and adding it as an additional domain alias as shown below.
Above we have used the delivery domain of smellyfish.fish - but what does this mean?
This essentially means that we can now issue a request and perform Domain Fronting without a Host header of *.stackpathcdn.com, and instead have smellyfish.fish.
We can test that the Domain Front works by utilising the following command:
If the request responds with the content of your C2 endpoint, then we know that the technique is a success.
Back in the post located at , I mentioned that you could utilise arbitrary Host headers that were not even valid domain names by setting it as a CNAME record. Amazon has since fixed this issue.
