How hackers use this AWS ransomware attack

There’s a “new” ransomware attack being used in AWS that you need to know about. But what is it, how does it work, and how can you defend against it? Let’s find out.

We’re going to cover everything from:

• What it is and how it works
• Live demonstration
• We’ll talk about defenses to prevent this attack
• I’ll save the best for last and show you a couple of tools you can use to test and see if your environments are vulnerable

P.S.: prefer videos over text? Watch this article!

Real quick though, at the beginning I wrote that it was a “new” attack with quotes, because it’s not really a new attack technique at all. It’s just actively being exploited in the wild all of a sudden which is why people are talking about it. Otherwise, this technique was shared a while ago by security researcher Spencer Gietzen and security firm RhinoSecurity Labs. But regardless, it’s happening now and it’s making the news, so we’ll probably see more copycats.

Picture this scenario…

An organization is storing a bunch of critical data in Amazon S3 within their AWS accounts. A threat actor gains access to those S3 buckets and that data, and they start to encrypt it. They then leave a ransom note and give the victim 7 days to pay, or else they’ll either delete the data or publish it on the Internet.

But how is this possible? How do we get to that point?

We’re going to talk about 2 variations of this attack. The first requires that you know about an AWS service called the Key Management Service, or KMS for short.

KMS can be used to create and manage encryption keys, and you can use those keys to encrypt data in AWS environments. AWS customers use KMS to encrypt all sorts of data, including Amazon S3 data. That’s not uncommon, and in fact, it’s a recommended best practice.

The problem is that threat actors figured out they could take KMS and turn it against victims for ransomware purposes. They’ll encrypt the data using KMS from their own attacker-controlled account, and then prevent decryption access to the victim unless they pay.

That’s attack technique number 1, which we’ll demonstrate in just a minute.

A second technique uses something called server-side encryption using client-provided keys, and this approach is quite different from the first, so we’ll also break that down.

Let’s walk through step by step how this attack would go down — and just to clarify, I’m showing you this purely for educational purposes and so that we can understand effective defenses.

Breakdown of attack technique #1

By default an S3 bucket uses SSE-S3 for encryption which uses an Amazon S3 managed key which means that it’s created, managed, and used on your behalf by the S3 service. However, you can also select Server-side encryption with AWS KMS keys, or SSE-KMS for short

An attacker, once they gain access to this account, can go to the bucket’s Properties and then Edit encryption settings. They would select the SSE-KMS option, and then specify their own KMS key.

As long as this key resides in the same region as the bucket, it can be from a different account — it can be from an attacker controlled account.

So in another window, I’m authenticated in a separate AWS account entirely and we’ll pretend that this is my attacker-controlled environment. I can go to the KMS service and I’ve already created a key for demonstration, so I can click on it and grab its ARN value, and then go back to the S3 bucket and set that as the encryption key.

This key has a policy allowing the victim to encrypt data uploaded to S3, but they don’t have permissions to decrypt the data. The attacker would add this KMS key to the bucket in the victim’s account and save changes.

After doing that, any object uploaded to the bucket would be encrypted using that key, and anyone wanting to decrypt the data would have to have decryption permissions. Now, let’s upload a file to this bucket, and then let’s try to retrieve it.

In my video demo, I uploaded one of my S3 least privilege cheat sheets, which I figured would be relevant here! Then I tried to download it, and got an AccessDenied because I don’t have access to perform the kms:Decrypt action. The only way for me to retrieve this data, is if the attacker gives me decryption access.

1-Click Deploy Hands-On Labs to learn how S3 KMS encryption works

If you want to learn more about how S3 KMS encryption works, we have 2 Hands-On Labs that can help you:

So that’s one way that this attack can unfold, but a second way would be using Server-side encryption with client-provided keys, or SSE-C for short.

Breakdown of attack technique #2

With SSE-C, you can store data encrypted with your own local encryption keys, so that when you upload an object, S3 uses that encryption key to apply AES-256 encryption. When you go to retrieve the object, you have to provide the same encryption key in order to be able to download and view that object.

This means that whoever controls the key controls the data, and that’s how an attacker can take advantage of that.

If you want to learn how SSE-C works hands-on, I’ve got a Hands-On Lab where you can learn how to encrypt S3 data with SSE-C via the CLI safely in our environments.

But at this point you might be asking: aren’t these attacks just for newly uploaded files? Well, if an attacker has enough permissions to upload data, they can use the AWS API to replace each object in a bucket with a new copy of itself, but this time, it will be encrypted with the attacker’s KMS key.

That can happen very quickly depending on how much data we’re talking about, since this would be automated with a script. It can happen so quickly in fact that your threat detection may not even fire off alerts by the time the attack is already over.

Security Recommendations

This sounds like doom & gloom, but defending against it is actually quite easy.

Let’s talk about the root cause defenses:

1. Stop using long-term access keys and IAM users which is something I’ve been repeating a lot because most breaches still happen due to long-term access keys getting stolen (I have a blog post that can help you with that)
2. Ensure S3 buckets are not misconfigured, and they should follow the principal of least privilege, for which I have a cheat sheet and course content (add links) that you can check out here

Next, let’s talk about additional security controls we can implement:

1. Turn on S3 Object Versioning with MFA delete enabled. This requires having MFA to disable versioning and to delete an object version, so you could retrieve the unencrypted version of that object
2. Consider using S3 Object Lock, especially with backups, that way those objects can’t be encrypted or deleted
3. Speaking of backups, make sure you have them, and they should be in a different AWS account, region, and off-site as well
4. I think you could also use SCPs and RCPs to require specific encryption and encryption that’s not external to your accounts…I’d have to test that out, and make sure it’s practical, but it’s a thought that crossed my mind as I was writing this

AWS has also implemented automatic mitigations, according to their blog post, but that’s not going to block everything. They even mention blocking the use of SSE-C unless required by an application. That’s probably fine if you never plan on using it, but as we saw it won’t prevent this attack entirely. So, maybe, up to you…but definitely not the primary fix.

Test and verify whether you are vulnerable:

Before we wrap up, I want to share 2 tools you can use to test your effectiveness at preventing and responding to this threat.

Tool #1

The first is a script by Spencer Gietzen, which will execute the first attack technique we discussed.

Tool #2

The second tool is an attack simulation tool called Stratus Red Team. They have multiple S3 ransomware scenarios, including one for client-side encryption.

I’ve got a hands-on lab that you can test this out: https://cybr.com/hands-on-labs/lab/s3-ransomware-simulation-through-client-side-encryption/

That way you can try these attacks safely in our accounts first.

Conclusion

But that’s it! That’s what’s going on with these attacks. You now know what they are, how to prevent them, and how to test your defenses.

If you found this helpful, please let me know in the comments below. Thanks for reading!