Ransomware in the Cloud: Breaking Down The Attack Vectors

Ofir BalassianoOfir Balassiano
table of contents
Ransomware in the Cloud: Breaking Down The Attack Vectors

The number of ransomware attacks, especially those involving cloud assets such as Amazon S3 buckets and Azure Storage accounts, has increased in recent years. Nevertheless, most organizations do not act either to reduce these attacks or to lower their impact. Our research shows, for example, that only 31% of S3 buckets have versioning enabled, an essential for data recovery, while just two-thirds of sensitive buckets have logging enabled, a prerequisite for detection.

In the battle against ransomware, understanding your enemy is half the victory. By diving into the minds of attackers and evaluating the pros and cons of their techniques, we can anticipate their next moves… and fortify our defenses.

In this blog, we cut through the theory and delve into the practical aspects of ransomware attacks within cloud environments. Drawing from real-world data and simulations, we explore these attack vectors and evaluate both their prevalence and potential impact to align our defense strategies and chart out the most effective approaches.

By closely examining the modus operandi of ransomware attackers from their point of view, we can understand them better, predict when each technique might occur, and nip it in the bud.

Ransomware Techniques

Ransomware attacks in the cloud are carried out via four main techniques – data deletion, override, re-encryption, and disable key as shown in the diagram below.

Cloud Ransomware Flow Diagram

Let’s first dive into the nuts and bolts of each technique, including providing the relevant CLI and required permissions, as well as understanding its advantages and limitations from the attacker’s perspective .

1. Data Deletion

1a. Direct data deletion

During a ransomware attack, the attacker may decide to delete data in order to gain exclusive control over it. By understanding the mechanisms behind this attack, we can develop more effective counter-strategies.

CLI Command

Required Permission

  • ‘s3:DeleteObject’


  • Speed: deletion of 1,000 objects in 2 seconds
  • Does not require permission to list objects in the bucket


  • Ineffective if versioning is enabled (see more below), since only the current version is removed

1b. Indirect deletion using life cycle policy

Alternatively, an attacker can manipulate bucket life-cycle rules by setting them to delete objects automatically after a certain period and by bypassing the need for direct deletion permissions.

CLI Command

Required Permission

  • ‘s3:PutLifecycleConfiguration’


  • Stealth: does not require permissions to access objects directly
  • Helps evade detection, since the attacker does not access the objects themselves


  • Time-consuming: takes at least one day to initiate deletion

2. Object Override

In this technique, attackers create a blank file and systematically replace every object in the bucket, in effect to make the data unusable. 

CLI Command

Required Permissions

  • ‘s3:PutObject’: to overwrite objects within the bucket
  • ‘s3:ListBucket’: to list all objects that need to be overwritten


  • Does not require ‘s3:DeleteObject’


  • Ineffective against buckets with enabled versioning, since only the most recent version is modified
  • Requires additional ‘s3:ListBucket’ permission, which is less common

3. Object Encryption / Re-encryption 

3a. Encrypt / Re-encrypt objects with local encryption key

Re-encryption of all objects in the victim’s bucket also involves multiple techniques, including reading every file in the bucket and re-uploading it – this time with a ”local” encryption key. In this way, the encryption key is the only way the victim can decrypt the files.

CLI Command

Once a customer key encrypts the object, the victim will receive again the following error when trying to access the encrypted files:

Required Permissions

  • ‘s3:ListBucket‘: to list and prepare files for re-encryption
  • ‘s3:GetObject‘: to retrieve files
  • ‘s3:PutObject‘: to upload the re-encrypted files back to the bucket


  • Speed: like other methods, re-encrypting a large number of objects can be executed quickly
  • Storage-free attack: the attacker needs to store only the encryption key, not the files


  • Ineffective if versioning is enabled, since only the latest version of file is affected by the new encryption

3b. Encrypt / Re-encrypt objects with remote KMS

Another option is to re-encrypt all the files with a KMS stored in a remote account, which, in this case, is in the attacker's remote account.

CLI Command

Required Permissions

  • ‘s3:ListBucket‘: to list and prepare files for re-encryption
  • ‘s3:GetObject‘: to retrieve the files
  • ‘s3:PutObject‘: to upload the re-encrypted files back to the bucket
  • ‘kms:GenerateDataKey’


  • Speed: deletion of 1,000 objects in 2 seconds
  • Storage-free attack: the attacker needs to store only the encryption key, not the files


  • Ineffective if versioning is enabled, since only the latest version of files is affected by the new encryption

