Cloud Storage Phishing Hosting

Timeline: The Cat and Mouse

2017 ← Attack emerges → 2020 ← Defenses improve → 2023 ← Shifting to serverless → Present

The Evolution

Key Events with Sources

Overview

Attackers host phishing pages on legitimate cloud storage services instead of their own infrastructure. Victims see trusted domains like storage.googleapis.com in the URL, and security filters are reluctant to block major cloud providers entirely.

The Attack

How It Worked

1. Attacker creates a cloud storage bucket (GCS, S3, Azure Blob) with public read access
2. Uploads phishing HTML page mimicking target brand (Office 365, PayPal, banking, etc.)
3. Sends phishing email with link to storage.googleapis.com/[bucket-name]/login.html
4. Victim sees a Google/Amazon/Microsoft domain, assumes it’s safe
5. Victim enters credentials, which POST to attacker-controlled server
6. Attacker harvests credentials

Technical Details

Cloud storage services serve files with appropriate Content-Type headers based on file extension:

• .html → Content-Type: text/html → Browser renders as webpage
• .js → Content-Type: application/javascript → Browser executes
• .css → Content-Type: text/css → Browser applies styles

This means an attacker can host a fully functional phishing page—complete with JavaScript for form validation and credential exfiltration—on “trusted” infrastructure.

Example malicious URL:

https://storage.googleapis.com/hqyoqzatqthj/aemmfcylvxeo.html

The bucket name hqyoqzatqthj is random gibberish—a red flag if you know to look for it, but invisible to users who only see “googleapis.com.”

Why It Worked

• Domain reputation — URL filters scored googleapis.com as trusted
• User trust — Users trained to “look for HTTPS” saw valid Google certificate
• Blocking difficulty — Can’t block cloud storage wholesale without breaking legitimate use
• Anonymity — Easy to spin up, no infrastructure to trace
• Speed — New bucket in seconds, campaign running in minutes

Notable Campaigns

• Office 365 Phishing Wave (2019) — Massive campaign using Azure Blob storage; Microsoft’s own infrastructure hosting O365 phishing
• COVID-19 Lures (2020) — Health organization spoofs hosted on GCS during pandemic
• Banking Campaigns (Ongoing) — Persistent abuse across all major cloud providers

How The Defenses Work

Cloud Provider Abuse Scanning (2019+)

Cloud providers scan uploaded content for phishing patterns:

• Known brand logos (Microsoft, PayPal, banks)
• Credential harvesting forms
• Suspicious JavaScript patterns

Malicious buckets get flagged and taken down—though often hours after the campaign started.

Full-Path URL Inspection (2020+)

Instead of just asking “is googleapis.com safe?”, security tools now analyze:

• Is the bucket name random gibberish?
• Does the path contain login.html, verify.html, secure.html?
• Does the HTML contain login forms for brands the bucket owner doesn’t control?

Real-Time Content Analysis (2022+)

Advanced Secure Email Gateways fetch the destination URL at scan time and analyze:

• Page content and structure
• Form actions (where do credentials POST?)
• Brand impersonation signals
• Behavioral patterns (redirects, JavaScript obfuscation)

Attacker Adaptation

Attackers evolved several counter-techniques:

Sophisticated attackers have largely moved to more evasive hosting:

• Cloudflare Workers — Serverless functions, even harder to inspect
• Compromised legitimate sites — Real business domains with good reputation
• URL shorteners — Hide the destination entirely

Current State

Status: 🟡 Limited Effectiveness

Still seen regularly in the wild, but detection has improved significantly. Success factors:

Detection Guidance

Email Indicators

Look for emails containing:

• storage.googleapis.com URLs
• s3.amazonaws.com URLs
• blob.core.windows.net URLs
• Any cloud storage URL pointing to .html files

URL Red Flags

• Bucket names that are random strings
• Bucket names that don’t match the claimed sender
• Cloud storage hosting HTML (legitimate use is typically media/documents)
• Query parameters with tracking tokens or encoded data

User Reports

Train users to report:

• “Login pages” hosted on cloud storage
• Brand impersonation on Google/Amazon/Microsoft domains
• Emails from unknown senders with cloud storage links

SIEM Queries

If you’re ingesting email logs, alert on:

url.domain:("storage.googleapis.com" OR "s3.amazonaws.com" OR "blob.core.windows.net")
AND url.path:*.html