GTFire Phishing Scheme: Avoiding Detection Using Google Services

Introduction

Over the past several years, phishing campaigns have evolved beyond simple spoofed emails and low-effort fake login pages. Modern threat actors increasingly rely on legitimate cloud services, trusted domains, and well-known technology platforms to blend malicious activity into normal internet traffic. One such campaign, tracked as GTFire, demonstrates how attackers can systematically abuse Google-owned infrastructure to distribute phishing pages, evade security controls, and harvest credentials from thousands of victims worldwide.

The GTFire scheme relies heavily on Google Firebase (web.app) for hosting phishing pages and on Google Translate as an intermediary layer that disguises malicious URLs, enabling them to bypass email and web security filters. By chaining these services together, the attackers create phishing links that appear benign, leverage Google’s reputation, and dynamically redirect victims to brand‑impersonating login pages.

Once credentials are submitted and harvested, victims are often redirected back to the legitimate website of the targeted organization, reducing suspicion and delaying incident response.

This campaign is notable not only for its technical sophistication but also for its scale. Analysis of exposed command-and-control (C2) infrastructure reveals thousands of stolen credentials associated with more than 1,000 organizations, spanning over 100 countries and hundreds of industries.

The attackers demonstrate strong operational discipline; reusing phishing templates across brands, enforcing multi‑step credential collection, and maintaining centralized servers that store harvested data in an organized manner.

From a defensive perspective, GTFire highlights several uncomfortable truths. Trusted services can be weaponized with minimal effort, traditional URL-based detection is insufficient, and brand abuse remains one of the most effective social engineering vectors.

This blog aims to document the GTFire phishing scheme in detail, outline its modus operandi, map victimology, and provide actionable recommendations for defenders, CERT teams, and law enforcement.

Key Takeaways

1. GTFire abuses trusted Google services, including Firebase and Google Translate, to scale phishing and reduce detection.

2. The campaign uses redirect chains and encoded URLs to obscure the final phishing destination.

3. Victims are often redirected back to the legitimate brand website after credential theft, which delays suspicion and response.

4. Security teams should hunt for translate.goog and web.app redirect patterns rather than rely only on static domain blocklists.

5. Group-IB’s analysis shows that trusted cloud-service abuse is now a core phishing tactic defenders must monitor proactively.

Who May Find This Blog Interesting

• Cybersecurity analysts and corporate security teams
• Malware analysts
• Threat intelligence specialists
• Cyber investigators
• Computer Emergency Response Teams (CERT)
• Law enforcement investigators
• Cyber police forces

What is the GTFire phishing scheme?

GTFire is a large-scale phishing campaign that abuses Google Firebase and Google Translate to host phishing pages, disguise malicious links, and steal credentials while reducing detection. Group-IB researchers observed the scheme impacting over 1,000 organizations across more than 100 countries.

Group-IB Threat Intelligence Portal: GTFire

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

Victimology

Figure 1. GTFire phishing scheme global victimology.

Infrastructure and Techniques

Abuse of Google Firebase Hosting (web.app)

GTFire relies on Google Firebase’s free and fast hosting infrastructure to deploy phishing pages at scale. The threat actor registers large volumes of randomly generated *.web.app subdomains, allowing rapid rotation of infrastructure and minimizing operational costs. Because Firebase domains are widely trusted and frequently used by legitimate developers, these phishing pages often bypass reputation-based security controls.

Firebase-hosted pages dynamically load brand-specific login templates, displaying logos and visual elements of the targeted organization. The same phishing framework is reused across multiple brands, with only minor changes to URL paths and visual assets, enabling efficient scaling across regions and industries.

Domain Generation Patterns

Despite these characteristics, Firebase domains observed by Group-IB researchers in this campaign follow predictable, high-volume naming patterns, including:

• Randomized alphabetic strings of 6-10 characters
• Alphanumeric combinations designed to evade simple blocklists

These patterns enable defenders to build proactive hunting rules rather than relying on static domain lists.

Google Translate as a Phishing Shield

Phishing shield is a security layer that detects, blocks, or warns users about phishing pages before credentials or sensitive data are exposed. A defining feature of the GTFire campaign is the systematic abuse of Google Translate’s website translation functionality. Phishing links are distributed to victims in the form of translate.goog URLs, which act as an intermediary redirect layer between the victim and the malicious Firebase-hosted phishing page.

Google Translate – Website Translation Mode

These links use Google Translate’s website translation feature. Google loads the original website through a translation proxy and dynamically replaces the visible text with the translated version, while preserving the original site structure and navigation. The original website itself is not modified; only the content rendered in the victim’s browser is translated.

