{
	"id": "2bc3a6aa-b6f3-435a-a1e3-cdae9cde7392",
	"created_at": "2026-04-06T00:15:04.505841Z",
	"updated_at": "2026-04-10T03:21:28.569002Z",
	"deleted_at": null,
	"sha1_hash": "b281b95bb7fa79d1484da607613ce7179ea4ecce",
	"title": "S3 Ransomware Part 1: Attack Vector",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 358758,
	"plain_text": "S3 Ransomware Part 1: Attack Vector\r\nBy Spencer Gietzen\r\nPublished: 2019-06-10 · Archived: 2026-04-05 15:01:04 UTC\r\nThis is part one in a two-part series on S3 Ransomware. You can find Part Two: Prevention and Defense here.\r\nIntroduction to the Attack Vector\r\nThrough our cloud security research, we at Rhino Security Labs developed a proof of concept “cloud\r\nransomware” using KMS to encrypt objects within Amazon S3 buckets of a compromised AWS account.\r\nRansomware is when an attacker gains access to a victim’s system and encrypts the sensitive data on it. This is\r\naccompanied by a threat to delete or publicly release the data if the victim does not give payment within a certain\r\ntime frame. Typically, these attacks are targeting servers, workstations, and similar setups, but as with many\r\nattacks, there is a “cloud-equivalent”.\r\nS3 Ransomware can be very damaging, and our research and blog post do not aim to assist attackers by any\r\nmeans. For this reason, only a slow proof-of-concept script will be released with this blog, so defenders are able to\r\ntest their defenses. For the defenders and blue teamers, we created a second part to this post in which we discuss\r\nhow to prevent and defend against S3 ransomware.\r\nAmazon S3 and AWS KMS\r\nFor those unfamiliar, Amazon Simple Storage Service (Amazon S3) is a robust static-file hosting service offered\r\nthrough Amazon Web Services. According to Amazon, S3 can be used to “store and protect any amount of data for\r\na range of use cases, such as websites, mobile applications, backup and restore, archive, enterprise applications,\r\nIoT devices, and big data analytics”. At a high level, S3 consists of “buckets” and “objects”, in which objects are\r\nfiles that are stored in a bucket.\r\nAWS Key Management Service (AWS KMS) is essentially a managed encryption key service offered by AWS.\r\nAmazon defines it as a service that “makes it easy for you to create and manage keys and control the use of\r\nencryption across a wide range of AWS services and in your applications”.\r\nS3 Buckets\r\nS3 buckets are not automatically server-side encrypted, meaning that without configuration, all files will be stored\r\nin cleartext on Amazon’s servers. Buckets can have a “default” encryption setting that can be used as a fallback\r\nmechanism for when someone/something tries to upload a file without encryption. In that case, the default\r\nencryption method will kick in and ensure the file is not stored in cleartext.\r\nS3 Objects\r\nhttps://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/\r\nPage 1 of 6\n\nIndividual objects can also be encrypted separately from the “default” encryption on the bucket, unless enforced in\r\nthe bucket’s policy. This means that if there was a default encryption method set up on a bucket (or none at all),\r\nthe uploader of a file can decide how to encrypt it on upload, which will override the default setting for the bucket.\r\nKMS Encryption\r\nAWS KMS integrates with S3 object encryption, in that you can specify a particular KMS key to encrypt an object\r\nin a bucket. In that case, a user who tries to view a file in S3 would both need the “s3:GetObject” permission on\r\nthe specific S3 object and the “kms:Decrypt” permission on the specific KMS key. Proper implementation of a\r\nKMS key policy can prohibit attackers from reading sensitive files in S3. If an attacker escalates their access and\r\ngains the “s3:GetObject” permission, they still may not be able to read files in S3 because they don’t have decrypt\r\npermissions on the appropriate KMS key.\r\nKMS keys can also be used cross-account, so if an attacker gains access to your S3 bucket, they may be able to\r\nencrypt your objects with a cross-account KMS key that only provides you with “encrypt” permissions. Because\r\nyou don’t control the KMS key that was used to encrypt your files, that means you can’t view your own files.\r\nThe Attack Path\r\nAs part of this research, we wrote an advanced tool for performing ransomware attacks against S3 buckets and\r\nobjects. This tool handles a variety of options and configurations in the target environment, and was written\r\nspecifically for speed. However, because our research and blog post do not aim to assist attackers, we will not be\r\nreleasing the tool for this attack. Instead, a script can be found below in the “Testing Your Buckets” section that is\r\ndesigned to assist defenders and blue teamers in protecting against this attack.\r\nAttack Walkthrough\r\n1. Attacker creates a KMS key in their own “personal” AWS account (or another compromised account) and\r\nprovides “the world” access to use that KMS key for encryption. This means that it could be used by any\r\nAWS user/role/account to encrypt, but not decrypt objects in S3.\r\n2. Attacker identifies a target S3 bucket and gains write-level access to it, which is possible through a\r\nvariety of different means. This could include poor configuration on buckets that expose them publicly or\r\nan attacker gaining access to the AWS environment itself. Typically attackers would target buckets with\r\nsensitive information, such as PII, PHI, logs, backups, and more.\r\n3. Attacker checks the configuration of the bucket to determine if it is able to be targeted by ransomware.\r\nThis would include checking if S3 Object Versioning is enabled and if multi-factor authentication delete\r\n(MFA delete) is enabled. If Object Versioning is not enabled, then they are good to go. If Object Versioning\r\nis enabled, but MFA delete is disabled, the attacker can just disable the Object Versioning. If both Object\r\nVersioning and MFA delete are enabled, it would require a lot of extra work to be able to ransomware that\r\nspecific bucket.\r\n4. Attacker uses the AWS API to replace each object in a bucket with a new copy of itself, but this time,\r\nit is encrypted with the attackers KMS key.\r\n5. Attacker schedules the deletion of the KMS key that was used for this attack, giving a 7 day window to\r\ntheir target until the key is deleted and the data is lost forever.\r\nhttps://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/\r\nPage 2 of 6\n\n6. Attacker uploads a final file such as “ransom-note.txt” without encryption, which instructs the target on\r\nhow to get their files back.\r\nThe following screenshot shows an example of a file that was targeted for a ransomware attack. As you can see,\r\nthe account ID that owns the KMS key that was used to encrypt the object (7**********2) is different than the\r\naccount ID of the account that owns the object (2**********1).\r\nThe next screenshot shows what happens when the object owner uses a pre-signed URL to try to view the object.\r\nAccess is denied because even though the object owner has permission to view the object, they don’t have\r\npermission to use the KMS key to decrypt the encrypted object, thus preventing access to it.\r\nhttps://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/\r\nPage 3 of 6\n\nAttack Metrics\r\nTo test this attack and to see the viability of it, we ran Rhino’s internal tool against an S3 bucket that was hosting\r\napproximately 2000 different files of different sizes, totaling about 100 GB of data. To ransomware the entire\r\nbucket (encrypt every individual object) it only took 1 minute and 47 seconds.\r\nTypical CloudTrail logs can take up to 15 minutes to be delivered to an S3 bucket, but in testing, it was found that\r\nCloudTrail S3 data event logs were delivered in approximately 5 minutes. Logs delivering in 5 minutes is much\r\nbetter than 15 minutes, but the problem is that 5 minutes is still too long. Our test above shows that approximately\r\n2,000 files, totaling about 100 GB of data can be ransomwared in as little as 1 minute and 47 seconds, which is far\r\nunder the 5 minute limit. By following those numbers (theoretically—results would be slightly different in\r\npractice depending on the size of the individual files), an attacker can ransomware just over 900 MB of data per\r\nsecond. That means in a 5-minute period, they could ransomware approximately 270 GB of data before you even\r\nhave a chance to see what happened.\r\nThe next thing to consider is how fast you can react once you do see what’s going on. As an example, it could take\r\nyou 5 minutes from the first log delivery to act against an attacker trying to ransomware your data and block their\r\naccess to your environment. At that point, you’re 10 minutes into the attack, which comes out to approximately\r\n540 GB of data. To give some perspective, the following list was calculated based on the data from this “How Big\r\nis a Gig?” cheat sheet from iClick.\r\n540 GB of data, expressed in common file types:\r\n360,000 1.5 MB photos\r\n360 1.5 GB movies\r\n135,000 4 MB songs\r\nhttps://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/\r\nPage 4 of 6\n\nOf course, this is all an estimate and there are many more factors to be considered, but this is to give an idea of\r\nhow much 540 GB of data really is. The list above shows that no matter how fast you respond, the attacker will\r\nstill be able to ransomware a large amount of data. This is why it is extremely important to defend against this\r\nattack as much as possible, in addition to implementing incident response plans.\r\nS3 Ransomware Proof-of-Concept\r\nWe also wrote a simple proof-of-concept script for demonstrating this attack, so that defenders can test it out and\r\nhopefully build detections around it. This script will only work against buckets that have object versioning\r\ndisabled.\r\nThe script, which can be found on our GitHub, does the following:\r\n1. Gathers the first 100 objects in the bucket (or all, if fewer than 100 objects in the bucket)\r\n2. One by one, overwrites each object with itself using the new KMS encryption key\r\nScript Usage\r\nTo use the PoC script, modify the values of “aws_cli_profile”, “bucket_name”, and “kms_key_arn” to match your\r\nenvironment, then run the script with Python 3.6+.\r\nVariables:\r\naws_cli_profile: The AWS CLI profile to use for authentication with AWS (~/.aws/credentials).\r\nbucket_name: The name of the S3 bucket to target.\r\nkms_key_arn: The ARN of the KMS key to use for the attack.\r\nHere’s a screenshot of the script running and its output:\r\nBecause you are specifying the KMS key to use and the S3 bucket to target, you shouldn’t lose access to your data\r\n(such as if a real attacker used their own KMS key on your S3 bucket). To be cautious, though, do not run this\r\nscript against production/important data.\r\nConclusion and Defensive Controls (Part 2)\r\nRansomware is an extremely threatening attack vector that has become more and more popular in recent years.\r\nThe amount of data that an attacker can ransomware in a short period of time is very significant. Attackers\r\ncontinue advancing, so defenders need to stay one step ahead to prevent cloud-based attacks that have traditionally\r\nbeen performed elsewhere.\r\nS3 ransomware can be very dangerous to an organization, but there are a variety of both simple and complex\r\ndefense mechanisms that defenders can put in place to prevent this attack.\r\nThese methods are explained in depth in part two of this post.\r\nhttps://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/\r\nPage 5 of 6\n\nSource: https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/\r\nhttps://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/\r\nPage 6 of 6",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/"
	],
	"report_names": [
		"s3-ransomware-part-1-attack-vector"
	],
	"threat_actors": [],
	"ts_created_at": 1775434504,
	"ts_updated_at": 1775791288,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/b281b95bb7fa79d1484da607613ce7179ea4ecce.pdf",
		"text": "https://archive.orkl.eu/b281b95bb7fa79d1484da607613ce7179ea4ecce.txt",
		"img": "https://archive.orkl.eu/b281b95bb7fa79d1484da607613ce7179ea4ecce.jpg"
	}
}