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.002

Timeline

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

  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:

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.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

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

Attacker Adaptation