In recent months, two high-profile malware campaigns have abused popular public cloud services to execute attacks...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
on enterprises. Specifically, the campaigns used Dropbox and Google cloud servers as command-and-control infrastructure, which helped the attack traffic to appear legitimate. In both cases, the campaigns were discovered by third-party security vendors (zScaler and Elastica) and not the cloud provider itself. How did attackers manage to abuse these public cloud services without the providers noticing?
The history of cloud malware
First, it's important to note that we've seen this movie before. In fact, numerous cases of cloud malware have been reported over the past 10 years, affecting a number of different cloud providers. One of the most well-documented cases of cloud malware attacks occurred in 2009, when Amazon's EC2 services were found to be hosting numerous instances of the infamous Zeus malware. In fact, some industry sources estimate up to 80 unique cases of EC2-hosted malware (including Zeus) between 2007 and 2009, with many EC2 instances hosting command-and-control servers. In 2011, researchers at Kaspersky found the SpyEye banking Trojan hosted on Amazon's S3 storage service.
At the beginning of 2014, managed security services firm Solutionary published its quarterly threat report for Q4 2013, which stated that cloud services like Google and Amazon -- with AWS called out explicitly -- host numerous instances of malware, primarily from U.S.-based cloud servers. In June 2014, researchers at Trend Micro described a unique case of a targeted attack against a government agency where the malware (the PlugX Trojan) fetched its command-and-control instructions from Dropbox. This most recent campaign leveraged Dropbox once again, as well as Google cloud servers, to host both command-and-control servers and the instruction sets for cloud malware already installed in target environments.
Understanding cloud malware attacks
Why use cloud provider servers for hosting malware and malicious instructions? The most prevalent reason is one of trust -- by hosting malicious content and services in well-known cloud service provider environments, attackers can ensure a higher probability that their traffic and sites won't be blocked by domain, as most organizations won't arbitrarily shun all Google or Amazon traffic, for example. Attackers also like taking advantage of the cloud for the same reason most enterprises do: cost-effective and scalable computing capabilities.
How are the attackers getting in? In some cases it seems as though the attackers are setting up legitimate customer accounts, often using stolen payment methods to do so. This is the easiest way to get started in the cloud for attackers with resources, although they may need to rotate payment methods frequently. In other cases, attackers are hijacking accounts and sites that are already in use by tenants, turning them into unwilling participants in their cloud malware distribution and control schemes. Many organizations have orphaned accounts still active in cloud provider environments, and simple account hijacking is likely the easiest way in for a determined botnet operator.
This leaves the question of why the cloud providers didn't detect the malware or malicious behavior, and the answer reflects the harsh nature of many cloud services contracts -- the cloud service provider isn't watching your deployed assets. Infrastructure as a service providers like Amazon and Google do not monitor tenants' systems once they have been deployed successfully, and watching for all evidence of command-and-control traffic is likely prohibitive given the size and scale of the vendors listed. Even in the case of Dropbox, where malware fetched instructions or initial malicious "dropper" applications from Dropbox accounts, the retrieval process would not likely have set off any alarms.
What can be done about cloud malware?
Cloud providers aren't likely to start paying closer attention to this type of activity in the near future, sadly. The responsibility is on the customers to carefully monitor and control all activity within their cloud infrastructure, as well as the traffic coming from our environments for cloud malware protection. Set up logging and event monitoring for all cloud-based assets, and keep a close eye on all accounts set up to administer your cloud environment. All cloud service provider traffic to and from our internal assets should be monitored, too, and any unusual patterns of communication should be closely scrutinized. Also, ensure that only approved cloud providers are able to communicate with internal systems, if possible, by blocking all traffic you shouldn't see. These basic steps will improve enterprises' overall cloud security posture and also reduce the chances that their cloud instances will be used by threat actors.
Learn what really works for daily event log monitoring
Find out how to assess the risks of cloud malware
Discover the benefits of cloud-based automated malware analysis tools