What You Need to Know About AWS Ransomware

As bad of an issue ransomware is within data centers, I was a bit skeptical that it was much of a problem in cloud. I, personally, hadn’t run into any incidents, and I started to think it was more theoretical than anything else. It turns out I was a little wrong. Okay, totally wrong. Not only is it a bigger problem than I thought, but the attack pattern was different from than I expected within Amazon Web Services (AWS).

At the AWS re:Inforce conference, I attended an awesome session led by Kyle Dickinson, Megan O’Neil, and Karthik Ram. It was totally packed, and the room minder turned away dozens of people. This post is a bit of a recap of the session, combined with my own experiences and recommendations regarding AWS ransomware. Any errors and omissions are mine, not theirs.

Key highlights:

• Ransomware actors are increasingly targeting Amazon Web Services (AWS) environments, often exploiting gaps in identity access, storage configurations, and visibility across services.
• Amazon S3 buckets are a common entry point, with attackers encrypting or deleting critical data due to weak policies or a lack of encryption enforcement.
• Effective ransomware defense in the cloud requires a layered strategy, including access control, real-time monitoring, and rapid response workflows.
• FireMon enhances data security posture by continuously monitoring for misconfigurations, enforcing policy at scale, and providing visibility that helps teams respond faster to cloud-based ransomware threats.

Is Amazon AWS Ransomware​ a Problem?

Yep. It turns out AWS ransomware is more of a problem than I originally thought. Real customers are being affected, it isn’t merely theoretical.

How Does an Amazon Ransomware Attack Work?

I’ll cover the initial exploit vector in the next question, but there are four possible Amazon ransomware attack techniques:

• Attackers compromise an instance (often via phishing a user/admin, not always direct compromise), then install their malware to encrypt the data and spread to other reachable instances. This is really no different than ransomware in a data center since it doesn’t involve anything cloud-specific.
• The attacker copies data out of an S3 bucket and then deletes the original data. This is the most commonly seen cloud native Amazon ransomware.
• A bad actor encrypts S3 data using a KMS key under their control. This is more theoretical than real, due to multiple factors. It’s a lot easier to just delete an object/bucket than it is to retroactively encrypt one.
• An attacker does something the to data in another storage service to lock/delete the data. I’m being nebulous because this isn’t seen, and most of those services have internal limitations and built-in resiliency that make ransomware hard to pull off.

Ransomware targets AWS S3 buckets most commonly, with the attackers copying and then deleting the data. Instances/servers can also be a target of the same malware used to attack data centers. There are a few theoretical attacks that aren’t really seen in the wild. 

One new Amazon ransomware attack, however, is gaining traction: ransomware gangs have begun encrypting data in place using AWS’s server-side encryption with customer-provided keys (SSE-C). This technique lets attackers encrypt files directly in your S3 buckets without removing them or triggering standard alerts, and recovery is impossible without the attacker’s custom encryption key.

How Do Threat Actors Get Access to Perform Amazon Web Services Ransomware Attacks?

Exposed credentials. Nearly always static access keys, but possibly keys obtained from a compromised instance (via the metadata service). You know, pretty much how nearly all cloud-based security attacks work.

What’s the Sequence of an S3 Ransomware Attack​?

I’ll focus on the S3 bucket ransomware scenario since that’s the cloud native one we want to focus on.

• Attacker obtains credentials.
• Attacker uses credentials for reconnaissance to determine allowed API calls and identify resources they can access.
• Attacker discovers they have S3 write permissions and list/read access to identify buckets. Note that the attacker may not have List privileges but can obtain the bucket names from other sources, like DNS, GitHub, or other locations. This is much less likely.
• Attacker copies/moves data to another location, which isn’t necessarily in AWS.
• The attacker deletes the source objects/files.
• Attacker uploads a ransom note (or emails). 

In recent campaigns, attackers have also started using S3 Object Lifecycle Management policies to mark encrypted files for deletion within seven days, increasing the urgency to pay the ransom. They often leave a warning.txt file in the affected directory with a Bitcoin wallet address and a unique victim ID.

Since this is all automated, the process can start within a minute of a credential exposure.

How Can I Detect Amazon S3 Ransomware​?

Well, if you can’t skip to S3 ransomware prevention…

The attacker will usually leave a note with contact information so you can send them Bitcoin, which is convenient. But the odds are most of you will want to identify a problem before that.  Let’s walk through the Amazon S3 ransomware attack sequence to see where we can pick things up.

First, you will want to enable more-in-depth monitoring of your sensitive buckets. Since this post is already going longer than I’d like, I will skip over all the ins and outs of how to identify and manage those buckets and, instead, focus on a few key sources to consider. For cost reasons, don’t expect to turn these on for everything:

• CloudTrail, of course.
• CloudTrail Data Events for any buckets you care about. This costs extra.
• GuardDuty.
• Optional: Security Hub. This is the best way to aggregate GuardDuty and other AWS security services across all your accounts.
• Maybe: S3 Server Access Logs. If you have CloudTrail Data Events, you get most of what you would want. But S3 logs are free to create (you just pay for storage) and do pick up a few events that CloudTrail might miss (e.g., failed authentications). They also take hours to see, so they aren’t useful in a live-fire incident. Read more in this user guide.

Now that we’ve covered monitoring, let’s look at the seven steps in the detection process: 

1. Detecting Exposed Credentials and Recon Activity

