The Complexity of Detecting Amazon S3 and KMS Ransomware

April 7, 2025
Jason Kao

Amazon S3 Ransomware: Detection

While following up on our research on preventing ransomware in Amazon S3 and KMS and while working with the Cybr team on explaining Amazon S3 Ransomware, we found detecting ransomware to be complex. We also noticed that some available tools do not account for the complexities of detecting and available logging - which could result in a false sense of security from false negatives in environments. Some over-index on AWS CloudTrail (AWS's go-to service that records API calls made in AWS), but AWS CloudTrail by default does not include data events - which could mean ransomware attacks go undetected.

In this post, we will cover:

We also have developed and recently updated YES3, an open source tool that scans for S3 access issues and ransomware prevention controls, which can also help identify available detection settings for your S3 configuration including S3 logging and if other tools will provide accurate results in detecting ransomware.

If you have questions or feedback, we can be reached at info@fogsecurity.io.

Detection in AWS: Amazon S3 Ransomware

AWS comes with the following S3-relevant logging capabilities:

KMS API calls are logged in CloudTrail and S3 events are logged in CloudTrail or either in S3 Server Access Logging.  For more information about AWS CloudTrail and S3 Server Access Logging, see AWS's documentation on S3 logging.

Latency in Logging and Detection

Keep in mind that logging does have a delay with delivery. While these logs can be used for defense, forensics, or post-incident analysis, efficient malicious actors may be able to complete a ransomware attack before any alerting occurs due to the delay in delivery of logs.

We still recommend strategizing around having logging and monitoring for sensitive data and publicly exposed buckets to detect for potential reconnaissance activities and unusual activity that can signal potential compromise or impending attempts at ransomware.

Default Configuration

By default, an AWS Account will not have a CloudTrail Trail.  Event history is available and will show the last 90 days of management events. This does not include data events.  Additionally, when a S3 bucket is created, server access logging is disabled by default.

Keep in mind that your organization may have different setups for your AWS account - including centralized CloudTrail logs or additional setup with logging in your AWS account.  We recommend checking with your teams that manage AWS infrastructure to see if there are any changes to default configuration.

Default Logging Configuration for a S3 Bucket

AWS CloudTrail

Server Access Logging

For example, running either of the commands via AWS CLI (either high-level s3 or low-level s3api) will result in buckets created with Server Access Logging disabled:

aws s3 mb s3://fog-security-example-ransomware-bucket

‍

aws s3api create-bucket \
--bucket fog-security-reference-ransomware-detection-bucket

‍

Logging Cost

Both S3 Server Access Logging and Logging S3 Data Events in CloudTrail will incur additional charges. This needs to be considered as data events can be high-volume.

CloudTrail Data Events Pricing: 

S3 Server Access Logging Pricing:‍

Ransomware Scenarios and Detection

For more information on ransomware scenarios, reference our previous research that covers 11 different use cases for preventing ransomware for Amazon S3 and KMS. In each of the following ransomware techniques and scenarios below, we will detail the indicators of compromise for detection including the permissions required or events to log (which map to API calls), what type of logging is needed to detect ransomware, and if it's logged by default in a standard AWS account.

Note: CloudTrail and other logs do not always map 1-1 with IAM Permissions (and API Actions) in AWS.

Ransomware Technique: SSE-C Ransomware

Events: s3:PutObject and s3:GetObject (s3 copy)

Detection: Server Access Logging and CloudTrail Data Events

Logged by Default: No

One type of ransomware recently in the news is S3 ransomware utilizing SSE-C encryption.  This type of ransomware replaces data in S3 with data encrypted with SSE-C encryption, where the encryption keys are provided by the customer (or malicious actor) and are not stored by AWS. One method of conducting SSE-C ransomware involves using S3 copy commands to rewrite files but with SSE-C encryption.  Due to the copy command using both s3:PutObject and s3:GetObject  which are both data events, this attack will be only be logged in S3 Server Access Logging and CloudTrail Data Events.

aws s3 cp s3://<bucket_with_data>/<file_name> s3://<bucket_with_data>/<file_name> \
--sse-c AES256 \
--sse-c-key <customer_provided_key_here>

‍

Ransomware Technique: Encryption Change (Object-Level)

Events: s3:PutObject and s3:GetObject (s3 copy)

Detection: Server Access Logging and CloudTrail Data Events

Logged by Default: No

Similar to the SSE-C Ransomware technique above, changing encryption on existing objects (data) in S3 can be done with an S3 copy command.  This command uses both the s3:PutObject and s3:GetObject permissions which are both data events to replace objects encrypted with an attacker-controlled KMS key. This attack will be only logged in S3 Server Access Logging and CloudTrail Data events.

‍

Ransomware Technique: Object Deletion

Events: s3:DeleteObject or s3:DeleteObjects

Detection: Server Access Logging and CloudTrail Data Events

Logged By Default: No

Certain ransomware attacks may delete data and hold the data hostage. In buckets without versioning enabled, a s3:DeleteObject call can delete data. Due to s3:DeleteObject being an object-level command, this can be detected either in server access logging or CloudTrail data events and is not logged by default in CloudTrail management events.

If bucket versioning is enabled, it still will be an s3:DeleteObject event, but will also require the s3:DeleteObjectVersion  IAM permission.

Note: s3:PutObject can also be used to delete data by overwriting existing data.

Ransomware Technique: Object Deletion via S3 Lifecycle Configuration

Events: S3.EXPIRE.OBJECT or S3.CREATE.DELETEMARKER

Detection: Server Access Logging

Logged By Default: No

Another sneakier way to delete data in S3 is to use S3 Lifecycle Configuration to automatically delete data after a certain time.

‍Amazon S3 Lifecycle actions are not logged in CloudTrail since S3 lifecycle actions use internal Amazon S3 endpoints and CloudTrail only captures actions that use external Amazon S3 endpoints. Thus, to track the actual deletion actions done by S3 lifecycle configuration, Server Access Logging can be used. These events in Server Access Logging are S3:EXPIRE.OBJECT for permanent deletoin due to lifecycle Expiration action and s3:CREATE.DELETEMARKER for when S3 logically deletes the current version in a verisoning-eabled bucket by adding a delete marker.

‍

Ransomware Technique: S3 Lifecycle Configuration Change (Leads to Object Deletion)

Events: s3:PutLifecycleConfiguration

Detection: CloudTrail Management Events

Logged By Default: Yes

In order to have a lifecycle configuration as specified in the ransomware technique above, a S3 bucket's lifecycle configuration must be set.  This can be done via s3:PutLifecycleConfiguration , which is logged in CloudTrail Management Events as it is a bucket-level operation.  Keep in mind that this by itself does not mean data has been deleted, but can be an indicator that a malicious actor has set a lifecycle configuration to automatically delete data in S3 after a certain time as used in the 'Codefinger' SSE-C ransomware attacks.

‍

Ransomware Technique: Default Bucket Encryption Change

Events: s3:PutBucketEncryption

Detection: CloudTrail Management Events

Logged By Default: Yes

Another indirect method to set encryption on data in S3 is to change the default encryption settings on an S3 bucket.  This setting will apply to any new writes without encryption specified to the bucket.  Keep in mind this does not change encryption on existing objects in the S3 bucket.  An attacker may use this technique on a S3 bucket with frequent writes in order to "ransom" new data. With this technique, s3:PutBucketEncryption is a bucket-level operation and will show in CloudTrail Management Events.

We plan on doing more research on how encryption works in Amazon S3. Reach out to us at info@fogsecurity.io if you're interested!

‍

Ransomware Technique: KMS Key Access Change

Events: kms:PutKeyPolicy

Detection: CloudTrail Management Events

Logged By Default: Yes

Part of ransomware in AWS may involve changing an encryption key's access to remove legitimate access to the KMS Key. This can be done by kms:PutKeyPolicy and is logged in CloudTrail as a management event.

‍

Ransomware Technique: KMS External Key Store (XKS)

Events: kms:CreateCustomKeyStore and kms:ConnectCustomKeyStore

Detection:  CloudTrail Management Events

Logged By Default: Yes

One hypothetical KMS ransomware technique is to use a KMS External Key Store (XKS). A KMS external key store is a newer feature by AWS KMS which is a custom key store backed by an external key manager that is owned and managed outside of AWS. We describe this and the IAM permissions (as well as an SCP to prevent using XKS) here. In order for a External Key Store to be used, it must be both created via kms:CreateCustomKeyStore and then connected to a KMS key via kms:ConnectCustomKeyStore. This will be logged in CloudTrail management events. kms:UpdateCustomKeyStore, kms:DisconnectCustomKeyStore, and kms:DisconnectCustomKeyStore can also be monitored for as they are additional events related to managing a KMS external key store.

‍

Ransomware Technique: KMS Key Creation with non AWS_KMS Key Material

Events: kms:CreateKey and kms:ImportKeyMaterial

Detection: CloudTrail Management Events

Logged By Default: Yes

One aspect of a ransomware attack with KMS may be to create a KMS Key with attacker-controlled key material.  In order to do so, the malicious actor must call kms:ImportKeyMaterial which imports external key material into an existing KMS key. This will be logged in CloudTrail as all AWS KMS oeprations are logged.

‍

Ransomware Technique: KMS Key Material

Events: kms:DeleteImportedKeyMaterial

Detection: CloudTrail Management Events

Logged By Default: Yes

One aspect of a ransomware attack with KMS may be to remove legitimate access to the data. One such way is to delete imported key material of a KMS key (that uses imported key material). This renders the KMS key unusable unless the same material is re-imported.

‍

Ransomware Technique: Point KMS Key Alias at a Different KMS Key

Events: kms:UpdateAlias

Detection: CloudTrail Management Events

Logged by Default: Yes

If a KMS Key Alias is used for encryption, the "friendly name" for a KMS Key can be pointed at a different KMS Key within the same AWS account.  In this scenario, an attacker can change an alias pointing at a non-malicious key to a key that has been compromised by the attacker (such as a KMS Key with attacker-controlled key material and a compromised key policy for access). CloudTrail logs all AWS KMS operations as management events, including kms:UpdateAlias.

‍

Recommendations

We recommend using the following baseline logging controls in AWS:

With advanced logging such as data event logging in CloudTrail and server access logging, we recommend:

If it makes sense for your use cases and company:

CloudTrail Data Events have a faster time for log delivery compared to S3 Server Access Logging. However, given how data events and additional logging costs can add up with high-volume activity, the following can be done to reduce cost:

CloudTrail offers event selectors such as eventName and resources.ARN.

An example CloudTrail advanced event selector to trigger on Delete Object or Delete Objects (Console) calls for the S3 bucket fog-sample-ransomware-prevent  is below.  This selector utilizes both the eventName and resources.ARN field selectors.

[
  {
    "FieldSelectors": [
      {
        "Field": "eventCategory",
        "Equals": [
          "Data"
        ]
      },
      {
        "Field": "resources.type",
        "Equals": [
          "AWS::S3::Object"
        ]
      },
      {
        "Field": "eventName",
        "Equals": [
          "DeleteObject"
        ]
      },
      {
        "Field": "resources.ARN",
        "StartsWith": [
          "arn:aws:s3:::fog-sample-ransomware-prevent/"
        ]
      }
    ]
  },
  {
    "FieldSelectors": [
      {
        "Field": "eventCategory",
        "Equals": [
          "Data"
        ]
      },
      {
        "Field": "resources.type",
        "Equals": [
          "AWS::S3::Object"
        ]
      },
      {
        "Field": "eventName",
        "Equals": [
          "DeleteObjects"
        ]
      },
      {
        "Field": "resources.ARN",
        "StartsWith": [
          "arn:aws:s3:::fog-sample-ransomware-prevent"
        ]
      }
    ]
  }
]

‍

To help with scanning buckets for we've updated our open-source S3 Scanner, YES3 Scanner, to now also scan for logging in S3.  YES3 scanner will check for server access logging in addition to other ransomware protection such as object lock, versioning, and for public access via ACLs and bucket policies.

Conclusion

We have now covered the following in our ransomware series of research as well as published the following open source tools:

We have now covered a holistic approach to cloud-native ransomware. From breaking down a newer technique with SSE-C ransomware in Amazon S3 to identifying and protecting against cloud-native ransomware, and now also detecting cloud-native ransomware attacks.

If there's anything we can help with, reach out to us with feedback at info@fogsecurity.io. We have more planned in the cloud ransomware space - keep an eye out for more of our work in the near future.

References

Fog Security: YES3 Scanner, the open source S3 access and ransomware protection scanner‍

Fog Security: Complete Guide to Ransomware Protection in Amazon S3 and KMS

Cybr: S3 Ransomware Webinar (Youtube)

AWS Documentation: Amazon S3 Logging Options

AWS Documentation: Amazon S3 CloudTrail Events

AWS Blog: How to Optimize AWS CloudTrail Costs Using Advanced Event Selectors

Subscribe to stay up to date on cloud data security and our work.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Copyright Fog Security