The first screenshot below demonstrates 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).

Figure 2. Google Translate “Websites” mode for translating an entire website.

The second screenshot shows the result, which is the same website rendered through Google Translate’s translation proxy (translate.goog domain), with dynamically translated content displayed in the browser.

Figure 3. Group-IB website displayed via Google Translate proxy, showing the translated version of the original site in the browser.

This technique provides several advantages to the attacker:

• Obfuscation of the final phishing destination.
• Increased trust due to the use of Google-owned domains.
• Reduced likelihood of blocking by email and web gateway security controls.

In many cases, the underlying Firebase phishing domain becomes visible only after the Google Translate redirect chain is fully resolved, significantly complicating automated detection and analysis.

Figure 4. GTFire infrastructure overview.

The GTFire campaign leverages a multi-step redirect chain to obscure the final phishing destination and delay exposure of the underlying malicious infrastructure.

Victims are initially presented with a Google Translate URL (translate.goog), which acts as the first redirection layer. This URL forwards the request through Google-owned translation infrastructure before resolving to the final Firebase-hosted phishing page.

During this process, the request passes through multiple intermediate URLs, including:

• Internationalized Domain Name (IDN) representations encoded in Punycode (IDN allows domain names to use non-Latin characters, while Punycode converts those characters into ASCII format so browsers and DNS systems can read them)
• Google Translate proxy subdomains
• Dynamically generated path segments

Only after the full redirect chain is resolved does the browser load the final phishing page hosted on a .web.app domain.

Example Redirect Flow

Figure 5. How legitimate Google Translate and Firebase domains are used to mask and host malicious webpages.

1. The initial link
   Victim clicks a translate.goog URL distributed via phishing messages.
2. Google Translate proxy layer
   The request is processed by Google Translate’s web translation service, which rewrites the URL and forwards the request through Google-controlled infrastructure.
3. Intermediate translated domain
   The browser resolves encoded and translated domain names (including IDN/Punycode variants), further obscuring the true destination.
4. Final destination on Firebase (Primary Request)
   The request ultimately resolves to the phishing page hosted on Firebase (see below). Even at this stage, the Firebase domain only becomes visible in network traffic or browser developer tools, not necessarily in the address bar during earlier steps.

URL Obfuscation and Encoding

The phishing URLs frequently contain Base64-encoded parameters that embed victim-specific information, such as email addresses, language preferences, and targeted brands. In some cases, parameters are double-encoded to further hinder analysis and signature-based detection.

Figure 6. Double base64 decoding the URL parameter:
WTJGc2JDNTJhWEowZFdGc09VQmlZVzV2Y25SbExtTnZiUT09OkI0STNY

Credential Harvesting Workflow

Credential harvesting is the theft of usernames, passwords, MFA codes, or other login details through fake forms, malware, or deceptive websites. Once a victim lands on the phishing page, the credential harvesting process follows a consistent and deliberate workflow:

1. The victim enters their username and password.
2. The phishing page displays an “incorrect password” message.
3. Credentials from the first attempt are silently exfiltrated.
4. The victim is prompted to re-enter their password.
5. Credentials from the second attempt are also harvested.
6. The victim is redirected to the legitimate website of the impersonated brand.

This design increases the attacker’s chances of capturing valid credentials while minimizing user suspicion.

Figure 7. Phishing pages use fake error prompts and retry attempts to hide credential exfiltration in the background.

Data Exfiltration

Captured credentials are transmitted via HTTP GET requests to attacker-controlled command-and-control (C2) servers. Passwords are Base64-encoded and accompanied by metadata such as:

• Victim email address
• Country of access
• Browser language

Figure 8. The request with the credentials are sent on the url parameters, the password encrypted in base64, alongside with the country of the visit and the language.

The primary C2 infrastructure observed by Group-IB researchers in this campaign operates on LiteSpeed Web Server instances, hosting centralized PHP-based collection scripts (e.g., All-in-1.php).

The operational mechanics of the GTFire threat actor’s web application phishing campaign reveal a reliance on simplicity and automation for maximum scale. Credential exfiltration is achieved through an unsophisticated but effective method. The captured credentials are simply submitted via URL parameters within a standard HTTP GET request. Specifically, the compromised user’s email is transmitted directly, while the corresponding password is first Base64 encoded before being included. This information is bundled with telemetry data, including the geographical country of the victim’s visit (<COUNTRY>) and the user’s browser language setting (<LANGUAGE>), providing the threat actor with valuable context for post-phishing operations or filtering.

