A successful ransomware attack is the culmination of numerous steps performed by a determined attacker: gaining initial access to the victim’s environment, enumerating privileges to identify sensitive data, escalating privileges to gain access to the identified data, and finally encrypting the original data before demanding the ransom payment (with the optional exfiltration step beforehand if an extortion play is on the table).

The encryption process itself is straightforward. After the data is accessed, a cryptographic key (usually an asymmetric key) is used to encrypt the original data, rendering the data unrecoverable by any identity not possessing the key. If the attacker first downloads the data to be used as a potential extortion leverage during the ransom process, this requires attacker-controlled infrastructure to support this data transfer and storage outside the victim’s environment, all while attempting to evade any potential outbound data transfer alerting mechanisms in the target’s environment.

What if this was not necessary and the attacker could simply use the victim’s own infrastructure while nullifying them any access to the data? Creativity is key when discovering new ways to attack a target, achieving a goal with little detection while using the least amount of resources.

Permiso’s P0 Labs research team identified several ways to abuse features allowed by AWS KMS (Key Management Service) to encrypt data on a target's buckets as part of a ransomware attack. This blog will touch upon detection opportunities that might help defenders mitigate these attack vectors through the help of RansomWhen, a new open-source tool we are releasing to aid all organizations in detecting usage of these ransomware TTPs in CloudTrail logs and enumerating identities that possess specific combinations of privileges corresponding to these TTPs.

KMS Ransomware

The idea of using KMS as a ransomware tool was first published by Spencer Gietzen from (then) Rhino Security Labs. He wrote two articles demonstrating how KMS keys can be utilized to encrypt S3 Buckets and lead to extortion:

• https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/
• https://rhinosecuritylabs.com/aws/s3-ransomware-part-2-prevention-and-defense/

At Permiso we discovered many more scenarios where KMS can facilitate the direct encryption of data for ransomware or can be used to tamper with the delivery of CloudTrail logs. For a deep-dive on seven specific attacks leveraging abuse of KMS keys and their corresponding policies (as well as defense recommendations), please refer to the following blog post:

https://blog.pepperclipp.com/pepperclipp-public/encrypting-buckets-for-compliance-and-ransom-how-attackers-can-use-kms-to-ransomware-s3-buckets 

RansomWhen?

All this research led to the creation of Permiso’s newest open-source tool - RansomWhen - a customizable Python-based tool designed to aid defenders in countering these KMS-based ransomware scenarios. This tool’s capabilities include detecting potential ransomware attempts for a specific account based on evidence in CloudTrail logs, while also proactively enumerating identities with access to use KMS keys in various ways to encrypt or otherwise deny access to data residing in an S3 bucket.

Ransomwhen help

Installation

Local Installation

To get started simply install the required libraries:

python3 -m venv ./venv
source venv/bin/activate
python3 -m pip install -r requirements.txt

Then run the tool by executing ransomwhen.py:

(venv) $ python3 ransomwhen.py -h

usage: ransomwhen.py [-h] {IDENTITIES,EVENTS} ...

RansomWhen???

positional arguments:
  {IDENTITIES,EVENTS}  Select the check on the account (the choices are IDENTITIES, EVENTS)
    IDENTITIES         IDENTITIES specific arguments
    EVENTS             EVENTS specific arguments

options:
  -h, --help           show this help message and exit

Docker

A Dockerfile is placed inside the main directory of the project. To build the image, inside the main directory of the project run:

docker build -t ransomwhen .

Then run the container with directory ~/.aws mounted to host:

$ docker run -v ~/.aws:/root/.aws -it ransomwhen -h
 
usage: ransomwhen.py [-h] {IDENTITIES,EVENTS} ...

RansomWhen???

positional arguments:
  {IDENTITIES,EVENTS}  Select the check on the account (the choices are IDENTITIES, EVENTS)
    IDENTITIES         IDENTITIES specific arguments
    EVENTS             EVENTS specific arguments

options:
  -h, --help           show this help message and exit

The tool has two nested Argument Parsers, IDENTITIES and EVENTS. IDENTITIES will list all identities with privileges to any of the ransomware scenarios and EVENTS will list malicious events related to ransomware for each identity.

Enumerating Identities

To enumerate the identities containing privilege-combinations related to ransomware capabilities, the tool loads the JSON configuration file located at scenarios/scenarios.json which contains the necessary list of privileges for thirteen (13) different attacks shown below:

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

This JSON file is easily configurable with the following format, each scenario having a title and a list of privileges to check.

{
    "Create Locked Key and Encrypt Bucket using CopyObject": [
        "kms:CreateKey",
        "s3:PutBucketEncryptionConfiguration",
        "s3:CopyObject"
    ]
}

In the output results, each scenario will display one of the following statuses:

• allowed (for cases when all the privileges in a scenario are allowed)
• partially (for cases when at least one privilege in a scenario is allowed)
• denied (for cases when no privilege in a scenario is allowed)

RansomWhen output for Identity enumeration

Finding Malicious Events

To find identities which have performed these potentially-malicious events, the tool loads the JSON configuration file located at scenarios/events.json. This file is similarly configurable with a sample format below, each event having its relevant properties set to either null or a value, just as it is supposed to be saved in the CloudTrail logs:

{
  "CreateKey": {
    "UserAgent": null,
    "Identity": null,
    "RequestParameters": null,
    "ResponseElements": null,
    "ErrorCode": null,
    "ErrorMessage": null,
    "EventSource": "kms.amazonaws.com"
  }
}

The following events are included in the default checks against all API-accessible CloudTrail logs. As seen above, each event can be configured to check for specific indicators.

kms:CreateKey
kms:PutKeyPolicy
kms:ReEncrypt
kms:CreateCustomKeyStore
kms:UpdateCustomKeyStore
kms:ConnectCustomKeyStore
kms:DisconnectCustomKeyStore
kms:DeleteCustomKeyStore
s3:PutBucketEncryptionConfiguration
s3:CopyObject
s3:PutObject
s3:GetObject
iam:CreateUser
iam:DeleteUser
iam:CreateRole
iam:DeleteRole
iam:AttachUserPolicy
iam:PutUserPolicy
iam:AttachRolePolicy
iam:PutRolePolicy
cloudtrail:StopLogging
cloudtrail:DeleteTrail
cloudtrail:UpdateTrail

Finally, running the tool will query the CloudTrail API and list all the identities (IAM users and roles) and the related events they have executed over the last ninety (90) days (the lookback limit for the CloudTrail API).

Ransomware-related malicious events in CloudTrail logs

Permiso Coverage

For Permiso customers, the following alerts assist in detecting related threats:

Conclusion

If there is one main takeaway from this article then it is this: just because a vendor or cloud service provider has offered functionality for their customers does not mean that same functionality cannot be used nefariously by threat actors. Attackers are becoming smarter and finding new ways to attack their targets while still living off the land (even when the land is in the cloud!).

Defenders must be vigilant in applying the following best practices to their infrastructure to mitigate the aforementioned attacks:

• Continuously monitor which identities (human and non-human) have access to sensitive data or sensitive services like KMS.
• Always enable S3 bucket versioning and MFA delete with least privilege in mind for the identities that have access to MFA.
• Limit account and organization level access if your account is part of an organization.

Permiso Security is laser-focused on researching and building the latest cloud and identity runtime detection capabilities into our product for our customers. For a point-in-time check on a small slice of these techniques, you can access RansomWhen on GitHub: https://github.com/Permiso-io-tools/RansomWhen