Phishing campaign abused Google Cloud Storage links to redirect victims to scam pages
A phishing campaign spotted in early March used Google Cloud Storage (GCS) links on the trusted storage.googleapis.com domain to funnel victims to scam pages. Research published by malware analyst Anurag says more than 25 phishing emails sent to one inbox all pointed to the same GCS bucket, whilewait, and the same redirector file, comessuccess.html.
The core trick was simple. Attackers hosted a public HTML file in Google Cloud Storage, then used that Google-owned domain as the first hop in the phishing chain. Google’s own Cloud Storage documentation confirms that objects can be made publicly readable, and anyone who knows the object URI can access them for as long as the object remains public.
That does not mean Google was hacked. Based on the available evidence, this was abuse of legitimate cloud hosting, not a compromise of Google infrastructure. That distinction matters, because trusted cloud domains can help phishing links survive email filtering and look safer to users than random attacker-owned domains.
What researchers found
Anurag’s report says the campaign used many different lures, including fake storage warnings, subscription notices, and brand-themed reward scams. Even though the messages looked different, they all pushed victims toward the same GCS-hosted redirector.
The report identifies the shared infrastructure as the whilewait bucket and says the main object was comessuccess.html, a script-heavy redirect page. Sandbox analysis from ANY.RUN also shows traffic to storage.googleapis.com/whilewait/comessuccess.html and classifies the activity as malicious.
Researchers say the redirect completed quickly enough that many users would only see a Google domain for a moment before landing on the real scam site. The end goal, according to the published analysis, was usually credit card harvesting through fake payment or renewal pages.

Campaign details
| Item | Details |
|---|---|
| Hosting platform | Google Cloud Storage |
| Trusted first-hop domain | storage.googleapis.com |
| Reported bucket | whilewait |
| Reported redirect file | comessuccess.html |
| Main technique | Trusted cloud-hosted redirect to third-party phishing site |
| Reported goal | Payment card theft / scam conversion |
Sources: Anurag’s published analysis and sandbox results.
Why this worked
The attackers benefited from trust in a major cloud platform. A storage.googleapis.com link does not automatically mean the content came from Google itself. In Cloud Storage, third parties can upload public objects into their own buckets and serve them through Google infrastructure.
That makes the campaign more convincing than a normal phishing email. Users may recognize the Google domain and lower their guard. Some security tools may also treat the first hop as lower risk than a newly registered phishing domain, especially when the malicious content mainly acts as a redirect layer. This is an inference based on the campaign design and Google’s public-object model.
One point in the sample article needs tighter wording. Passing SPF or DKIM checks does not prove an email is safe. It only shows the sending domain’s mail authentication aligned in a way that passed those checks. Attackers often abuse legitimate infrastructure or compromised services to get authenticated mail delivered. In this case, the main confirmed trust signal was the Google-hosted redirect URL, not proof that Google itself sent the phishing messages.

How the redirect chain appears to operate
According to the published analysis, the phishing email first sends the victim to the GCS object hosted under the whilewait bucket. That object then redirects the browser to an external scam page controlled by the attacker.
The sandbox and public threat-analysis pages also show related variants such as itcomessuccess.html, which suggests the attacker may have used more than one similarly named redirector inside the same bucket. That does not change the core finding, but it suggests the infrastructure may have supported multiple lure variants or A/B-style changes. This is an inference from multiple public analyses referencing the same bucket.
What defenders should do
- Treat Google Cloud Storage links as user-controlled content, not automatically trusted content. Public GCS objects can be hosted by third parties.
- Inspect redirects, not just the first visible domain. In this campaign, the Google domain was only the first hop.
- Hunt for repeated access to the same bucket or object across multiple phishing emails. The researcher found more than 25 messages tied to the same bucket.
- Report abused Google Cloud resources quickly. Google provides a dedicated abuse-reporting form for Cloud Storage and other Google Cloud Platform services.
- Warn users that urgent billing, storage, subscription, and prize emails remain high-risk lures even when the link starts on a familiar domain. That recommendation follows directly from the lures documented in the campaign analysis.
FAQ
There is no evidence in the sources reviewed here that Google infrastructure was compromised. The campaign appears to have abused public Google Cloud hosting, not breached Google itself.
storage.googleapis.com? Because Google Cloud Storage lets users make objects public. Attackers can abuse that feature to host redirectors or phishing assets on a trusted domain.
The published analysis points to the whilewait bucket and the comessuccess.html object as the shared redirect infrastructure.
Google provides a Google Cloud Platform abuse reporting form that specifically covers Cloud Storage.
Read our disclosure page to find out how can you help VPNCentral sustain the editorial team Read more
User forum
0 messages