When Trust Becomes the Attack Surface

How attackers are abusing legitimate cloud infrastructure to bypass modern phishing defenses

Modern phishing attacks are not what they used to be. The obvious red flags — suspicious domains, broken grammar, mismatched logos — have largely been replaced by campaigns that look entirely legitimate, because in many ways they are.

A recent campaign documented in TLDR InfoSec illustrates this shift clearly. Attackers used Google Cloud Storage to host phishing redirectors, allowing malicious emails to pass standard authentication checks and land in inboxes without triggering filters. The initial link pointed to a real Google domain. The email was technically valid. And users had no obvious reason to be suspicious.

How the Attack Works

Rather than hosting a phishing page on a suspicious or newly-registered domain, the attackers took a simpler route.

They uploaded a small HTML redirector file to a Google Cloud Storage bucket. Phishing emails were sent containing links to that file, structured like:

Phishing URL pattern

https://storage.googleapis.com/<bucket-name>/redirect.html

When a victim clicked the link, the redirector silently forwarded them to a credential-harvesting page controlled by the attacker.

The key detail: only the first hop needs to look legitimate. Because the initial link pointed to storage.googleapis.com, the email passed SPF and DKIM authentication checks, avoided most URL-based filters, and appeared credible to the recipient. The redirect to the actual malicious page happened after the trust check was already cleared.

Why This Technique Works

This attack succeeds because it exploits assumptions baked into most email security controls.

Trusted domains get a free pass. Many email gateways and URL filtering tools treat domains like googleapis.com, microsoft.com, and aws.amazon.com as inherently safe. Attackers know this and deliberately use these platforms as their first hop.
Security controls are domain-centric. Blocklists, reputation scores, and domain-based filtering are largely ineffective when the initial URL belongs to a major cloud provider. The malicious behavior lives downstream of the trust boundary, where many tools stop looking.
Familiar interfaces lower suspicion. Victims are typically redirected to pages mimicking well-known login screens. The combination of a legitimate-looking link and a familiar landing page makes users far less likely to hesitate.

Detecting This Activity

Even when the initial domain is trusted, there are ways to surface suspicious patterns.

In a SIEM (Splunk or Elastic), start by querying email logs for cloud storage links:

Splunk / Elastic — Email log query

index=email_logs
| search "storage.googleapis.com"
| stats count by sender, recipient, url

This can help identify unusual senders leveraging cloud storage links, repeated use of the same bucket across multiple emails, or volume patterns consistent with a phishing campaign.

At the network level, move beyond domain reputation and inspect:

Uncommon or randomized bucket names
URL paths that do not correspond to any known internal resource
Redirect chains where the initial and final domains differ significantly

In the documented campaign, a reused bucket name — whilewait — was identified as a consistent infrastructure indicator across multiple phishing attempts. Even when the domain is trusted, attacker-controlled bucket names can serve as meaningful signals.

Example suspicious pattern

storage.googleapis.com/whilewait/verify.html

A bucket name like whilewait has no obvious connection to legitimate Google services and would warrant investigation if observed in outbound traffic.

The Broader Pattern

This is not an isolated technique. Across the same threat reporting, attackers were also observed abusing LinkedIn to distribute malware through fake venture capital firm profiles, and exploiting special-use domains like .arpa to bypass DNS-based filtering.

The consistent thread across all of these methods:

Cloud storage, file sharing platforms, collaboration tools, and social networks all carry varying degrees of implicit trust. As long as security controls continue to treat trusted domains as safe by default, those platforms will remain attractive staging grounds.

Defensive Takeaways

Treat trusted domains as neutral, not safe

Do not automatically allow cloud storage or file-sharing links. Evaluate the full URL context — the root domain is only the first signal, not the final verdict.

Inspect the full URL path

Focus on bucket names, file paths, and redirect chains — not just the root domain. Attackers rely on security tools stopping at the domain level.

Monitor for redirect behavior

Multiple HTTP redirects, short-lived landing pages, or significant domain mismatches between the initial and final destination are worth flagging regardless of where the chain starts.

Tune SIEM rules for cloud storage abuse

Queries targeting known platforms like storage.googleapis.com, blob.core.windows.net, and similar endpoints can surface campaign patterns early — especially when volume or sender patterns are anomalous.

Maintain user awareness training

Users who understand redirect-based deception are less likely to submit credentials after following unexpected links. Awareness of this technique is a meaningful layer of defense even when technical controls miss it.

Final Thoughts

As organizations adopt more cloud services — and as security tools continue to rely on domain reputation as a primary filter — attackers will keep finding ways to hide within legitimate environments. The challenge is no longer simply identifying malicious infrastructure. It is detecting malicious intent operating inside infrastructure that looks completely normal.

Behavioral analysis, full URL inspection, and redirect chain monitoring are not optional enhancements. They are becoming baseline requirements for effective phishing defense.

← Back to Insights