To most security professionals, the word “ransomware” has traditionally been associated with attacks targeting on-premises Active Directory: we conjure images of corporate environments being encrypted by centrally proliferated ransomware. This association is far from unreasonable: for years, ransomware attackers largely repeated tried-and-true playbooks, targeting similar environments over and over again. Until recently, ransomware has been predominantly an on-premises phenomenon.
Might this be changing? Though cloud ransomware is still an evolving pattern these attacks are beginning to emerge in the wild. In its April 2023 Threat Horizons report, the Google Cybersecurity Action Team identified an instance of cloud ransomware targeting Google Cloud SQL instances. Incident response consultancy Invictus detailed another cloud ransomware attack in a blog post in which attackers moved laterally through the AWS control plane to access sensitive data in S3.
Although the goals of ransomware, encryption, and exfiltration/extortion, remain the same, the tactics used to achieve these goals differ in the cloud as compared to in traditional environments. Understanding these differences is the first step for any organization looking to protect its cloud environment against emerging cloud ransomware threats.
So how is cloud ransomware different?
The cloud offers built-in, decentralized backup mechanisms - for example, automating backup snapshots of managed databases is simple and common. This provides defenders with added protection, but also provides attackers with a novel attack vector for exfiltration and extortion
Identity is far more central - access to data generally requires access to an appropriately-permissioned role. This provides defenders with increased protection against attacks, but also means that attackers with the right permissions can more easily disguise their actions as legitimate activity. The recent MGM ransomware attack is an illustrative example of this focus on identity: there, the ALPHV/BlackCat ransomware group claimed to have gained super administrator privileges in the corporate Okta environment, as well as global administrator privileges in MGM’s Azure tenant.
Cloud environments are more standardized across organizations, and attackers can more easily translate attack techniques from organization to organization. This increases the speed of cloud attacks, giving defenders less time to react.
Clearly, the cloud offers new opportunities both for defenders to stay secure, and for attackers to gain new footholds into enterprise environments. In this blog, we’ll detail some of our research on cloud ransomware tactics, and provide guidance on how these techniques can be stopped.
Cloud Ransomware: Attacker Tactics & Defense Techniques
To keep things manageable, we’ll focus on tactics relating to the two most common enterprise cloud environments: AWS and Azure.
Data destruction & encryption
This first set of tactics relates to direct destruction or encryption of cloud data.
AWS - Overwriting S3 Data with Encrypted Copies
The Technique: An attacker with read and write access to AWS S3 can simply read all relevant files, encrypt them with an encryption key of their choosing, and overwrite the original file with the result.
How to Detect It: Ensure S3 data event logging is enabled in AWS CloudTrail. You should monitor for:
Objects being copied onto themselves
High volume data access requests
AWS - Encryption of Data Using an External KMS Key
The Technique: An attacker can create an AWS KMS key in their own AWS account, grant cross account access to the victim’s account, and use that key to encrypt data in the victim’s account much faster than using a local key
How to Defend Against It: Monitor data event logs for suspicious events. In particular, organizations should prevent or at least closely monitor any encryption using external keys.
Azure - Encrypt Data using Azure Key Vault
The Technique: An attacker can create a new Azure Key Vault with a very short retention window (the minimum is 7 days), create a new key, and save a local copy of the key. The attacker can then use that key to encrypt data in a victim storage account and delete the Key Vault
How to Defend Against It: Ensure your organizations collect and monitor Key Vault audit logs - these are not enabled by default. You should monitor for the creation of unusual new key vaults - especially those configured with short retention periods. You should also monitor the key vault logs for anomalous key export events, which could indicate this technique is being used.
Azure - Cross-subscription data encryption
The Technique: Creation of a new subscription in Azure is a surprisingly effective defense evasion technique. Subscription creation is not clearly logged, meaning that attackers with the relevant permissions can create new a subscription within the tenant to establish an unmonitored base of operations. Attackers can then move laterally and escalate privileges to execute the attack with a lower chance of detection.
How to Defend Against It: Ensure you have the relevant infrastructure in place to monitor for unusual subscription creation events.
Access denial to encryption keys
The cloud also offers a second, more unique attack path beyond direct encryption of data. Most cloud data assets are encrypted at rest by default: though encryption at rest is an obvious best practice, it also means that attackers can deny organizations access to their data by simply denying them access to their own encryption keys.
These methods are particularly malicious for two related reasons:
They are typically significantly faster than direct destruction or encryption. Instead of a large number of encryption operations, some of these techniques can be accomplished with a single API call
With increased speed comes increased difficulty and urgency for detection: organizations will need to detect and respond to these attacks earlier in the attack chain
AWS - KMS Key Deletion
The Technique: An attacker with the relevant permissions can simply download a KMS key used by an organization to encrypt data and delete the original version housed in the victim’s cloud account. The organization’s data will be rendered unreadable by their own key
How to Defend Against It: Ensure your KMS keys have lean access permissions, and closely monitor KMS logs for changes to sensitive keys. Alerting based on these events can be prioritized based on the sensitivity of the assets which the KMS keys are used to protect. If worse comes to worst, AWS offers KMS key recovery services, but this process is often lengthy and will cause downtime: as such, organizations should ensure that KMS keys are sufficiently monitored to detect and prevent these kinds of attacks before impact is achieved.
AWS - KMS Key Policy Access Denial
The Technique: An attacker can alter an AWS KMS key access policy to deny access to the victim. The attacker can either save a copy of the key prior to policy change, or allocate an elastic IP in the attacker’s own account and allow access only from that specific IP (this technique was first described by Spencer Geitzen at the 2020 DEFCON Cloud Village)
How to Defend Against It: Monitor AWS CloudTrail for creation of keys or alteration of key policies. Importantly, you should ensure that your team is prepared to respond immediately when sensitive key policies are changed. This tactic is especially dangerous because it eliminates the large amounts of read and write activity that makes the above techniques take more time, meaning that the entire attack can be executed with a single API call.
Azure - Key Vault Key Deletion
The Technique: An attacker can download a key from an Azure Key Vault and delete the cloud version, leaving the organization locked out.
How to Defend Against It: Azure enforces a minimum retention period of 7 days for deletion of Key Vault keys, meaning organizations will have a detection window in which they can recover the deleted key. Organizations should monitor for not only unusual key downloads, but also attempts (successful or unsuccessful) to delete keys or grant permissions to delete keys. Deleting a key requires specific privileges that should not be available to most users, and teams investigate and respond as soon as possible when these events occur to ensure the keys are recovered before data is lost.
Summary
As organizations continue to shift workloads to the cloud, attackers will inevitably follow. No longer is ransomware synonymous with on-premises Active Directory, and cloud ransomware is a new emerging threat.
All major cloud providers provide defenders the means to protect themselves. With easily enabled versioning and automated backup functionality, in some ways defenders’ lives have been made easier. But attackers have gotten new opportunities as well, and the cloud control plane allows for faster, more automated attacks that circumvent traditional ransomware defenses. The environment is different, and organizations need to understand these differences to detect and respond to cloud ransomware effectively.
Gem’s cloud detection and incident response platform continuously monitors your entire cloud estate (AWS, Azure, GCP) and identity provider platforms (Okta, Azure AD, Google Workspace) for suspicious TTPs like the ones described above. And our cloud security research team is constantly adding new ones to the library.
Click here to learn more about how the Gem platform significantly reduces the time to detect, investigate, and contain ransomware and other cloud attacks.
Comments