Disclaimer: The information in this blog post is provided for educational and informational purposes only. We do not endorse, promote, or support any malicious activities, including hacking, unauthorized access, or exploiting vulnerabilities. Defenders are encouraged to use the knowledge shared here to strengthen security practices and increase the resilience of their environments against potential ransomware threats.

Introduction  🌩️

As organizations increasingly migrate their workloads to the cloud, data security remains a shared responsibility between cloud service providers (CSPs) and their customers. A cornerstone of cloud security is encryption, which ensures that sensitive data remains confidential, tamper-proof, and accessible only to authorized users. Over time, encryption key management has evolved significantly, shifting from traditional on-premises hardware security modules (HSMs) to cloud-native Key Management Services (KMS) offered by major CSPs.

Among these, AWS Key Management Service (AWS KMS) has become a widely adopted solution, providing centralized control over encryption keys with seamless integration into AWS cloud services. It enables users to generate, store, and manage cryptographic keys securely, ensuring that data at rest and in transit is protected across AWS environments. With fine-grained access controls via AWS Identity and Access Management (IAM), automated key rotation, and logging through AWS CloudTrail, AWS KMS can help organizations meet compliance or regulatory requirements and adhere to security best practices.

It is particularly valuable for securing services such as S3 buckets, RDS databases, EBS volumes, Lambda functions, and other AWS services that require encryption. Supporting both AWS-managed keys and customer-managed keys (CMKs), KMS provides flexibility for enforcing security policies. Additionally, AWS integrates KMS with hardware security modules (HSMs) via AWS CloudHSM, offering FIPS 140-2 Level 3 validated security for highly regulated industries.

However, while AWS KMS enhances cloud security, it can also present risks if not properly configured. Chris Farris' blog (since revised) on Effective Techniques for AWS Ransomware highlighted an attack method targeting AWS resources using KMS with external key material. 

Figure 1.1: Screenshot from https://www.chrisfarris.com/post/effective-aws-ransomware/ 

Two methods were highlighted that arguably neither AWS nor the legal system can prevent:

• External Key Store (XKS) Exploitation: Attackers can use XKS to store encryption keys outside AWS KMS, but this method is complex, difficult to scale, and risky as it requires restoring external infrastructure, increasing detection chances.
• Bring Your Own Key Material (BYOKM) Exploitation: Attackers generate and upload their own key material to AWS KMS, then delete it to make encrypted data inaccessible, effectively holding it hostage until the threat actor's key is re-uploaded.

The second method, Bring Your Own Key Material (BYOKM) has been observed in the wild, with threat actors leveraging AWS KMS to encrypt victim data for ransom. This method allows threat actors to gain control over encryption keys and effectively lock victims out of their own resources.

Steps in the BYOKM Attack Process 🔐

1. Generate Key Material: The attacker creates KMS key material externally.
2. Upload Malicious Key Material: Using a compromised victim AWS account with full KMS permissions, the attacker executes ImportKeyMaterial, uploading their own encryption keys into the victim’s AWS account and replicating them across all regions.
3. Re-encrypt Data with Attacker’s Keys: The attacker replaces existing keys with the imported BYOKM key and re-encrypts all critical data, ensuring that only they have the decryption capability.
4. Execute the Ransom Attack: At the chosen moment, the attacker deletes the key material using DeleteImportedKeyMaterial, making the victim's encrypted resources completely inaccessible.

In another article - Redefining Ransomware Attacks on AWS using AWS KMS XKS, - Harsh Varagiya explores how threat actors may exploit AWS's External Key Store (XKS) to enhance ransomware attacks. XKS allows AWS services to use encryption keys stored outside AWS, enabling encryption for over 100 services, including Amazon EBS and S3, without modifying existing configurations. Attackers can leverage this by encrypting data with external keys, rendering it inaccessible to victims unless a ransom is paid. This method complicates detection and prevention, as it relies on the victim's infrastructure and the flexibility of AWS's encryption capabilities.

Attack Path Detection using RansomWhen ⏳

In an effort to enhance detection capabilities and help defenders identify ransomware attack paths, Permiso Security’s P0 Labs research team has developed an open-source tool named RansomWhen. This Python-based tool is designed to help defenders detect KMS-based ransomware attacks within a specific AWS account through CloudTrail log analysis. Additionally, it can be used to proactively enumerate identities with permissions to use KMS keys in ways that could encrypt or restrict access to data stored in an S3 bucket. Better defenders run this tool in their own account before threat actors do!

RansomWhen allows defenders to

• Identify Overly Permissive IAM Roles & Users
• Detect Suspicious KMS Encryption Events
• Proactively Audit KMS Key Misuse Risks

🎯 We'll now investigate a scenario where  we suspect that an attacker has compromised a victim’s AWS account, imported a Customer Master Key (CMK), encrypted S3 buckets and then deleted the CMKs to render the data inaccessible. We'll use RansomWhen to enumerate "risky" identities and also to detect suspicious KMS events.

