New Phishing Campaign Exploits Google Storage to Deliver Remcos RAT

A recently observed phishing campaign is abusing Google Cloud Storage to deliver the Remcos remote access trojan (RAT), relying on trusted Google infrastructure and a signed Microsoft binary to evade traditional defenses.

Attackers host a fake Google Drive login page on the legitimate domain storage.googleapis.com, making the URL appear trustworthy to both users and security tools.

Instead of registering their own domain, they upload a crafted HTML page that closely mimics Google’s interface and branding.

The operation highlights how reputation-based filtering alone is no longer enough to stop modern credential theft and malware delivery.

The page requests the victim’s email address, password, and one‑time passcode, effectively capturing full account access. Using Google’s infrastructure also helps phishing links bypass some email filters and URL-reputation checks that favor well‑known cloud providers.

Multi‑stage infection chain

After a “successful” login, the site prompts the user to download a JavaScript file named Bid‑Packet‑INV‑Document.js, presented as a document or bid packet.

When executed, this script runs under Windows Script Host, includes time‑based evasion logic, and launches the next stage VBS script.

The first VBS stage downloads and silently runs another VBS file, which drops components under %APPDATA%WindowsUpdate and configures Startup persistence so the malware survives reboot.

A PowerShell script, DYHVQ.ps1, then orchestrates the loading of an obfuscated portable executable stored as ZIFDG.tmp, which contains the Remcos RAT payload.

To stay stealthy, the chain fetches an additional obfuscated .NET loader from a text‑hosting service (Textbin). It loads it directly in memory via Assembly.Load.

The .NET loader abuses RegSvcs.exe, a legitimate Microsoft .NET Services Installation Tool located in the framework directory, for process hollowing.

Because RegSvcs.exe is signed by Microsoft and often has a clean VirusTotal reputation, its execution usually appears benign in endpoint logs.

The loader creates or starts RegSvcs.exe from %TEMP%, hollowing the process and injecting the Remcos payload so that most of the malicious logic executes only in memory.

This results in a partially fileless Remcos instance that communicates with its command‑and‑control (C2) server while hiding behind a trusted process name.

Detection and defense recommendations

Security teams should not rely solely on domain or file reputation when triaging alerts involving Google cloud domains or signed Windows binaries.

Behavioral sandboxing and EDR telemetry are key: defenders should monitor for suspicious script chains (JS → VBS → PowerShell), unusual creation of WindowsUpdate‑like folders in %APPDATA%, and RegSvcs.exe launching from atypical paths such as %TEMP%.

Network controls should flag outbound connections following execution of scripting engines and newly spawned .NET processes, especially when preceded by access to storage.googleapis.com links.

Finally, user awareness campaigns must emphasize that even links pointing to well‑known cloud providers can host phishing pages and malware, and any unexpected login prompts or script downloads from “Drive documents” should be treated with caution.

Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.