Organizations typically allow traffic to essential services such as Google Meet, YouTube, Chrome update servers, and Google Cloud Platform (GCP) to ensure uninterrupted operations. A new domain-fronting technique exploits this trust to create hidden command and control (C2) channels, allowing attackers to funnel malicious traffic through Google's infrastructure without raising suspicion.
See also: Google fixes problematic Meet invitations on Android
Praetorian says that domain-fronting exploits the difference between the TLS Server Name Indication (SNI) and the HTTP Host. In a typical HTTPS handshake, the client presents the SNI in clear text. Once the TLS tunnel is established, the HTTP Host header within the encrypted request can specify an entirely different domain. Through Google’s front-end server routing, hackers can connect to meet.google.com, youtube.com, update.googleapis.com , or even GCP, while back-end routing diverts traffic to attacker-controlled infrastructure hosted on Google Cloud Run or App Engine.
To network observers, the packets appear indistinguishable from legitimate Google usage, mixing malicious C2 with regular corporate traffic. The researchers created a simple Cloud Run that returns “Hello World!” and inserted its URL in the Host header when connecting to google.com. Unexpectedly, the Cloud Run function executed, confirming that the request was routed to an attacker’s infrastructure instead of Google’s public web servers.
See also: Hackers are now testing ClickFix attacks against Linux
This behavior extends to multiple Google domains, including update.googleapis.com and api.snapchat.com (using Google App Engine). Because these domains are often exempt from TLS inspection due to certification or classification as financial or healthcare services, security appliances rarely inspect or block them, providing attackers with near-complete invisibility.
Historically, the major providers blocked domain-fronting by enforcing consistency between SNI and the Host header. However, Google's load balancer internal routing logic still allows mismatches for certain services, creating an inadvertent fronting entity. The attack sequence is as follows: a TLS handshake starts with the SNI set to a high-reputation Google domain (e.g., youtube.com). Within the encrypted request, it sets the Host header to the C2 domain hosted on Cloud Run or App Engine. Google's front-end accepts the SNI, terminates TLS, and routes the decrypted HTTP request to the backend infrastructure based on the Host header.
The attacker’s infrastructure handles the request, allowing bidirectional traversal over standard HTTPS. A redirector tool, praetorian-inc/google-redirector, automates the setup for red team engagements. Deploying this redirector alongside existing implants allows for seamless HTTP-based C2 over Google’s highly trusted channels. This technique revives the power of domain-fronting within the Google ecosystem, presenting defenders with a formidable challenge: blocking malicious C2 without disrupting core business services.
See also: Google Meet: Adds new screen reading options
Vigilance requires enhanced detection strategies, such as certificate consistency checks, analysis of anomalous traffic patterns, and strict host validation at the enterprise perimeter level. As attackers turn the backbone of the Internet into their hidden conduit, defenders must adapt to detect covert threats lurking in plain sight.
🔒 Protect your privacy with Proton VPN
Swiss VPN from the creators of Proton Mail — strict no-logs policy, strong encryption, and built-in NetShield that blocks ads, trackers, & malware.
- ✔ No-logs, based in Switzerland (except 14-Eyes)
- ✔ NetShield: blocks ads, trackers & malicious domains
- ✔ Covers all devices — free version available
The link is an affiliate link — SecNews may receive a commission at no additional cost to you. It does not affect the independence of our article writing.
