Listen to this Post
Introduction:
Cybercriminals are increasingly abusing trusted cloud services to bypass traditional email security filters. By hosting phishing pages on Google’s own `storage.googleapis.com` domain, attackers exploit users’ inherent trust in Google-branded URLs, making detection significantly harder for both email gateways and human targets.
Learning Objectives:
- Understand how attackers leverage Google Cloud Storage to host fake login pages and deliver Remcos RAT.
- Learn to detect and block malicious JavaScript files delivered via trusted cloud domains.
- Implement defensive measures across email filters, endpoint detection, and cloud security configurations.
You Should Know:
- Anatomy of the Attack: From Phishing Email to RAT Execution
This campaign begins with a spear-phishing email containing a link to `storage.googleapis[.]com` – a legitimate Google Cloud Storage endpoint. The landing page mimics Google Drive’s authentication interface, complete with branded logos and file icons (PDF, DOC, SHEET, SLIDE). Victims are prompted to enter their credentials and any one‑time passcode (OTP). After harvesting this data, the page triggers a download of a malicious JavaScript file named Bid-P-INV-Document.js.
Step‑by‑step guide – How to analyze the JavaScript payload (Linux/macOS):
1. Download the suspicious JS file (use a sandboxed environment) wget https://storage.googleapis.com/malicious-bucket/Bid-P-INV-Document.js <ol> <li>Examine the file type and basic strings file Bid-P-INV-Document.js strings Bid-P-INV-Document.js | head -50</p></li> <li><p>Deobfuscate using js-beautify and look for suspicious patterns npm install -g js-beautify js-beautify Bid-P-INV-Document.js > deobfuscated.js</p></li> <li><p>Search for known Remcos RAT indicators (e.g., PowerShell download cradle) grep -iE "powershell|Invoke-Expression|FromBase64String|WebClient" deobfuscated.js</p></li> <li><p>Extract URLs or IPs for blocking grep -oE '(https?|http?)://[^\s"'\''<>]+' deobfuscated.js | sort -u
Windows PowerShell detection example:
Scan downloaded JS files for known malicious patterns Get-ChildItem -Path C:\Users\Downloads.js -Recurse | Select-String -Pattern "WScript.Shell|Shell.Application|ActiveXObject|Invoke-Expression" | Out-File suspicious_js.txt Block execution of JS via Windows Script Host (system-wide) reg add "HKLM\Software\Microsoft\Windows Script Host\Settings" /v Enabled /t REG_DWORD /d 0 /f
- Email Filter Bypass: Why Google’s Domain Is a Blind Spot
Most email security solutions maintain allowlists for major cloud providers like Google, Microsoft, and Amazon. A link to `storage.googleapis.com` is rarely flagged as malicious, even if the bucket is attacker‑controlled. The campaign exploits this trust by hosting a convincing phishing page on a subdomain that shares the same parent domain as legitimate Google services.
Step‑by‑step guide – Hardening email filters against trusted‑domain abuse:
Linux: Add custom SURBL or DNSBL overrides (Postfix example) echo "storage.googleapis.com REJECT Cloud storage used in phishing" >> /etc/postfix/sender_access postmap /etc/postfix/sender_access systemctl reload postfix Alternatively, use SpamAssassin custom rules echo "header CLOUD_PHISHING URIBL_BLACK == 'storage.googleapis.com'" >> /etc/mail/spamassassin/local.cf echo "describe CLOUD_PHISHING Link to Google Cloud Storage with phishing pattern" >> /etc/mail/spamassassin/local.cf echo "score CLOUD_PHISHING 3.5" >> /etc/mail/spamassassin/local.cf systemctl restart spamassassin
Microsoft 365 / Exchange Online rule (via PowerShell):
Create a transport rule to prepend warning to emails with links to storage.googleapis.com New-TransportRule -Name "Block Google Cloud Storage Phishing" -SubjectContainsWords "Document","Invoice","Bid" -DomainIs "storage.googleapis.com" -SetHeaderName "X-Warning" -SetHeaderValue "Suspicious link detected – do not enter credentials"
- Credential Harvesting: How the Fake Login Page Steals OTPs
The fake Google Drive page not only captures email/password but also prompts for a one‑time passcode. This defeats MFA by tricking the user into providing the second factor in real time. Attackers can then use these credentials to log into the victim’s actual Google account, enabling further account takeover and lateral movement.
Step‑by‑step guide – Detecting and blocking credential harvesting endpoints:
Monitor HTTP POST requests to suspicious paths (using tcpdump + ngrep) sudo tcpdump -i eth0 -n -s 0 'tcp port 80 or tcp port 443' -A | grep -i "POST /.login" Create an iptables rule to log traffic to known malicious buckets (extract from analysis) sudo iptables -A OUTPUT -d storage.googleapis.com -j LOG --log-prefix "GCS_PHISHING: " sudo iptables -A OUTPUT -d storage.googleapis.com -j DROP after verification
Windows Defender Firewall rule to block Google Cloud Storage entirely (if not needed):
New-NetFirewallRule -DisplayName "Block Google Cloud Storage" -Direction Outbound -RemoteAddress "142.250.0.0/15" -Action Block
4. Remcos RAT Payload: Post‑Exploitation and Persistence
Once the JavaScript file executes (often via double‑click by the user), it downloads and runs the Remcos RAT. Remcos provides attackers with full remote control: keylogging, screen capture, file exfiltration, and command execution. It establishes persistence via Windows Registry or scheduled tasks.
Step‑by‑step guide – Detecting Remcos RAT indicators on Windows:
Check for known Remcos mutexes and registry keys
Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" | Select-Object -ExpandProperty "Remcos"
Get-ItemProperty -Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\Run" | Select-Object -ExpandProperty "Remcos"
Find scheduled tasks with suspicious names
Get-ScheduledTask | Where-Object {$_.TaskName -match "Update|Java|Chrome"} | Format-List
Use Sysinternals Autoruns to inspect persistence (download from Microsoft)
autoruns64.exe /accepteula /nobanner /v /output remcos_autoruns.csv
Linux command to scan for Remcos network patterns in logs:
Look for outbound connections to known C2 ports (Remcos often uses 2404, 443, 8080) sudo grep -E "DPT=2404|DPT=443|DPT=8080" /var/log/kern.log | grep "SRC=<internal_ip>"
- Cloud Hardening: Preventing Abuse of Your Own Google Cloud Storage
Organizations using GCP can unintentionally host malicious content if buckets are misconfigured. Attackers may upload phishing pages to publicly writable buckets. Implement strict bucket policies and monitoring.
Step‑by‑step guide – Secure GCP bucket configuration:
1. Disable public access at organization level
gcloud resource-manager org-policies enable-enforce storage.publicAccessPrevention --organization=ORG_ID
<ol>
<li>Set bucket to uniform bucket-level access
gsutil uniformbucketlevelaccess set on gs://your-bucket</p></li>
<li><p>Block cross-origin requests that mimic login pages
gsutil cors set cors-config.json gs://your-bucket
Example cors-config.json: [{"origin": ["https://yourdomain.com"], "method": ["GET"], "responseHeader": ["Content-Type"], "maxAgeSeconds": 3600}]</p></li>
<li><p>Enable VPC Service Controls to restrict access to approved IPs
gcloud access-context-manager perimeters create storage-perimeter --resources=projects/your-project --restricted-services=storage.googleapis.com
6. Mitigation Blueprint: Email, Endpoint, and User Training
A layered defense is essential. Combine technical controls with user awareness to break the kill chain.
Step‑by‑step guide – Immediate incident response:
- Extract IOCs from the JavaScript file – Use the Linux commands in Section 1 to get C2 IPs, domains, and file hashes.
- Block at firewall level – Add extracted IPs to blocklist (Linux:
iptables, Windows:New-NetFirewallRule). - Search email logs for any clicks on `storage.googleapis.com` links in the last 30 days.
- Revoke OAuth tokens for any compromised Google accounts (admin.google.com > Security > API controls).
5. Deploy YARA rules for Remcos on endpoints:
rule Remcos_RAT_JS_Loader {
strings:
$js1 = "ActiveXObject" nocase
$js2 = "WScript.Shell" nocase
$js3 = "http://" ascii
$js4 = "base64" nocase
condition:
(uint16(0) == 0x5A4D or uint32(0) == 0x6E6F6A) and 2 of ($js)
}
What Undercode Say:
- Trust no domain, even “legitimate” ones – Attackers abuse Google Cloud Storage because security tools allowlist it. Implement URL rewriting and sandboxing for all cloud storage links.
- MFA is not a silver bullet – Real‑time phishing pages that capture OTPs bypass traditional MFA. FIDO2/WebAuthn tokens are resistant to this because they validate the site’s origin.
- JavaScript files are the new macro – Blocking `.js` attachments and disabling Windows Script Host by default reduces the attack surface dramatically.
This campaign demonstrates a sophisticated understanding of security blind spots: leveraging trust in Google’s infrastructure, mimicking the login flow, and delivering a powerful RAT. The only way to stay ahead is to treat every link – even those from `google.com` – as potentially malicious until verified. Organizations should implement outbound TLS inspection, deploy browser isolation for unknown links, and enforce strict Content Security Policies (CSP) that disallow inline scripts from untrusted sources.
Prediction:
Expect a surge in “trusted cloud” phishing over the next 12 months. Attackers will expand beyond Google to abuse AWS S3 (s3.amazonaws.com), Azure Blob (blob.core.windows.net), and even CDN providers like Cloudflare. Email filters will adapt with ML‑based anomaly detection that inspects page content rather than just the domain. Meanwhile, we will see the first major data breach caused entirely by an attacker‑controlled cloud storage bucket that was allowed through because “it’s just Google.” To counter this, security vendors will introduce “trusted domain sandboxing” – automatically detonating any link to a major cloud provider in a disposable browser environment before delivering it to the user.
▶️ Related Video (80% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Cybersecuritynews Cyberattacknews – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
