How Attackers Abuse Cloud Services to Mask Attack Origins and Build False Trust

This article is based on reporting originally published by TechRepublic and references research from Menlo Security (circa late 2018).

The Lock Icon Is Not Enough

Security awareness training has long leaned on a simple heuristic: if a website shows the browser padlock icon, it is encrypted and therefore safe. Google’s Chrome browser reinforced this mental model by prominently displaying the lock for HTTPS connections. For everyday users, lock equals trustworthy — a clean piece of skeuomorphic design that unfortunately creates a dangerous blind spot.

Encryption confirms that traffic between a browser and a server has not been tampered with in transit. It says nothing about whether the content being served is malicious. Attackers have understood this distinction for years, and a class of campaigns documented by Menlo Security illustrates just how effectively that gap can be exploited.

Using Legitimate Cloud Infrastructure to Host Malware

Rather than standing up their own command-and-control servers — which are expensive to maintain, easy to fingerprint, and straightforward to blacklist — attackers have begun hosting malicious payloads directly on reputable cloud storage platforms. Menlo Security’s research identified trojan downloads served from domains such as storage.googleapis.com, a legitimate Google Cloud Storage endpoint.

The advantages for an attacker mirror the advantages cloud computing offers any enterprise:

• Low cost: No server infrastructure to purchase or maintain.
• High availability: Cloud providers operate globally redundant infrastructure.
• Trusted reputation: The hosting domain is already whitelisted by virtually every organisation on the planet.
• HTTPS by default: Traffic is encrypted, satisfying both user expectations and many automated security checks.

Why Blacklists and Whitelists Cannot Solve This

Consider the position of an IT or security team when a user follows a phishing link to download a trojan from storage.googleapis.com. From the user’s perspective, the URL contains “google,” the padlock is present, and the download proceeds without browser warnings. From the security team’s perspective, blocking storage.googleapis.com at the network level is effectively impossible. Google’s services are so deeply embedded in enterprise workflows — through Google Workspace, vendor portals, client-facing tools, and partner integrations — that blocking the domain would disrupt normal business operations.

This is not a problem that can be solved purely with technical controls at the perimeter. Domain reputation, IP reputation, and TLS certificate validation are all bypassed by design when the malware is genuinely hosted on Google’s infrastructure.

The Only Scalable Mitigation: User Education

The core defensive lesson is straightforward but requires sustained reinforcement:

A trusted domain hosting a file does not make that file trustworthy.

Users need to understand that Google, Microsoft, Dropbox, and Amazon can all be used as unwitting hosts for malicious content. The presence of a recognisable brand in the URL is not an indicator of safety. Specific training points to reinforce include:

• Do not download executable files, archives, or scripts from links in unsolicited emails, even if the download URL appears to belong to a trusted provider.
• Verify file requests through a separate communication channel before downloading.
• Report unexpected download prompts to the security team immediately.

The Campaign’s Technical Mechanics: VBScript, JAR Files, and Houdini

The Menlo Security research described a campaign that used VBScript and JAR files (sometimes delivered as ZIP archives) to download and execute a malicious payload. The payload was assessed to be related to the Houdini malware family, a remote access trojan (RAT) first documented around 2013.

A few technical observations are worth noting for defenders:

• VBScript execution: VBScript runs on Windows systems via Windows Script Host (WSH). It has no legitimate use on most modern enterprise workstations and should be disabled. Microsoft’s documentation and guidance from vendors such as Trend Micro describe disabling WSH as a straightforward registry change that eliminates this attack surface entirely.
• JAR file execution: JAR files require a Java Runtime Environment (JRE) to execute. If your organisation has workstations with Java SE installed and no documented business requirement for it, this represents unnecessary attack surface. Any system that has been exposed should be treated as potentially compromised and rebuilt from a clean image rather than simply having Java uninstalled post-incident.
• Cross-platform claims: The Menlo report suggested this campaign represented a rise in “cross-platform malware.” In practice, VBScript is a Windows-only technology, so the cross-platform framing requires scrutiny (see review notes below).

Actionable Hardening Steps for Security and DevOps Teams

Regardless of the specific campaign, these hardening measures reduce exposure to this class of attack:

1. Disable Windows Script Host on endpoints where VBScript has no legitimate use. This prevents VBScript and JScript from executing outside of approved contexts.
2. Remove or restrict Java from workstations. If Java is required for a specific application, consider application whitelisting to prevent arbitrary JAR execution.
3. Deploy application whitelisting so that only approved executables can run, regardless of where they are downloaded from.
4. Implement email gateway controls that strip or sandbox attachments and flag links pointing to cloud storage downloads.
5. Use a web proxy with SSL inspection to inspect encrypted traffic to cloud storage endpoints and detect anomalous download behaviour.
6. Train users regularly on the specific risk that legitimate-looking URLs and padlock icons do not guarantee content safety.
7. Monitor for RAT indicators: Remote access trojans like Houdini establish persistent outbound connections. Network monitoring for unusual outbound traffic patterns, particularly long-lived connections to unexpected destinations, can surface active infections.

The Broader Threat Landscape Context

The Menlo report’s accompanying commentary suggested that botnets would decline as RAT-based attacks increased. This prediction deserves some scepticism. The proliferation of poorly secured Internet of Things (IoT) devices continues to provide attackers with enormous pools of botnet fodder. Separately, large-scale router compromise campaigns — such as the VPNFilter campaign that affected an estimated hundreds of thousands of routers — demonstrate that botnet infrastructure remains a live and evolving threat, not one in decline.

RAT-based attacks and botnet-based attacks are not mutually exclusive. The more accurate framing is that cloud-hosted delivery mechanisms lower the barrier to entry for RAT deployment, adding a layer to the threat landscape rather than displacing existing techniques.

Summary

Cloud platforms offer attackers the same operational benefits they offer legitimate businesses: low cost, high reliability, and built-in trust. Security teams cannot blacklist their way out of this problem. The combination of aggressive endpoint hardening (disabling VBScript, removing unnecessary runtimes like Java), network-layer inspection, and sustained user education represents the most practical defence against campaigns that abuse legitimate cloud infrastructure for malware delivery.