{
	"id": "3d9f95d5-c8ba-47c6-abae-0b9757a3bda9",
	"created_at": "2026-04-06T00:11:11.404566Z",
	"updated_at": "2026-04-10T03:21:10.685393Z",
	"deleted_at": null,
	"sha1_hash": "4318aa61d488950b078c4f751b1d95cb8eb6f9fe",
	"title": "Cloud Ransomware: Trends \u0026 Defense Strategies",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 513825,
	"plain_text": "Cloud Ransomware: Trends \u0026 Defense Strategies\r\nArchived: 2026-04-05 13:20:23 UTC\r\nBackground\r\nRecently we were engaged by a company after they were targeted by a ransomware attack in their AWS\r\nenvironment. In this blog we want to show you what happened and how we were able to piece together the picture\r\nbased on available logging.\r\nDue to confidentiality we will be using censored screenshots to protect our client’s information. They approved\r\nthe publication of this blog, to prevent other companies from becoming a victim to a similar attack.\r\nAttack overview\r\nThe overall attack activity is mapped to the MITRE ATT\u0026CK steps as shown in the figure below:\r\nIncident timeline\r\nInitial Access\r\nThe threat actor was able to get into the environment due to accidentally exposed long-term credentials. The first\r\nmalicious activity happened outside of the 90-day retention period of CloudTrail. However, based on analysis of\r\nsubsequent events and open-source analysis we were able to determine that a specific access key was used which\r\nwas publicly exposed. Luckily the access key was for an account that only had rights to a specific S3 bucket.\r\nhttps://www.invictus-ir.com/news/ransomware-in-the-cloud\r\nPage 1 of 11\n\nReconnaissance\r\nFollowing the initial access the threat actor performed the following activities for reconnaissance.\r\nMost of the activities are self-explanatory and they are attempts to list other users, buckets and any available\r\naccess keys.\r\nhttps://www.invictus-ir.com/news/ransomware-in-the-cloud\r\nPage 2 of 11\n\nThe more interesting calls are around Quotas the ListServiceQuotas\r\n and GetSendQuota events are related to the AWS\r\nSimple Email Solution (SES) service. We’ve seen that SES is an interesting attack vector for threat actors, because\r\nthey can leverage SES for spamming and (spear)phishing campaigns. Because the access keys that were used for\r\nmaking these calls had limited permissions these calls all resulted in AccessDenied events as shown in an example\r\nbelow.\r\nIn the above example we can see that the treat actor also uses the AWS CLI package on a Windows host and used\r\nthe aws s3 ls command. (reference)\r\nPersistence\r\nThe threat actor attempted to create a number of additional users which is captured in CloudTrail under the\r\nCreateUser\r\n event name. The following user creations were attempted:\r\nroot\r\nadminz\r\ndeploy\r\ns3mize\r\nses-smtp-user.\u003cdate-time-of-creation\u003e\r\nhttps://www.invictus-ir.com/news/ransomware-in-the-cloud\r\nPage 3 of 11\n\nAll of the above actions were again denied. Note that the SES user has a default naming convention which will tell\r\nyou the (attempted) creation date and time. Also the attempt to create a root user is interesting as each AWS\r\naccount by default has a root user. By creating an IAM user with the name root it might be a method to stay under\r\nthe radar. We were unable to find any interesting leads on the other user accounts in public code repositories, but\r\nmaybe someone else knows more.\r\nExfiltration\r\nWhilst most of the attempted activity failed, using the access key the threat actor did have full access to a S3\r\nbucket. The threat actor used this access to exfiltrate data. We were able to confirm this by using the AWS billing\r\ninformation which contained an entry for a GetObject Operation which is recorded when a file is downloaded from\r\na S3 bucket. The AWS billing can be a useful tool for detecting data exfiltration, as any data leaving the AWS\r\nbuckets incurs egress costs that are recorded in the bill.\r\nIf you want to investigate this yourself, use the following process:\r\nGo to AWS billing, then select Cost \u0026 Usage Reports;\r\nSelect the Create a Usage Report link under AWS Usage Report and select the time period of the incident\r\nand the S3 service;\r\nOpen the CSV file in something like Excel and sort by the UsageValue column from large to small;\r\nFilter on DataTransfer-Out or C3DataTransfer-Out Bytes in the UsageTypecolumn;\r\nSearch for the GetObjectOperation which contains file downloads;\r\nYou’ll get one or more entries with aggregated data for a period of 1-hour related to outgoing data\r\ntransfers.\r\nIn case of data being exfiltrated from a bucket you could see something like this in the billing report:\r\nIn the above example, data was transferred out of the EU region from a bucket named Invictus-test-bucket. With this\r\ninformation, we know the time period during which the transfer occurred and the number of bytes that were\r\ntransferred. The billing information doesn’t show where the transfer went, but it can help figure out if data was\r\nexfiltrated, especially if there’s no record of it in CloudTrail.\r\nImpact\r\nAfter the exfiltration of the data the threat actor, disabled bucket versioning, deleted data from several buckets and\r\nleft behind a ransom note.\r\nhttps://www.invictus-ir.com/news/ransomware-in-the-cloud\r\nPage 4 of 11\n\nAs mentioned earlier data events were not audited in CloudTrail for this environment, so we can’t see the\r\nindividual delete events, but the data from the bucket was deleted. It’s also interesting to see what the threat actor\r\ndid before file deletion. The following events were recorded in CloudTrailGetBucketVersioning and PutBucketVersioning.\r\nVersioning in Amazon S3 is a means of keeping multiple variants of an object in the same bucket. You\r\ncan use the S3 Versioning feature to preserve, retrieve, and restore every version of every object stored\r\nin your buckets. With versioning you can recover more easily from both unintended user actions and\r\napplication failures. Source\r\nThe threat actor used the GetBucketVersioningcall to establish whether versioning was enabled for the S3 bucket.\r\nVersioning would’ve allowed our client to easily restore data if it was deleted. In this case the versioning was\r\nenabled, the next call was to change the versioning settings with PutBucketVersioning as shown in the picture below.\r\nhttps://www.invictus-ir.com/news/ransomware-in-the-cloud\r\nPage 5 of 11\n\nWe’ve censored some confidential details such as the bucket and user that performed the action. Important to\r\nknow is that the userName field will contain the user responsible for this action and the bucketName will contain the\r\nbucket for which the versioning was changed. Under Status we can see that the versioning was ‘Suspended’.\r\nRansomware note\r\nThe following ransomware note was left behind in the affected buckets.\r\nCloudTrail events\r\nThe below table highlights the CloudTrail events we’ve come across for this case. You can use these events for\r\nmanual alerting in CloudWatch or setup rules in your SIEM. We’ve added a note on the usability of the events to\r\ndetect threats based on our experience, it might be different for your environment.\r\neventName Phase Note\r\nListUsers Reconnaissance\r\nUseful usage in your environment might vary due to\r\napplications requesting this information\r\nListBuckets Reconnaissance\r\nUseful usage in your environment might vary due to\r\napplications requesting this information\r\nhttps://www.invictus-ir.com/news/ransomware-in-the-cloud\r\nPage 6 of 11\n\neventName Phase Note\r\nListIdentities Reconnaissance Can be noisy due to applications requesting this information\r\nListAccessKeys Reconnaissance Can be noisy due to applications requesting this information\r\nListServiceQuotas Reconnaissance Useful limited to AWS SES so should be rarely used\r\nGetAccount Reconnaissance Can be noisy due to applications requesting this information\r\nGetSendQuota Reconnaissance Useful limited to AWS SES so should be rarely used\r\nCreateUser Persistence Highly useful you should know who is able to create users\r\nGetBucketVersioning Impact Highly useful should be limited usage in your environment\r\nPutBucketVersioning Impact Highly useful should be limited usage in your environment\r\nRecommendations\r\nThe following recommendations are tailored to the prevention, detection, response and recovery of a ransomware\r\nincident in AWS.\r\nEnable a trail in CloudTrail to store data in a S3 bucket which allows for longer data retention;\r\nEnabled CloudTrail for data events, this can generate a lot of events and comes with an added cost,\r\nprioritize based on where your most important data is stored;\r\nLimit the usage of long-term access key, where possible use IAM roles. E.g. use an IAM role for an\r\napplication hosted on EC2 that needs to store data in an S3 bucket and not an access key;\r\nProtect your access keys by regularly rotating them and monitoring for abuse, follow best practices guide\r\nby AWS;\r\nEnable bucket versioning with MFA delete, this will limit the ability to change bucket versioning settings,\r\nbecause MFA is required;\r\nUse AWS Backup for immutable backups, excellent blog by AWS here.\r\nConclusion\r\nRansomware is a threat for all organizations not just limited to on-premise environments. Threat actors will follow\r\nyou to the cloud and a misconfiguration in the cloud is very easy to make with some very serious consequences as\r\nhighlighted in this case.\r\nIndicators Of Compromise (IOCs)\r\nPlease find below a list of IOCs we encountered during this attack.\r\nhttps://www.invictus-ir.com/news/ransomware-in-the-cloud\r\nPage 7 of 11\n\nIndicator\r\nType\r\nIndicator\r\nIP address 139.99.120.65\r\nIP address 139.99.123.180\r\nIP address 139.99.68.31\r\nIP address 164.90.200.10\r\nIP address 193.148.18.59\r\nIP address 198.135.55.189\r\nIP address 198.98.183.38\r\nIP address 212.102.33.34\r\nIP address 64.226.75.246\r\nIP address 95.142.120.45\r\nIP address 95.142.120.58\r\nIP address 95.142.120.75\r\nIP address 114.10.26.42\r\nIP address 114.125.126.25\r\nIP address 120.188.39.58\r\nIP address 125.162.111.178\r\nIP address 140.213.132.181\r\nIP address 140.213.138.160\r\nIP address 140.213.138.35\r\nIP address 158.140.163.5\r\nIP address 180.242.79.14\r\nIP address 180.244.166.155\r\nIP address 182.1.119.185\r\nIP address 182.1.122.169\r\nIP address 182.2.71.61\r\nhttps://www.invictus-ir.com/news/ransomware-in-the-cloud\r\nPage 8 of 11\n\nIndicator\r\nType\r\nIndicator\r\nIP address 36.85.32.120\r\nIP address 36.85.32.129\r\nIP address 36.85.35.148\r\nIP address 36.85.36.50\r\nIP address 36.85.37.4\r\nIP address 36.85.38.180\r\nIP address 36.85.38.45\r\nIP address 36.85.39.118\r\nIP address 36.85.39.21\r\nUser-Agent Boto3/1.13.14 Python/3.9.2 Linux/5.10.0-21-amd64 Botocore/1.20.0\r\nUser-Agent Boto3/1.24.75 Python/3.9.6 Windows/10 Botocore/1.27.75\r\nUser-Agent Boto3/1.24.84 Python/3.10.7 Windows/2012ServerR2 Botocore/1.27.84\r\nUser-Agent Boto3/1.24.84 Python/3.9.7 Windows/10 Botocore/1.27.84\r\nUser-Agent Boto3/1.25.0 Python/3.10.6 Linux/5.15.0-58-generic Botocore/1.28.0\r\nUser-Agent Boto3/1.26.22 Python/3.9.5 Windows/10 Botocore/1.29.22\r\nUser-Agent Boto3/1.26.40 Python/3.11.1 Windows/2012ServerR2 Botocore/1.29.40\r\nUser-Agent Boto3/1.26.51 Python/3.11.1 Windows/10 exec-env/EC2 Botocore/1.29.51\r\nUser-Agent Boto3/1.26.54 Python/3.11.1 Windows/10 exec-env/EC2 Botocore/1.29.54\r\nUser-Agent Boto3/1.26.60 Python/3.11.1 Windows/10 Botocore/1.29.60\r\nUser-Agent Boto3/1.26.64 Python/3.11.1 Windows/10 Botocore/1.29.64\r\nUser-Agent Boto3/1.26.69 Python/3.8.13 Linux/5.15.0-47-generic Botocore/1.29.69\r\nUser-Agent Boto3/1.26.71 Python/3.11.2 Windows/10 exec-env/EC2 Botocore/1.29.71\r\nUser-Agent Boto3/1.26.76 Python/3.11.2 Windows/10 exec-env/EC2 Botocore/1.29.76\r\nUser-Agent Boto3/1.26.87 Python/3.8.13 Linux/5.15.0-47-generic Botocore/1.29.87\r\nUser-Agent Boto3/1.26.90 Python/3.8.16 Linux/5.4.0-1097-aws Botocore/1.29.90\r\nhttps://www.invictus-ir.com/news/ransomware-in-the-cloud\r\nPage 9 of 11\n\nIndicator\r\nType\r\nIndicator\r\nUser-Agent Boto3/1.26.92 Python/3.11.2 Windows/10 exec-env/EC2 Botocore/1.29.92\r\nUser-Agent [Boto3/1.13.14 Python/3.9.2 Linux/5.10.0-21-amd64 Botocore/1.20.0 Resource]\r\nUser-Agent [aws-cli/1.19.112 Python/2.7.18 Linux/4.4.0-19041-Microsoft botocore/1.20.112]\r\nUser-Agent [aws-cli/2.7.0 Python/3.9.11 Windows/10 exe/AMD64\r\nUser-Agent aws-cli/1.18.69 Python/3.8.10 Linux/5.4.0-137-generic botocore/1.16.19\r\nUser-Agent aws-cli/1.19.1 Python/3.9.2 Linux/5.10.0-21-cloud-amd64 botocore/1.20.0\r\nUser-Agent aws-cli/1.19.112 Python/2.7.18 Linux/4.4.0-19041-Microsoft botocore/1.20.112\r\nUser-Agent aws-cli/1.22.65 Python/3.8.10 Linux/4.4.0-19041-Microsoft botocore/1.27.20\r\nUser-Agent aws-cli/1.24.10 Python/3.6.9 Linux/4.4.0-22621-Microsoft botocore/1.26.10\r\nUser-Agent aws-cli/1.25.17 Python/3.9.7 Windows/10 botocore/1.27.26\r\nUser-Agent aws-cli/1.27.59 Python/3.8.16 Linux/5.4.0-1085-aws botocore/1.29.59\r\nUser-Agent aws-cli/1.27.81 Python/3.8.16 Linux/5.4.0-1085-aws botocore/1.29.81\r\nUser-Agent aws-cli/1.27.83 Python/3.8.16 Linux/5.4.0-1085-aws botocore/1.29.83\r\nUser-Agent aws-cli/2.10.1 Python/3.9.11 Linux/5.15.90.1-microsoft-standard-WSL2 exe\r\nUser-Agent\r\naws-cli/2.10.1 Python/3.9.11 Linux/5.15.90.1-microsoft-standard-WSL2\r\nexe/x86_64.ubuntu.22\r\nUser-Agent aws-cli/2.11.2 Python/3.11.2 Windows/10 exec-env/EC2 exe/AMD64 prompt\r\nUser-Agent aws-cli/2.7.0 Python/3.9.11 Windows/10 exe/AMD64\r\nUser-Agent aws-cli/2.9.19 Python/3.11.1 Linux/4.4.0-19041-Microsoft source/x86_64.kali.2022\r\nUser-Agent aws-cli/2.9.20 Python/3.9.11 Linux/4.4.0-19041-Microsoft exe/x86_64.ubuntu.18\r\nUser-Agent aws-cli/2.9.23 Python/3.9.11 Windows/10 exec-env/EC2 exe/AMD64\r\nAbout Invictus Incident Response\r\nWe are an incident response company and we ❤️ the cloud and specialise in supporting organisations facing a\r\ncyber attack. We help our clients stay undefeated!\r\nhttps://www.invictus-ir.com/news/ransomware-in-the-cloud\r\nPage 10 of 11\n\n🆘 Incident Response support reach out to cert@invictus-ir.com or go to https://www.invictus-ir.com/247\r\n📧 Questions or suggestions contact us at info@invictus-ir.com\r\nSource: https://www.invictus-ir.com/news/ransomware-in-the-cloud\r\nhttps://www.invictus-ir.com/news/ransomware-in-the-cloud\r\nPage 11 of 11\n\n  https://www.invictus-ir.com/news/ransomware-in-the-cloud \nIncident Response support reach out to cert@invictus-ir.com or go to https://www.invictus-ir.com/247\nQuestions or suggestions contact us at info@invictus-ir.com \nSource: https://www.invictus-ir.com/news/ransomware-in-the-cloud   \n   Page 11 of 11",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://www.invictus-ir.com/news/ransomware-in-the-cloud"
	],
	"report_names": [
		"ransomware-in-the-cloud"
	],
	"threat_actors": [],
	"ts_created_at": 1775434271,
	"ts_updated_at": 1775791270,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/4318aa61d488950b078c4f751b1d95cb8eb6f9fe.pdf",
		"text": "https://archive.orkl.eu/4318aa61d488950b078c4f751b1d95cb8eb6f9fe.txt",
		"img": "https://archive.orkl.eu/4318aa61d488950b078c4f751b1d95cb8eb6f9fe.jpg"
	}
}