S3 KMS Ransomware

Attack technique

Technique name: AWS S3 encryption using KMS

MITRE ATT&CK
Tactic: Impact
Technique: Data Encrypted for Impact

Technique description
As organizations transition from storing data on-premise to Cloud storage, AWS S3 buckets have become a popular target for threat actors due to the prevalence of misconfigurations. Once buckets are compromised, they provide attackers with access to vast amounts of data that can be used for a variety of malicious purposes, such as exfiltration, ransom, or sale on the darknet. S3 ransomware attacks are particularly devastating for companies, as they can result in the loss of access to S3 objects, requiring the victim to either comply with the attacker's demands or seek assistance from authorities or AWS incident response team, risking data leaks or extended downtime.

Insights from threat intelligence
Threat actors are increasingly targeting cloud environments due to the large amounts of sensitive data being stored and exchanged. Attackers mostly abuse leaked or weak credentials and misconfigurations to plan and execute their attacks on cloud environments. One particularly concerning trend is the surge of S3 ransomware attacks, which have been observed in the wild but are not yet publically linked to specific threat actors.

References

Threat hunting theses breakdown

S3 objects encrypted with a KMS key not owned by the organization

Relevant data sources

AWS Cloudtrail (with data events enabled)

Thesis explanation
Detects usage of the AWS API to replace each object in a bucket with a new copy of itself, but this time, it is encrypted with the attacker's KMS key. The KMS Key ARN contains an AWS Account ID, which is checked against AWS accounts found in the data collected by Hunters, to verify whether it’s an AWS account owned by the organization.

Blind spots
This thesis covers S3 ransomware using KMS keys not owned by the organization. A scenario where an attacker gains access to a KMS owned by the organization, and abuses it to execute his objectives, is not covered in this thesis.

Recommended investigation flow

Review the AWS account ID and the role of the user identity. Should it be allowed to access the bucket?
Which IP and user agent were used? Did the activity originate from a geo-location and user agent used by the organization?
Review the bucket policy and ACL, Who is allowed to access the bucket? Is there any misconfiguration like a ‘*’ principal or action?
Which API calls were used in order to encrypt the objects?
How many objects were encrypted?
Were other buckets or AWS resources accessed from the same IP or user identity ARN around lead time?

Hunting queries

https://gist.github.com/axon-git/daf33633d9dabe40ae293e1e571265e6

Recommended mitigations

Ensure the public access block is enabled for any non-public bucket.
Ensure only the needed actions and principals are allowed via bucket policy.
Create regular backups of critical data using S3 replication or AWS Backup.
Enable bucket versioning on critical buckets (gives you the ability to restore a particular version during the recovery process).
Consider configuring object lock on critical buckets (can help prevent objects from being deleted or overwritten for a fixed amount of time or indefinitely).
Create a KMS CMK (Customer Managed Key) and enforce its usage of it in any object upload via bucket policy (prevents unauthorized read and write access to principals that don’t have the necessary permissions on the CMK, and have usage auditing).
Configure Cloudtrail and GuardDuty on all S3 buckets. Consider enabling S3 Server Access Logs and Cloudtrail data events for critical buckets.

Hunters content

S3 Objects Encrypted with a KMS Key Not Owned by the Customer
A custom rule that increases confidence if CopyObject API was used to encrypt objects in a bucket