4. Disable Key

4a. Schedule key for deletion

Data encrypted with KMS can be decrypted only with that KMS; without the key, the data is inaccessible. Attackers can choose to schedule key deletion for the KMS to make the data inaccessible. It is not possible to delete the key immediately, but it must be scheduled at least seven days in advance.

In a prod environment with dozens of keys, it is possible for such a case to go undetected for 7 days, which will lead to key deletion and data loss.

CLI Command

Required Permission

  • kms:ScheduleKeyDeletion


  • Effective for non-current versions if versioning is enabled
  • Storage-free attack: the attacker needs to store only the encryption key, not the files
  • Stealth: does not require permissions to access objects directly
  • Helps evade detection, since the attacker does not access the objects themselves


  • Time-consuming: takes 7 days to complete

4b. Delete key material

A more sophisticated ransomware tactic involves disabling the key material in S3 buckets that are encrypted with external keys. Unlike AWS-managed keys that have a mandatory delay before deletion, external key material can be deleted immediately, thereby leaving the encrypted data inaccessible.

The attacker’s strategy is to remove access to the encryption key itself rather than manipulate the data directly.

CLI Command

Required Permission

  • kms:DeleteImportedKeyMaterial


  • Data that is encrypted becomes inaccessible almost instantly as a result of this rapid process
  • When deleting key material from versioned buckets, all files encrypted together with it are affected
  • Stealth: does not require permissions to access objects directly
  • Helps evade detection, since the attacker does not access the objects themselves


  • Is dependent on obtaining specific permissions (kms:DeleteImportedKeyMaterial), which is not so common for the attacker 

Complementary Ransomware Steps – Deletion of All Non-Current Versions

If versioning is enabled on the asset, the attacker needs to make all non-current versions unavailable for the victim in order to complete the attack on the victim’s bucket. The aforementioned techniques do not handle the remaining versions.

CLI Command (to delete remaining backups)

Required Permissions

  • ‘s3:DeleteObjectVersion’: to delete non-current version of an object
  • ‘s3:ListBucketVersions’: to list all non-current versions of an object


  • None


  • Time to complete depends on number of non-current objects

Comparative Analysis of Ransomware Techniques

After exploring the individual ransomware attack scenarios, comparing them across similar conditions helps us understand their relative levels of danger and efficacy. 

Before doing that, however, let’s point out two key parameters that help us make a proper comparison.

Dimension of time 

The time dimension is very important in ransomware attacks, because it defines the window of opportunity to detect and respond to the attack. By measuring the speed of the ransomware techniques in handling varied quantities of data, we can rank their relative strength.

Ransomware Speed Variation across Different Data Sizes

The strength of the direct deletion, override, and re-encryption techniques drops as the quantity of data increases. In contrast, techniques that are considered less efficient for small quantities of data ,such as schedule for deletion and indirect deletion using life cycle policy, get relatively stronger as the quantity of data increases.

Efficiency of attack execution: CLI vs. Python

Timing is critical in cloud ransomware scenarios: the time required to delete, write, or encrypt data can span hours, or even days, in the cloud. This window of time is not only an operational concern, but also a critical factor regarding the efficacy of attacks and the potential defenses against them. Therefore, when making our evaluation, we examined the execution speed of ransomware techniques via CLI and Python scripts on S3 buckets with and without versioning.

The timing for the various actions are illustrated in the following table.

Comparing the Speed of Ransomware Techniques using CLI vs. Python

Our findings yet again highlight the need for security teams to reduce the mean time to detect (MTTD) and mean time to respond (MTTR) for attacks on their cloud infrastructure.

Comparison summary

The table below summarizes our findings based on a comparison of the speed, impact, and reversibility of each method. It not only highlights the most risky techniques, but also underscores the importance of timely detection and response strategies in mitigating potential damage.

When examining the table, it becomes evident that quick and irreversible techniques pose the greatest risk. Some techniques are stealth and affect non-current versions, while others are not. In any case, every technique requires reading the data. As a result, encryption at rest is one of the best protection mechanisms against ransomware in the cloud.