Let’s begin!

Install RansomWhen  🐚

$ git clone https://github.com/permiso-security/RansomWhen.git
$ cd RansomWhen
$ python3 -m venv venv
$ source venv/bin/activate  # For Linux/macOS
$ venv\Scripts\activate     # For Windows
$ pip install -r requirements.txt 

Then configure the AWS CLI profile using the command aws configure . We can use an IAM user with admin permissions in the AWS environment, or in line with the principal of least privilege, an IAM user that is assigned the following permissions:

• iam:ListUsers
• iam:GetUser
• iam:ListUserPolicies
• iam:ListAttachedUserPolicies
• iam:ListGroupsForUser
• iam:ListGroupPolicies
• iam:ListAttachedGroupPolicies
• cloudtrail:LookupEvents
• iam:GetPolicyVersion
• iam:GetPolicy

Identity Enumeration  🕵️

Let’s start by running  python3 ransomwhen.py IDENTITIES  to enumerate the identities within the compromised account. This expects a  -p  or  --profile  parameter for the AWS profile to use.

# This command identifies the AWS principals with exploitable permissions
$ python3 ransomwhen.py IDENTITIES --profile RansomWhen

RansomWhen identified what seems to be excessive permissions for a test IAM User ( Test-prod ) within the compromised account and presented various possible attack scenarios that an attacker could leverage to execute a ransomware attack.

RansomWhen reports if AWS principals are able to perform any of the following actions that ransomware actors may perform to help them achieve their objectives.

• Attach Custom KMS Key Store
• Create Locked Key and Encrypt Bucket using CopyObject
• Create Locked Key and Encrypt Bucket using Get/Put Object
• Create Role, Add Inline Policy and Delete
• Create Role, Attach Inline Policy and Delete
• Create User, Add Inline Policy and Delete
• Create User, Attach Inline Policy and Delete
• Delete CloudTrail Trail
• Stop Logging
• Stop Logging using KMS
• Update Current Custom KMS Key Store
• Update Key Policy to Lock Key and Encrypt Bucket using CopyObject
• Update Key Policy to Lock Key and Encrypt Bucket using Get/Put Object

Monitor for Malicious Events in AWS CloudTrail Logs  👀

Next, let's use RansomWhen to detect potentially malicious activities. If we don't select the principal to query, the tool will attempt to list users and roles using the iam:ListUsers and iam:ListRoles permissions. 

💡 A pull request has been created from this fork of RansomWhen to address an issue where the same event data is returned for different AWS principals.


# This command detect suspicious activities, such as unauthorized key imports or deletions
$ python3 ransomwhen.py EVENTS --profile RansomWhen # all users
$ python3 ransomwhen.py EVENTS --profile RansomWhen -i <user> # specific user

The RansomWhen output reveals that the potentially compromised user Test-prod issued a kms:CreateKey request 😱 

We see an IAM policy in the RequestParameters because whenever you run kms:CreateKey, AWS KMS attaches a key policy—either the default one or a custom policy that you provide in the request. 

We can continue to analyze the breach using Splunk or natively using Amazon Athena.

Preventing This Attack  🏰

"The key question is not if customers can prevent this attack, but will they proactively implement these security measures?" - Chris Farris

• Restrict IAM Permissions & KMS Access:
  • Remove broad KMS permissions (  kms:* ).
  • Follow the principle of least privilege, ensuring only necessary permissions are granted.
  • Block kms:ImportKeyMaterial using a Service Control Policy (SCP) to prevent unauthorised key uploads.
    
    
• Monitor & Detect KMS Activity via CloudTrail:
  • Track suspicious actions like ImportKeyMaterial, DeleteKeyMaterial, and ScheduleKeyDeletion in CloudTrail Logs.
  • Set up detections based on CloudTrail eventName/eventSource pairs to flag unauthorised key modifications.
  • Since KMS key operations are logged, create alerts to identify potential ransomware activities.
    
    
• Enforce Strong Key Management Policies:
  • Restrict key usage via KMS key policies to specific IAM roles and services.
  • Enable multi-factor authentication (MFA) for critical key management actions.
  • Configure automatic expiration of imported key material to limit unauthorised key persistence.
    
    
• Detect & Block the Rug-Pull Operation:
  • kms:DeleteImportedKeyMaterial is a critical event to monitor and block, as it signals an attempt to make encrypted data permanently inaccessible.

Wrap-Up and Resources 🖇️

• [tl;dr sec] #256 - AI SOC Analyst, Detection Engineering, How to Ransomware in AWS
• Effective Techniques for AWS Ransomware [Must Read]
• Resource control policies in AWS KMS
• Key policies in AWS KMS
• Logging and monitoring in AWS Key Management Service
• Importing key material for AWS KMS keys
• Perfecting Ransomware on AWS — Using ‘keys to the kingdom’ to change the locks
• RansomWhen??? I Never Even Noticed It…
• S3 Ransomware Part 1: Attack Vector