The structure of the exfiltration request is as follows:

Once again, the cornerstone of the GTFire campaign’s success is its strategic use of readily available tools, such as commercial All-in-1 PHP phishing scripts. This tactical choice dramatically reduces the operational overhead and speeds up the deployment cycle.

These pre-packaged scripts are highly efficient, simplifying the creation of sophisticated, convincing phishing pages and automating the critical backend logic required for credential harvesting and exfiltration. This changes an attack that is typically complex, multi-stage, and highly customized per target, into a readily available plug-and-play operation.

By building their infrastructure on common, legitimate software components, such as the ubiquitous PHP scripting language and the high-performance LiteSpeed Web Server, the GTFire actor minimizes the need for specialized custom development and reduces the risk of being associated with maintaining unique, easily fingerprinted infrastructure.

This commitment to automation enables GTFire to instantly replicate and deploy new credential harvesting pages across its continually rotating network of domains. all while maintaining minimal resource investment.

Command-and-Control (C2) Infrastructure

Figure 9. Group-ib Graph of observed GTFire network infrastructure.

Analysis of exposed directories on observed C2 servers reveals structured storage of stolen credentials, organized by:

• Date
• Language
• Targeted service or brand

This level of organization suggests a mature operational workflow and potential downstream use of the stolen data for account takeover, resale, or secondary fraud campaigns.

Figure10. Litespeed Web Server, where the harvested credentials and phishing scripts are stored.

Group-IB’s Path to Detecting and Disrupting GTFire-Style Phishing

Conventional phishing awareness guidance has long centered on recognizable indicators: an unfamiliar sender address, poor grammar, or a URL that does not match the expected domain. For most of the past decade, those signals were sufficient to identify most phishing attempts.

GTFire is the campaign that makes that advice obsolete.

This campaign presented no suspicious domains, no grammatical errors, and no visual inconsistencies that standard awareness training would flag. Victims encountered a Google-hosted link that resolved to a convincing replica of a familiar login page, one that requested credentials in exactly the way legitimate services do.

In most cases, by the time a victim might have questioned the interaction, their credentials had already been silently exfiltrated, and they had been redirected to the genuine website, leaving no immediate indication that anything had gone wrong.

That is what makes this campaign worth studying carefully. It did not succeed because it was technically extraordinary. It succeeded by being ordinary, blending into infrastructure people already trust, and exploiting the assumption that a Google domain means safety.

What defenders need to change

The uncomfortable shift here is not technical. It is psychological. Trust needs to be earned in context, not assumed from a brand name in a URL.

For security teams:

• Correlate URL patterns involving translate.goog and web.app — do not treat Google-owned domains as automatically safe
• Monitor for brand impersonation across trusted cloud platforms, not just standalone phishing domains
• Share IOCs across industry and CERT communities before the next infrastructure rotation makes yesterday’s blocklist irrelevant

For organizations:

• Implement phishing-resistant MFA. It removes stolen credentials from the equation entirely, regardless of how convincing the phishing page is
• Train employees specifically on Google-based phishing techniques, not generic awareness that GTFire-style campaigns are designed to bypass

Group-IB’s investigation traced GTFire across more than 1,000 organizations and over 100 countries, mapping the infrastructure, credential-harvesting workflow, C2 architecture, and operational patterns that make this campaign replicable at scale.

&nbsp; 

Group-IB Fraud Matrix

Indicators of Compromise (IOCs)

Network IOCs

• jnhwzs[.]fyi
• gnpnia[.]lat

Network Indicators

• *.web.app with Google Translate redirects

File Indicators

• All-in-1.php credential collection scripts

DISCLAIMER: All technical information, including malware analysis, indicators of compromise and infrastructure details provided in this publication, is shared solely for defensive cybersecurity and research purposes. Group-IB does not endorse or permit any unauthorized or offensive use of the information contained herein. The data and conclusions represent Group-IB’s analytical assessment based on available evidence and are intended to help organizations detect, prevent, and respond to cyber threats.

Group-IB expressly disclaims liability for any misuse of the information provided. Organizations and readers are encouraged to apply this intelligence responsibly and in compliance with all applicable laws and regulations.

This blog may reference legitimate third-party services such as Telegram and others, solely to illustrate cases where threat actors have abused or misused these platforms.

This material is provided for informational purposes, prepared by Group-IB as part of its own analytical investigation, and reflects recently identified threat activity.

All trademarks referenced herein are the property of their respective owners and are used solely for informational purposes, without any implication of affiliation or sponsorship.