Protecting Against Ransomware

Ransomware can be devastating, but there are actions you can take to neutralize the various techniques and to reduce the effectiveness of such attacks. 

  1. Enable versioning: This ensures that when one object is re-encrypted with a new KMS, the older version of the object encrypted with the old KMS will not be lost forever. It also increases the time it takes to complete the attack.
  2. Enable MFA deletion when enabling versioning on the bucket: When a bucket has MFA delete enabled in its versioning configuration, the bucket owner is required to include the x-amz-mfa request header in any request to delete a version of an object permanently or to modify the bucket’s versioning state.
  3. Use delete protection. As a secondary protection mechanism, we can use the S3 Object Lock on top of S3 versioning to prevent data from being deleted or overwritten.
  4. Use KMS with key material managed by AWS rather than that managed externally or located in a key store like CloudHSM. KMS that is managed by AWS cannot be deleted immediately: it requires scheduling at least 7 days in advance, which gives you enough time to respond to an attack (according to IBM research, average detection time is more than 200 days).
  5. Use KMS with access policy to allow specific principals to read the data. Attackers who cannot read the data will not be able to carry out a ransomware attack. Be sure to put appropriate permissions in the policy as a second layer of security to access the objects in the S3 bucket.
  6. Remove powerful permissions on S3 buckets like ‘s3:PutLifecycleConfiguration,’ ‘s3:PutEncryptionConfiguration,’ and ‘s3:DeleteObjectVersion’ to reduce the attack surface. 
  7. Remove powerful permissions on KMS like ‘kms:DeleteImportedKeyMaterial’ and ‘kms:DeleteCustomKeyStore’ to reduce the attack surface.

Enforce separation of duties. Our recent ‘State of data security research’ shows that all principals with admin permissions also have consumer privileges. Use the divide-and-conquer approach to separate the permissions required to carry out a full attack by one principal.

[download infographic cheat sheet]

The Stats: How Vulnerable Are You?


  • 10% of encrypted buckets utilize CMK for enhanced security 
  • 4% of the 10% above are remotely managed
  • 72% of remote CMK buckets are not actively monitored

Data Protection Measures 

  • 31% of buckets have versioning enabled, which is essential for data recovery 
  • 67% of sensitive buckets have logging enabled
  • 1% of the buckets have object lock, which is crucial for preventing data tampering

These figures reveal significant gaps in current data security practices, highlighting areas where immediate improvements are necessary to bolster defenses against ransomware attacks.

Early Detection and Response Tactics

Knowing how much time it takes to perform a ransomware attack on your data is the first step to choosing a prevention and detection strategy. But you will also need to enable logging of data events on your S3 buckets.

Scenario 1: Versioning and MFA deletion are disabled

In a bucket whose versioning and MFA deletion are not turned on, the first sign of a ransomware attack will be multiple attempts to read / write files from the bucket. The detection requires critical mass before it is deemed as an attack, and by nature, detection will raise an alert only after the attack has begun and the data has been exfiltrated or deleted.

Scanrio2: Versioning and MFA deletion are enabled

If the bucket is protected with versioning and MFA delete, preliminary signs of an attack could include either removing the configuration of MFA deletion, versioning or changing bucket encryption configuration. These signs help us become aware of the attack before it impacts the data. And as long as it is advancing, we will receive additional signs that something is happening that requires our attention. 

As shown above, the presence of non-current versions in a versioned S3 bucket adds complexity to a ransomware attack. This means that attackers have to navigate through additional steps to compromise the data, which in turn, provides you with a longer time frame to detect and counteract the attack before any significant data loss occurs.


Our blog examines various ransomware tactics in the cloud and suggests preventive measures to highlight the role data security posture management (DSPM) plays in safeguarding sensitive data. Dig’s DSPM solution helps you identify all the data assets in your environment that are at risk of ransomware (see above “How to protect your data”). 

In addition, Dig’s data access governance (DAG) capabilities highlight all identities with relevant permissions to carry out a ransomware attack.

Dig’s data detection and response (DDR) tools provide the real-time detection needed to dramatically reduce your mean time to detect (MTTD) and mean time to respond (MTTR) to such attacks.

Stay safe and secured,

Dig Security


No items found.

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed consectetur do eiusmod tempor incididunt eiusmod.