Real-World Cloud Attacks: The True Tasks of Cloud Ransomware Mitigation

In Part 1 of our tales of real-world cloud attacks, we examined real-world examples of two common cloud attacks. The first starting from a software-as-a-service (SaaS) marketplace, demonstrating the breadth of potential access vectors for cloud attacks and how it can enable lateral movement into other cloud resources, including a company's AWS environment. The second cloud attack demonstrated how attackers take over cloud infrastructure to inject cryptominers for their profit.

As we have witnessed, more attacks have moved onto the cloud, so it was only a matter of time before ransomware attacks did, too. Let's look at two scenarios where attackers leveraged ransomware to gain profits, and how unique cloud capabilities helped victims avoid paying the ransom.

MongoDB Ransomware Demand Mitigated

The first case (or rather cases, as this attack has appeared numerous times) is the notorious MongoDB ransomware, which has been ongoing for years. The attack itself is simple— attackers use a script to scan the internet (and now, common cloud vendor address spaces) for hosts running MongoDB exposed to the internet. The attackers then try to connect to the MongoDB with the empty admin password. If successful, the attack erases the database and replaces it with a double ransomware note: pay, and your data will be returned; don't pay, and your data will be leaked.

Intervention was necessary to address the second part of the extortion scheme: data leakage. Luckily, the company had data backups, so recovery was easy, but the database contained considerable amounts of personally identifiable information (PII), which, if leaked, would be a major crisis for the company. This forced them into the position of either paying a hefty ransom or dealing with the press. MongoDB default logging, unfortunately, cannot provide a definitive answer regarding the data accessed, as not all potential types of data collection commands are logged by default.

This is where the cloud infrastructure became an advantage. While MongoDB may not log every command, AWS logs the traffic going in and out of servers, because it charges for network costs. Correlating the network traffic going out of the attacked server with the times when the attackers were connected to the compromised MongoDB server provided proof that the data could not have been downloaded by the attackers.

AWS traffic log over 10 day period. The marker represents the incident time. Source: Mitiga

This allowed the company to avoid paying the ransom and ignore the threat. As expected, nothing further was heard from the attackers.

Mitigating Ransomware in a Cloud Environment

Another company experienced an attack on its main servers running on AWS EC2, where it was hit by a ransomware Trojan, not unlike those seen on on-premises servers. As often occurs these days, this was another double-extortion ransomware attack and the company needed help dealing with both issues.

Luckily, due to the company's cloud architecture and preparedness, there were AWS snapshots of the environment going back 14 days. The attackers were unaware of the snapshots and had not disabled them in their attack. This allowed the company to immediately revert to the day before the data encryption, resolving the first part of the attack with minimal effort. That still left two challenges to deal with: the potential data leak and the eradication of the attackers from the environment.

To address these challenges, there was a full investigation of the breach, which turned out to be quite complex due to the hybrid nature of their environment. The attackers compromised a single account with limited access, used by an IT person. They then identified a legacy on-premises server where that individual was an admin and used it to take over the Okta service account, allowing privilege escalation. Finally, using a decommissioned VPN service, they were able to hop to the cloud environment. Using the elevated privileges, they took over the EC2 servers and installed the malware.

The investigation yielded two significant findings. The first was the attack timeline. It showed that the compromise of all hosts occurred before the earliest snapshots were taken, indicating that the recovered servers were compromised and could not be used. New servers were installed, the data was transferred to them, and the original affected servers were purged.

The second finding was even more surprising. Malware analysis identified that the attackers used rclone.exe to copy the files to a remote location. The connection credentials were hardcoded in the malware, so the company was able to connect to the same location, identify, and remove their files, eliminating the attackers' access to the files, eradicating the extortion aspect of the attack.

Cloud Breaches Are Here to Stay

As these real-life scenarios reveal, attackers are infiltrating the cloud and cloud breaches are on the rise. It's time for organizations to prepare for cloud incidents. Cybercriminals are leveraging cloud capabilities in attacks, and you should use them, too, to protect your organization and prevent a crisis from hitting the headlines.