Cloud Storage Phishing Hosting
Hosting phishing pages on trusted cloud storage (GCS, S3, Azure Blob) to bypass URL reputation filters; still active but detection improving.
MITRE ATT&CK: T1566.002Timeline
| Period | Status | Notes |
|---|---|---|
| 2017-2019 | 🟢 Peak | Explosion of GCS/S3-hosted phishing; filters not inspecting paths |
| 2020-2022 | 🟡 Decline | Cloud providers add abuse detection; SEGs start path inspection |
| 2023-Present | 🟡 Limited | Still works with rapid rotation; detection improving |
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
- Attacker creates a cloud storage bucket (GCS, S3, Azure Blob) with public read access
- Uploads phishing HTML page mimicking target brand (Office 365, PayPal, banking, etc.)
- Sends phishing email with link to
storage.googleapis.com/[bucket-name]/login.html - Victim sees a Google/Amazon/Microsoft domain, assumes it’s safe
- Victim enters credentials, which POST to attacker-controlled server
- 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.comas 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:
| Evasion | Description |
|---|---|
| Rapid rotation | Use bucket for hours, abandon before takedown |
| Legitimate-sounding names | microsoft-support-docs instead of xj7yhq9 |
| Redirect chains | Cloud storage redirects to actual phishing page elsewhere |
| Cloaking | Serve different content to security scanners vs. real users |
| Encrypted/obfuscated content | Base64-encoded pages that decode client-side |
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:
| Works When | Fails When |
|---|---|
| Attacker uses believable bucket names | Random gibberish bucket names |
| Campaign is short-lived (hours) | Campaign runs for days |
| Target org has basic email filtering | Target has advanced URL analysis |
| Target users aren’t security-aware | Users trained to inspect URLs |
Detection Guidance
Email Indicators
Look for emails containing:
storage.googleapis.comURLss3.amazonaws.comURLsblob.core.windows.netURLs- Any cloud storage URL pointing to
.htmlfiles
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
What Killed It (or Weakened It)
| Defense | Introduced | Impact |
|---|---|---|
| Cloud Provider Abuse Scanning | 2019 | Automated detection of phishing content in public buckets |
| Full-Path URL Inspection | 2020 | SEGs analyze bucket names and file patterns, not just domain |
| Real-Time Content Analysis | 2022 | Fetch and analyze page content before email delivery |