Overview
At Black Hat and DEF CON, we demonstrated how red teams could tunnel traffic through everyday collaboration platforms like Zoom and Microsoft Teams, effectively transforming them into covert communication channels for command-and-control. That research highlighted a critical blind spot: defenders rarely block traffic to core business services because doing so would disrupt legitimate operations. This creates a trust gap that attackers can exploit.
Today, we’re taking that research a step further. What if we could perform tunneling not just through web conferencing applications, but through the very backbone of the Internet, Google’s own infrastructure? Services like Google Meet, YouTube, Chrome’s update servers, and even Google Cloud Platform (GCP) form part of the daily workflow and backbone for billions of users worldwide. They’re too critical for defenders to simply block, making them an ideal cover for stealthy adversary operations.
The technique at the center of this research is domain fronting. In practice, this means an attacker could connect to a domain such as google.com or meet.google.com, and while the front-end traffic looks legitimate, the backend routing quietly diverts the connection to attacker-controlled infrastructure hosted inside GCP. To anyone monitoring the wire, the traffic appears indistinguishable from normal Google usage yet the traffic is entirely under adversary control.
In this article, we present a new technique for performing domain fronting against Google hosted infrastructure. This approach applies broadly across Google’s primary services and, importantly, extends to customer-facing systems built on Google App Engine, such as popular apps like Snapchat. The end result is that we are now able to tunnel traffic through some of the most trusted and widely used infrastructure on the Internet.
What is Domain Fronting
Domain fronting is a technique that takes advantage of the way HTTPS connections handle hostnames. When you connect to a site like google.com over TLS, two different hostnames come into play:
- SNI (Server Name Indication): Sent in cleartext during the TLS handshake. This tells the front-end which host you appear to be connecting to — for example, google.com.
- HTTP Host Header: Sent later inside the encrypted HTTPS request. This tells the backend which server should actually handle the traffic — for example, myc2.attacker.com.
With domain fronting, these two values don’t match. You make the SNI look like a trusted, high-reputation service (google.com), but the Host header quietly points traffic to attacker-controlled infrastructure. From the outside, the traffic looks like normal usage of a major service. But on the backend, it’s routed somewhere entirely different. For defenders, this is problematic because blocking access to services like Google or YouTube simply isn’t an option in most enterprises.
Isn’t Domain Fronting a Dead Technique?
Historically, domain fronting was widely used for both censorship circumvention and covert command and control. However, due to the backlash and abuse of these services, major providers have moved to prevent domain fronting. This includes Cloudflare in 2015, Amazon in 2018, Google in 2018, Microsoft in 2022, and Fastly in 2024 (source).
While domain fronting is an incredibly useful technique for red teamers, it’s become increasingly hard to find useful vectors for domain fronting. Some of my favorite command and control channels I’ve used on engagements have been when I was using a customer’s own infrastructure for domain fronting. It’s one of those things where if you aren’t aware of the technique it seems almost magical like “the call is coming from inside the house” type vibes.
Anyway, while it’s true that domain fronting in the broad general sense is largely dead, in this article we want to dive into an interesting edge case we identified on Google’s infrastructure that opens up some neat channels for reviving the domain fronting technique.
Long Live Domain Fronting
This research came from an interesting observation that we made several years ago in regard to Google’s infrastructure. The observation came from an interesting observation we observed. First, we created a Google Cloud Run function which simply returned “Hello World!” when invoked. Next, we inserted this function into the host header of an HTTP request to the google.com website.
In this scenario, we observed that the cloud run function was invoked which was unexpected given that we were connecting to google.com. Figure 1 shows a request made to google.com with the host header set to our Google Cloud Run function and the response shows that our “Hello World!” response indicating domain fronting is working against this domain. Figure 2 shows this technique applied to other Google domains like update.googleapis.com, meet.google.com, and payments.google.com.
Figure 1: A screenshot showing a connection to google.com being used to send traffic to a backend command and control redirector running as a Google Cloud Run function.
Figure 2: We observed a significant number of other Google domains we could leverage for command and control, each being high-traffic domains with interesting profiles.
Why do I care about Snapchat?
In the introductory section of this article we mentioned that Snapchat is one of the services that we identified that could be leveraged using this technique for domain fronting as they leverage Google AppEngine quite heavily. At the moment, we aren’t sure what the root cause of this is in practice, but we observed that sites hosted on Google AppEngine can also be leveraged for domain fronting using this technique. Figure 3 shows we are able to leverage api.snapchat.com for domain fronting using this technique as it is leveraging AppEngine.
Figure 3: We observed it was possible to leverage api.snapchat.com for domain fronting as it is hosted on Google AppEngine.
The next obvious question though is why Snapchat. It’s certainly not the first thing you might think of to leverage for command and control. The answer itself is kind of interesting. During my research into tunneling traffic through web conferencing infrastructure, I was curious what the default rulesets looked like for sites excluded from TLS inspection. Next, I leveraged some basic automation to identify sites within this list that leveraged Google AppEngine and identified a number of subdomains like api.snapchat.com. I’ve uploaded the default exclusion list for Palo Alto Networks firewalls on a GitHub gist here which you can leverage for additional research as well.
This domain is by default excluded from TLS inspection due to certificate pinning and this might be an interesting choice for domain fronting using this technique if you are concerned about any security appliances doing TLS inspection and comparing the host header to the SNI used for the connection.
Leveraging domains excluded from TLS inspection is useful in this scenario as even if an appliance is doing those types of checks it won’t be possible if they aren’t performing TLS inspection on the connection. Figure 4 shows the default exclusion list pulled from a PANW firewall showing that Snapchat services are excluded from inspection by default due to the application leveraging certificate pinning.
FFigure 4: We spun up and configured a PANW firewall in order to inspect the default exclusions and other configuration settings implemented by the appliance.
Another common vector is domains classified as things like healthcare or financial services related domains, including domains like payments.google.com which are frontable with this technique as well. This domain is classified as a financial services-related domain and many appliances will exclude it from inspection (see Figure 5).
Figure 5: An image showing the payments.google.com domain classified as a financial services site.
Building a Google Cloud Run Redirector
To assist in using this technique during red team engagements, we’ve developed a redirector that can be deployed alongside any existing implant that leverages HTTP for command and control communications for domain-fronting. This redirector is located at praetorian-inc/google-redirector and comes with an easy-to-deploy script to set up and deploy the tool. As the setup process is documented in the README we don’t repeat it here in this article, but the process is very straightforward.
Conclusion
In this article, we presented a new domain fronting technique that can be leveraged against Google infrastructure to route command and control traffic through core Internet infrastructure and domains. This technique complements our previous research on routing traffic through Zoom and Microsoft Teams infrastructure we published at Black Hat and DEF CON.
For red teams, this technique expands the playbook for stealthy operations. For defenders, it’s a reminder that trust in “big name” services must be paired with careful inspection and detection strategies. The challenge is no longer just about keeping malicious traffic out, it’s about recognizing when it’s already hiding inside the services you depend on most.
