Ransomware Crew Abuses AWS Native Encryption, Sets Data-Destruct Timer for 7 Days (theregister.com) 17
A new ransomware group called Codefinger targets AWS S3 buckets by exploiting compromised or publicly exposed AWS keys to encrypt victims' data using AWS's own SSE-C encryption, rendering it inaccessible without the attacker-generated AES-256 keys. While other security researchers have documented techniques for encrypting S3 buckets, "this is the first instance we know of leveraging AWS's native secure encryption infrastructure via SSE-C in the wild," Tim West, VP of services with the Halcyon RISE Team, told The Register. "Historically AWS Identity IAM keys are leaked and used for data theft but if this approach gains widespread adoption, it could represent a significant systemic risk to organizations relying on AWS S3 for the storage of critical data," he warned. From the report: ... in addition to encrypting the data, Codefinder marks the compromised files for deletion within seven days using the S3 Object Lifecycle Management API â" the criminals themselves do not threaten to leak or sell the data, we're told. "This is unique in that most ransomware operators and affiliate attackers do not engage in straight up data destruction as part of a double extortion scheme or to otherwise put pressure on the victim to pay the ransom demand," West said. "Data destruction represents an additional risk to targeted organizations."
Codefinger also leaves a ransom note in each affected directory that includes the attacker's Bitcoin address and a client ID associated with the encrypted data. "The note warns that changes to account permissions or files will end negotiations," the Halcyon researchers said in a report about S3 bucket attacks shared with The Register. While West declined to name or provide any additional details about the two Codefinger victims -- including if they paid the ransom demands -- he suggests that AWS customers restrict the use of SSE-C.
"This can be achieved by leveraging the Condition element in IAM policies to prevent unauthorized applications of SSE-C on S3 buckets, ensuring that only approved data and users can utilize this feature," he explained. Plus, it's important to monitor and regularly audit AWS keys, as these make very attractive targets for all types of criminals looking to break into companies' cloud environments and steal data. "Permissions should be reviewed frequently to confirm they align with the principle of least privilege, while unused keys should be disabled, and active ones rotated regularly to minimize exposure," West said. An AWS spokesperson said it notifies affected customers of exposed keys and "quickly takes any necessary actions, such as applying quarantine policies to minimize risks for customers without disrupting their IT environment."
They also directed users to this post about what to do upon noticing unauthorized activity.
Codefinger also leaves a ransom note in each affected directory that includes the attacker's Bitcoin address and a client ID associated with the encrypted data. "The note warns that changes to account permissions or files will end negotiations," the Halcyon researchers said in a report about S3 bucket attacks shared with The Register. While West declined to name or provide any additional details about the two Codefinger victims -- including if they paid the ransom demands -- he suggests that AWS customers restrict the use of SSE-C.
"This can be achieved by leveraging the Condition element in IAM policies to prevent unauthorized applications of SSE-C on S3 buckets, ensuring that only approved data and users can utilize this feature," he explained. Plus, it's important to monitor and regularly audit AWS keys, as these make very attractive targets for all types of criminals looking to break into companies' cloud environments and steal data. "Permissions should be reviewed frequently to confirm they align with the principle of least privilege, while unused keys should be disabled, and active ones rotated regularly to minimize exposure," West said. An AWS spokesperson said it notifies affected customers of exposed keys and "quickly takes any necessary actions, such as applying quarantine policies to minimize risks for customers without disrupting their IT environment."
They also directed users to this post about what to do upon noticing unauthorized activity.
Y'all got incremental off-site backups, right? (Score:1)
Re:Y'all got incremental off-site backups, right? (Score:5, Informative)
What rock have you been living under, smartypants?
WE'RE IN THE CLOUD, MAN, we minimize costs that way and it takes care of everything, no need to involve ourselves in low-level stuff like where we keep our keys and backups.
The cloud does it all, that's what we're paying for!!11!!
Re:Y'all got incremental off-site backups, right? (Score:4, Insightful)
This is kinda the kicker here - they're really only encrypting S3 data, so if you've used S3 to store your backups offsite, or off-region or anything else, you're still vulnerable. That said, if all you use S3 for is backups, you can probably ignore the ransom demands.
This hack is really very simple, and requires some quite-high-level compromised credentials. You could do a lot more damage with those credentials than this hack alone, but hey ho. Essentially, all they do is say "Hey, AWS, encrypt my data with this specific key", and of course don't tell you what the key is. AWS goes ahead and encrypts, and no one has access to the key except the attackers. AWS is doing exactly as they've been told, so it seems unlikely they're going to do much differently.
The mitigation here is obviously not to leave your credentials laying around. There is a way to say "do not allow customer key encryption" on S3 buckets, which you could also set (via a policy), but that'll need to be set with more privileges than whatever account you decide to leave lying around (although it's not clear if the attackers would remove the policy if they had the rights to do so before encrypting, or just chalk it up as "can't do this one, move on").
As I say though, the attackers could almost certainly just delete everything on your bucket right away if they chose to do so. If they've got credentials to do that, I'll bet my lunch those same creds have access to a whole lot more than just S3, so they can do damage elsewhere too.
Re: (Score:2)
I think what is interesting here if there is anything interesting is that it undermines what are (incorrect mind you) assumptions a lot of people have about the cloud.
Namely I don't need to backs of S3 because Amazon has backups; or if I do make backups I just need to copy everything to some other bucket in another availability zone.
Well guess neither of these things really substitutes for your own offline or at least versioned backups. Amazon aint restoring s3 because s3 never lost any data. If you overw
Re: (Score:2)
This attack can be done with other AWS mechanisms as well, AWS EventBridge could be used for a self-destruct timer as well. Or a cronjob tucked away on an EC2 instance. Using S3 bucket migration is just one way to tuck a logic bomb somewhere.
As the parent states, credentials are critical, as well as least privilege. However, with a number of applications, they may store AWS credentials in a horrifically insecure way. I've seen devs spent a ton of time making homegrown obfuscators so they could stick a
Re: (Score:2)
Re: (Score:2)
They have been mucking with the site - it's broken many things.
Ghostery is pretty hit and miss for me. It's breaking every second page. Highly enjoyable.
Re: (Score:2)
Adguard is working well enough. Maybe 1 or 2 ads every dozen page loads.
Re: (Score:2)
Why not have the spam, eggs, ham, and spam? That's not got much spam in it.
Re: (Score:2)
uBlock Origin renders the site completely blocked, with a demand to turn off the ad blocker. I only turned it off long enough to say either they revert or I leave. If I'm costing them so much money they can't continue, then they'll be dead soon anyhow. If they're just being grabby, fuck 'em. I had enough karma to turn off ads a long time ago. Now they're back with a vengeance. The ad blocker wasn't even supposed to do much of anything on this site, now I'd consider it an absolute necessity.
Re: (Score:2)
Well, yes (Score:1)
Windows Syskey is back (Score:2)
The new and improved Amazon S3 edition which uses real cryptography and actually applies it to your data.
Apologizing (Score:2)
Let the cloud apologizing begin in 3...2...1...
The Great Oops is nigh (Score:2)
It's coming. Kiss the cloud goodbye.