GTFire Phishing Campaign Exploits Google Services to Bypass Detection and Harvest Credentials

GTFire is a large-scale phishing scheme that abuses multiple Google services to hide malicious infrastructure, evade security tools, and steal credentials from organizations worldwide.

GTFire is a credential-harvesting operation that chains Google Firebase Hosting and Google Translate to deliver phishing pages that look like legitimate brand logins.

Attackers host fake login portals on Firebase .web. app domains.app domains.web.appdomains and wrap them inside translate.goog links, which benefit from Google’s trusted reputation and often slip past email and web filters.

Analysis of exposed command-and-control infrastructure shows over 120 unique phishing domains and stolen credentials tied to more than 1,000 organizations in 100+ countries and 200+ industries.

GTFire Phishing Campaign

Telemetry linked to the GTFire infrastructure points to a global victim base, with Mexico, the United States, Spain, India, and Argentina among the most affected countries.

Group-IB access our Threat Intelligence portal for more information about the GTFire threat actor and phishing scheme.

Victims span manufacturing, education, government, and a wide range of other verticals, highlighting the campaign’s opportunistic, volume-driven targeting strategy.

In one exposed dataset, Mexico alone accounted for 385 victims, followed by 101 in the United States, 67 in Spain, 54 in India, and 50 in Argentina, suggesting focused waves against certain geographies.

GTFire relies on Firebase’s free *.web.app hosting to quickly spin up and rotate phishing pages using randomly generated subdomains, lowering costs and complicating domain-based blocking.

These pages load brand-specific templates on demand, reusing the same phishing framework while swapping logos and minor assets to impersonate multiple services with minimal effort.

At the same time, Google Translate is abused in “website” mode: victims receive translate.goog URLs that proxy the underlying phishing site, mask the true destination, and delay exposure of the Firebase domain until late in the redirect chain.

Redirects, obfuscation, and harvesting

The redirect flow typically starts with a translate.goog link, passes through intermediate translated or IDN/Punycode domains, and only then resolves to the final Firebase phishing page.

Google Translate’s Websites feature, where a full website URL (in this case, group-ib.com) is submitted for automatic translation into another language (Spanish).

URL parameters often contain single or double Base64-encoded data encoding victim email addresses, language settings, and brand identifiers, hindering static analysis and signature-based detection.

Once on the fake login page, users are prompted to enter their credentials twice, with a fake “incorrect password” error between attempts, silently exfiltrating both submissions before redirecting the victim to the real brand site to reduce suspicion.

Stolen data is sent via simple HTTP GET requests to LiteSpeed Web Server–based C2 hosts running commercial “All-in-1” PHP phishing scripts, which centralize collection and make the operation highly automated and scalable.

Directory listings observed on these servers show credentials organized by date, language, and targeted service, indicating a mature workflow geared toward account takeover, resale, and secondary fraud.

Defenders should pivot on patterns in Firebase subdomain generation, translate.goog redirect chains, Base64-heavy URL parameters, and LiteSpeed/All‑in‑1 PHP endpoints, and combine these with brand monitoring and user education, to detect and disrupt similar trusted-service phishing operations.

Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.