The detection process starts with self or third-party identification of publicly disclosed or compromised AWS keys, as well as any suspicious activity. Usually via scanning a common repository, like GitHub. Amazon Web Services once found one of mine and emailed me. Oopsie.

Your account credential recon detections will work here. Some options include:

• GuardDuty findings, such as credential exfiltration. However, this has about a 20-minute delay, and there are evasion techniques
• The GetCallerIdentity API call isn’t always bad, but it isn’t a call you should see a lot in production accounts
• GetAccountAuthorizationDetails should trigger an alarm every time
• Multiple failed API calls from a single IAM entity

2. Watching for S3 Enumeration

Now we start focusing on AWS ransomware detections that indicate the attacker is focusing in on S3. You likely notice that early detection in these phases can be difficult due to the noise, but keep in mind these will be more viable in situations like production accounts managed via CI/CD with limited human access. Heck, this might motivate you to use more cloud-native patterns.

The GuardDuty S3 findings for Discovery events, which have to be enabled on top of just turning on GuardDuty, depending on how your account and organization are set up. Filter for failed Read and List Management and Data Events on the S3 service. You might catch the attacker looking around. You could do this in your SIEM but it’s also easy to build CloudWatch Metrics Filters for these.

3. Monitoring for Object Reads and Copying

Here, you’re continuously monitoring to see if the attacker is reading the objects and making copies. If they read (copy) and then delete each object, this may intertwine with the next phase.

4. Catching Mass Deletion and Ransom Note Placement

This is the “uh oh” stage. The attacker isn’t merely looking around, they are executing the attack and deleting the copied data. The GuardDuty exfiltration/impact S3 findings will kick in. Remember, it takes at least 20 minutes to trigger and depending on the number of objects, this could be a late indicator. CloudTrail Insights, if you use them, will alert on the large number of Write events used to move the data.

You can build your own detections for a large number of delete calls. Depending on your environment and normal activity patterns, this could be a low number and trigger faster than GuardDuty. Your SIEM and CloudWatch Metrics Filters are good options.

5. Identifying SSE-C Abuse (Silent Encryption)

Monitor for sudden application of SSE-C headers in API calls like PutObject—a sign data may be encrypted using the attacker’s key. Since AWS logs only an HMAC hash of operations, standard forensic recovery is impossible without proactive monitoring.

6. Using Canary Buckets and KMS Detection

Mature organizations can seed accounts with canary buckets/objects and alert on any operations touching those buckets. While it’s a less common attack pattern, you can alert people about the use of a KMS key from outside your account.

7. Escalation and Incident Response

If you’re detecting the attack here, you’re already compromised. It’s time to respond. Call law enforcement and engage the AWS customer incident response team. 

AWS Ransomware Protection: How Can I Keep My Enterprise Safe?

To carry out a successful AWS ransomware attack, the bad actor needs three conditions:

• Access to credentials
• Permissions to read and write in S3
• The ability to delete objects that can’t be recovered

The first layer in preventing ransomware is locking down IAM, then using the built-in AWS tools for resiliency. That’s easy to say and hard to do, but here is an S3-focused checklist, and I’ll try to leave out most of the common hygiene/controls:

• Don’t allow IAM users who come with static access keys at all. If that isn’t possible, definitely use your tooling to identify any users with S3 delete permissions.
• Require MFA for SSO/federated users. Always and forever.
• Have administrators escalate to a different IAM role when they need to perform delete operations. You can even fully separate read and delete permissions into separate roles.
• If an instance needs access to S3, make sure you scope the permissions as tightly as possible to the minimal required API calls to the minimal resources.
• Disable SSE-C unless it’s absolutely necessary. This helps prevent silent encryption attacks that can lock you out of your data with no recovery path.
• Use a VPC endpoint to access the bucket, and layer on a resource policy that only allows delete from the source VPC. Then the attacker can’t use the credentials outside that VPC.
• Turn on versioning, AWS Backup, and/or bucket replication. All of these will ensure you can’t lose  access to your data. Well, unless you REALLY mess up your IAM policies and let the attacker have at it. Some of these need to be enabled when you create the bucket, so you might need to have a migration operation to pull it off.

You’ll notice I’m skipping Block Public Access. That’s a great feature, but many orgs struggle to implement it at scale since they need some public buckets and it won’t help with attacks using exposed credentials.

This all takes effort and adds costs, so I really recommend focusing on the buckets that really matter at the start. There are some more advanced strategies, especially if you are operating larger environments, that can’t fit in a post, but drop me a line if you want to talk about them.

What New Things About S3 Ransomware Did You Learn In The Re:Inforce Session?

I didn’t know that S3 ransomware was so common. I also didn’t know that copy-then-delete was the preferred attack technique. I thought it was using KMS encryption and it makes total sense why that is more theoretical and rare. I was familiar with the detectors and defenses, but the AWS speakers did a wonderful job tying them all together in a very clear and usable way. The talk definitely exceeded my expectations.

How Can Firemon Help My Enterprise with S3 Ransomware Protection?

We have a new IAM product in Beta for Just in Time privileges that should be out soon. We also offer posture checks and threat detectors in DisruptOps to identify risky buckets and alert on malicious activity, such as ransomware attacks. Drop me a line if you want to talk about them, or even if you just want some general advice on the AWS options I mentioned in the post.

Book a demo today, and see how FireMon can help you protect your enterprise from AWS ransomware.