Empire Domain Fronting With Microsoft Azure

Feb 27, 2019 · 6 minute read

Introduction

Domain Fronting used to be all the rage a while back. It’s still actively being used by Red Teams and Malicious operators. My interest was recently renewed by this detailed blog post by digininja and this one by @rvrsh3ll. This post doesn’t present any new research as there have been plenty of resources detailing how to setup domain fronting for Empire and Cobaltstrike. I wanted to post one for using Empire with Microsoft Azure since I didn’t see one detailing the setup. We’ll start off with CDNs which are crucial to understanding Domain Fronting.

Content Delivery Networks (CDNs)

A CDN simply is a global network of servers that deliver content to visitors of a website based on where that visitor is located. CDNs offer several advantages to businesses worldwide such as Protection against DDoS attacks, protection against increased traffic, helping with SEO, Reliability and its cheap.

Intro to Domain Fronting

At a high level, domain fronting is an undocumented feature of CDNs. It can be used to transmit command and control traffic to the intended origin that’s being blocked by egress filters. The domain name of the attacker controlled endpoint is only communicated after the establishment of an encrypted HTTPS connection. Attackers can simply swap in their host header for the CDN to route what appears to be trusted website traffic to their command and control server instead.

Technical Details

This technique is made possible when a large trusted service provider uses a shared SNI certificate containing both a common and target HTTPS domains. When the traffic is received by the Edge Server (ex: located at azureedge.net), the packet is forwarded to the Origin Server (ex: darthmalicious.azureedge.net) specified in the packet’s Host header. The Origin Server will then directly forward traffic to a specified domain, which we’ll point to our Empire Instance. We can see this cool example from the Red Team wiki.

redteam-wiki-example

Real World Use Cases

Domain fronting is frequently used in heavily censored nations by political activists to circumvent censorship and ant-free speech controls. This is mostly done over Social Media Chat apps such as Signal and Whatsapp. It’s also used by Proxy Networks e.g. Tor. In Infosec, this technique has been used by both malicious and legitimate attackers. AWS CloudFront is normally the CDN of choice for domain fronting but we’ll use Microsoft Azure. Using domain fronting should always be carefully considered since it may violate terms and conditions of the service providers.

Setting up Azure

Setting up on Azure CDN is fairly straight forward and relatively painless. One just needs a little patience. The Azure documentation on CDNs is amazing and this blog post from @ch1gg1ns helped out a ton. We first Log in to the Azure portal. We enable Azure Content Delivery Network (CDN) by creating a new CDN profile and CDN endpoint. In the upper left, select Create a resource.

We then select Web and then CDN.

The CDN profile pane, we can then create a CDN resource and create an endpoint for that resource.

After we’ve successfully created it we will get this notification.

This is where the patience part comes in. After creating the CDN and the endpoint, we have to wait around 90 minutes for the endpoint to propagate throughout the CDN. We update the endpoint’s caching settings so that our CDN won’t cache our traffic like the usual CDN behavior. This enables us to use this as a communications channel. Change your caching behavior and query string caching behavior to bypass and we’re done.

Before moving on we need to explain a few things.

CDN Endpoint Name is going to be in our Empire Host header Communication profile in the HTTP request. This will point to our C2 infrastructure where Empire is hosted. You can make it sound more legitimate.

Origin Hostname is your IP address or DNS name for you C2 infrastructure. It simply connects the CDN to your resources and gets the domain working.

Finding domain frontable Azure domains

While our CDN is propagating, we search for a high-profile domain name to hide behind that will also work for our CDN. There’s a great resource in finding frontable azure domains. However, I went a slightly different route and used FindFrontableDomains by @rvrsh3ll. We’ll use watcocdn1.azureedge.net.

Testing the CDN

To properly test if our CDN communication is properly setup, we’ll use the Empire Instance we already have running. The Empire instance should respond the same way when accessed directly and via the CDN we just created. When accessing via the CDN, we’ll want to set the Host Header to the CDN endpoint we created before.

root@kali:~# curl -k https://[redacted].com

<--Snipped Output -->
<body>
<div id="container">
<a href="http://go.microsoft.com/fwlink/?linkid=66138&amp;clcid=0x409"><img src="welcome.png" alt="IIS7" width="571" height="411" /></a>
</div>
<--Snipped Output -->


root@kali:~# curl -k --header "Host: darthmalicious.azureedge.net" "https://watcocdn1.azureedge.net/"

<--Snipped Output -->
<body>
<div id="container">
<a href="http://go.microsoft.com/fwlink/?linkid=66138&amp;clcid=0x409"><img src="welcome.png" alt="IIS7" width="571" height="411" /></a>
</div>
<--Snipped Output -->

Setting up Empire

This is also relatively simple. We set the Listener Host option to our Azure front domain (watcocdn1.azureedge.net in our case) and we then add a custom header in our DefaultProfile that points to our CDN endpoint name (darthmalicious.azureedge.net). Example listener configuration is shown.

We can then start the Listener.

We launch an Empire stager, we can see that Azure’s Front Domain is used as the C2 domain.

Examining the traffic, we see the Host Header is used to redirect traffic to its intended destination.

Hardening Your Azure Domain Front

Recently @rvrsh3ll came out with nice post on medium on hardening your Azure Domain Front. This section will cover a few lessons from that post with regards to Azure CDN Rules Engine.

CDN Setup

Visiting the Azure CDN Rules Engine documentation we see it’s a feature of Azure CDN Premium from Verizon only. We create a CDN profile and endpoint name with this in mind. Once you create your CDN endpoint, it may take a few minutes to an hour to configure and propagate completely just as before.

Basic Redirection Rule Creation

While your CDN is running, open the profile page and click the Manage button.

We can then select “HTTP Large” > Rules Engine and we get to this page.

On this page, we can create conditions to match our desired rules. We’ll cover a rule to redirect based on User-Agent using the Request Header Regex. If a User-Agent doesn’t match our specified User-Agent we redirect the traffic to Twitter.

After creation we’ll get a warning: “Approval of new Rules takes up to 4 hours.”

If all goes well, our CDN rules should redirect any non-matching traffic to Twitter and allow matching traffic through to our Empire Instance.

We’ve successfully allowed an empire agent through our cdn and redirected any other traffic to Twitter.

Conclusion

This was mainly a post to summarize my own adventures when looking into domain fronting. While this article discusses a technique to bypass several network security tools, they have their importance when used with other ways of hunting for malicious traffic. Defense in depth should be considered when trying to defend against this technique e.g. Application Whitelisting, Robust EDR solution etc. An approach the blue team might consider is decrypting all traffic and looking for signs of C2 traffic e.g. Default Empire User-Agents, predictable call back times from agents.

Special thanks to Monsieur Numi who helped me get a Microsoft Azure account and all the researchers who looked into domain fronting. I hope this post encourages more researchers to look into more domain fronting opportunities in their offensive engagements and operations.