In this blog post, we will cover HTTPS domain fronting Google hosts (google.com, mail.google.com, etc.) using Cobalt Strike. Domain fronting via google.com has been used by adversaries, and it is valuable to include as part of Red Team assessments.

Domain Fronting is a technique to hide the remote endpoint of communication while leveraging high reputation domains as the cover. It’s valuable to adversaries because it can disrupt existing network analysis capabilities. Though there are means to fingerprint domain fronting, the result is the endpoint malware will be appear to be communicating with a high-reputation domain (e.g. https://www.google.com) while actually communicating with a C2 server.

To our knowledge, the most common approach to detecting domain fronting is to utilize an HTTPS proxy in a man-in-the-middle configuration – commonly referred to as “SSL Termination” – in which all encrypted traffic is decrypted and inspected. Using a man-in-the-middle proxy has its own risks. Furthermore, Google enforces HSTS, leaving only a few vendors with the ability to decrypt SSL traffic targeting Google domains. Considering the most common Google products, this would require enterprise-wide SSL termination and analysis for this non-exhaustive list of Google domains:

Although it is possible to add a second redirector layer between Cobaltstrike and our Google App, it complicates the deployment without actually providing value to the red team. Only a Google employee should be able to view traffic from the GAE to the C2.

Next, the route table for the application, shown here, is very simple.

Any request including URI sent to the AppSpot domain will be sent on to CobaltStrike. This will not be ideal if you want to filter the requests based on User-Agent, originating IP, or URI. These are common deterrents against blue team members typically employed in a redirector.

The last thing to point out is the way the application handles a request sent. The handling of a POST and GET requests is given below.

Notice that the request sent to the appspot application is sent on to the CobaltStrike instance. The application also makes sure to handle HTTP headers sent with the request and any data sent in the body of a POST request. This leaves the application generic enough to be used with different malleable C2 profiles.

Deploy the code:

$. gcloud app deploy

Verify the Redirector

After the code is deployed and the listener is setup, run a quick test to make sure everything is working. Open up the Web Log in CobaltStrike (View > Web Log) and send a cURL request to the GAE app:

Verify the request shows up in the Web View logs. You should receive an empty 200 OK from the cURL request and a 404 in CobaltStrike.

The redirector is working!

Update Your Malleable C2 Profile

The last step is to setup the C2 profile. We have supplied a simple example here.It is a modified version of the webbug profile created by rsmudge.

There are a few important points to make about this profile:

Make sure to modify the ‘header “Host”’ line in both the http-get and http-post section. This should have your appengine name.

We do not need to add any certificate data to the profile. We are using Google’s HTTPS certificates in the beacon to application communication (woot!). From the application to the C2, HTTPS communication is proxied and not accessible from the beacon endpoint.

Not sure if it is required, but the metadata http-get section and the output section of http-post client/server is changed to use base64url. Netbios should also be suitable encoding.

Restart CobaltStrike with the new profile ready for use.

From now on, your beacon traffic should look like it’s going to www.google.com, mail.google.com or docs.google.com.

Additional Resources

Domain Fronting is not new. This post and the techniques are built upon the hard work of others: