Over the weekend I read a very interesting and informative blog from AWS “The anatomy of ransomware event targeting data residing in Amazon S3 | AWS Security Blog”. This AWS blog lays out the case for ransomware attacks that are targeted at data stored in Amazon S3.
A few noteworthy observations about the blog
- This blog is written by the AWS Customer Incident Response Team (CIRT). They call out that the most common event that leads to a ransomware event that targets data in Amazon S3, is the unintended disclosure of Identity and Access Management (IAM) access keys.
- The AWS CIRT team makes a distinction between traditional ransomware events that affect mostly infrastructure resources like servers, databases, and connected file systems and non-traditional ransomware events that specifically target data. The blog discusses ransom events targeting S3 but this pattern of events extends to any cloud data asset stores and data warehouses such S3, RDS, Mongo, Snowflake etc.
- Ransom events that target data stored in the cloud leave a definitive IAM footprint. This observation is crucial. After a bad actor has obtained credentials, they use API actions that generate various levels of IAM activity.
Let’s dig into these IAM footprints. These breadcrumbs reveal different IAM actions – new types of permission operations being tried, new APIs, new data actions against the target of the ransom. Essentially pathways, that can be weaponized to ransom data.
The big question is how do we turn these IAM footprints into credible evidence? While we may have interesting clues to a ransomware event do we have sufficient evidence to take action?
What do practitioners need to know?
From a practitioner’s perspective they care about two things:
- Do these IAM breadcrumbs help me identify and quantify my exposure to data in the cloud?
- Do I have enough context and evidence to take action?
How are IAM credentials exposed?
Let’s look at a few different ways IAM credentials can be exposed.
- IAM keys and credentials can be disclosed because of a data breach. Time and again we have seen this from the numerous data breaches where customer IAM keys were exfiltrated and are now in the wild.
- A vulnerable EC2 instance or a software flaw can be exploited to gain initial access. The blog discusses the classic pattern of a compromised EC2 instance where the permissions attached to the instance profile were used to laterally move to ransom data.
- Toxic combinations of weak IAM credentials and permissions. Where the combination or chaining of permissions gives the bad actor an ability to elevate permissions to enable lateral movement and ransom the data.
Bottomline is that any vulnerability or software flaw can be combined with poorly managed IAM credentials to open up access and pathways to ransom or exfiltrate data.
How to take definitive action?
This is all good but do practitioners have enough context and evidence from these IAM footprints to take definite action? Many practitioners worry about false positives that could take them down rabbit holes.
- The first problem is determining whether these footprints present legitimate permissioned activity or anomalous activity by a compromised identity. This is a tough one but a retrospective analysis of IAM events using a 60-day or 90-day baseline can detect the truly unused permission(s) that are being used in the ransom event.
- The second problem is building the right data context. What is the data? What is the sensitivity classification of the data? What is the granularity of access – tables, rows, columns, schemas, etc? What is the posture of the data? How is the data protected? Collectively all of this information builds the full context of the risk and impact of the targeted data.
- The third problem is building the right cloud Identity context. Is this a human or programmatic or cross-account identity? Is it party-party access? What is the baseline of IAM actions for this cloud identity? Does the enumerated IAM actions represent an anomaly for this identity?
When we combine data posture context with access and identity context, practitioners are in a much better position to take proactive action to eliminate these threats and to help prevent them.
DIY requires stitching together multiple products
While this blog calls out the right problem, unfortunately, the solution is DIY – using several products – Cloudtrail for activity logs, Cloudwatch metrics for abnormal transfer spikes, GuardDuty for anomalous API activity and various ancillary log services to pickup additional context. This is just for Amazon S3. How do customers detect attacks on the hundreds of other data asset types, distributed across cloud platforms?
Stack Identity automates the remediation of ransomware risk
This is exactly what we are delivering out of the box with Stack Identity We have automated the early detection and elimination of Ransomware risk events that target cloud data. Our Identity Data Lake ingests identity, access, governance and data posture events from various systems and builds a “connected context”. With continuous visibility, automated right sizing of permission drift and just-in-time governance, security and data owners can quickly prioritize impact and authorize remediation before it turns into a “security incident”.
Zettabytes of data are pouring into cloud platforms. In AWS alone there are ~13,000 permissions that provide access to ~12,000 cloud services opening up pathways to data. The scale of data and the scale of access is fertile ground for this new class of Ransomware attacks targeted at data stored in the cloud. The good news is this is a solvable problem as IAM is a threat vector that enterprises have complete control over.
If this problem and use case is interesting and resonates with you I would love to hear from you. Please DM me at [email protected]