security-tools/sigma-rules
1
0
Fork 0
Code Issues Pull Requests Actions 3 Packages Projects Releases Wiki Activity

[Rule Tuning] Potential AWS S3 Bucket Ransomware Note Uploaded (#5657)

Browse Source 
* [Rule Tuning] Potential AWS S3 Bucket Ransomware Note Uploaded

This rule was very loud in telemetry since it's last tuning. ~8,938 alerts in last 24 hours. All false positives due to regex pattern matches for file names like `enc` as part of /filetransfertmsadherence/ and absence/; `lock` as part of citations-blocks/.

I've reworked this rule based on more research into common ransom note file name keywords and replaced the list here with the most common keywords. For `file` (the most common) and `back`, I was still seeing false positives so decided to alert on a combination of either or these 2 words in conjunction with any of the other words from the list. I also changed the regex to be case-insensitive.

With this new query, I see only true positive results within the last year all from known testing events.

I changed the toml file name so the rule looks new but it is just tuned.

I've updated the description and investigation guide, and added the study I used as a reference: https://www.mdpi.com/2073-431X/10/11/145#computers-10-00145-f002

Test data is in our stack, script for executing is here:

Screenshot of new working query in our test stack

* Apply suggestions from code review

* removing redundany regex pattern
This commit is contained in:
Isai
2026-02-05 21:34:38 -05:00
committed by GitHub
parent 64cca9e1ba
commit 1c59a6adde
1 changed files with 36 additions and 29 deletions
Download Patch File Download Diff File Expand all files Collapse all files
rules/integrations/aws/impact_s3_bucket_object_uploaded_with_ransom_extension.toml → rules/integrations/aws/impact_s3_bucket_object_uploaded_with_ransom_keyword.toml
+36 -29
View File
@@ -2,18 +2,18 @@
creation_date = "2024/04/17"
integration = ["aws"]
maturity = "production"
updated_date = "2026/01/16"
updated_date = "2026/01/30"
[rule]
author = ["Elastic"]
description = """
Identifies potential ransomware note being uploaded to an AWS S3 bucket. This rule detects the PutObject S3 API call
with a common ransomware note file name or extension such as ransom or .lock. Adversaries with access to a misconfigured
with an object name commonly associated with ransomware notes. The keywords detected here rarely overlap with common file names and have been attributed to ransomware notes with high-confidence. Adversaries with access to a misconfigured
S3 bucket may retrieve, delete, and replace objects with ransom notes to extort victims.
"""
false_positives = [
"""
Administrators may legitimately access, delete, and replace objects in S3 buckets. Ensure that the uploaded files are not part of a legitimate operation before taking action.
This rule uses matches regex patterns for common ransom note file names. Ensure that the uploaded file is not part of a legitimate operation before taking action.
""",
]
from = "now-6m"
@@ -26,38 +26,45 @@ note = """
### Investigating Potential AWS S3 Bucket Ransomware Note Uploaded
This rule detects a successful `PutObject` to S3 where the object key matches common ransomware-note patterns (for example, `readme`, `how_to_decrypt`, `decrypt_instructions`, `ransom`, `lock`). Attackers who obtain credentials or abuse overly-permissive bucket policies can upload ransom notes (often after deleting or encrypting data).
This rule detects a successful `PutObject` to S3 where the object key matches common ransomware-note patterns (for example, `readme`, `decrypt`, `ransom`, and combinations with `file`). Attackers who obtain credentials or abuse overly-permissive bucket policies can upload ransom notes (often after deleting or encrypting data).
#### Possible Investigation Steps:
- **Confirm the actor and session details.** Review `aws.cloudtrail.user_identity.*` (ARN, type, access key, session context), `source.ip`, `user.agent`, and `tls.client.server_name` to identify *who* performed the upload and *from where*. Validate whether this principal typically writes to this bucket.
### Possible investigation steps
- **Inspect the object key and bucket context.** From `aws.cloudtrail.request_parameters`, capture the exact `key` and `bucketName`. Check whether the key is publicly readable (ACL), whether the bucket is internet-exposed, and whether replication or lifecycle rules could propagate or remove related objects.
**Confirm the actor and session details**
- Review `aws.cloudtrail.user_identity.*` (ARN, type, access key, session context), `source.ip`, `user.agent`, and `tls.client.server_name` to identify who performed the upload and from where. Validate whether this principal typically writes to this bucket.
- **Pivot to related S3 activity around the same time.** Look for `DeleteObject`/`DeleteObjects`, mass `PutObject` spikes, `PutBucketPolicy`, `PutPublicAccessBlock`, `PutBucketVersioning`, and `PutBucketLifecycleConfiguration` events on the same bucket or by the same actor to determine if data destruction, policy tampering, or guard-rail changes occurred.
**Inspect the object key and bucket context**
- From `aws.cloudtrail.request_parameters`, capture the exact `key` and `bucketName`. Check whether the key is publicly readable (ACL), whether the bucket is internet-exposed, and whether replication or lifecycle rules could propagate or remove related objects.
- **Assess blast radius across the account.** Search recent CloudTrail for the same actor/IP touching other buckets, KMS keys used by those buckets, and IAM changes (new access keys, policy attachments, role assumptions) that could indicate broader compromise paths consistent with ransomware playbooks.
**Pivot to related S3 activity around the same time**
- Look for `DeleteObject`/`DeleteObjects`, mass `PutObject` spikes, `PutBucketPolicy`, `PutPublicAccessBlock`, `PutBucketVersioning`, and `PutBucketLifecycleConfiguration` events on the same bucket or by the same actor to determine if data destruction, policy tampering, or guard-rail changes occurred.
- **Check protections and recovery posture on the bucket.** Verify whether S3 Versioning and (if in use) Object Lock legal hold are enabled; note prior versions available for the affected key, and whether lifecycle rules might expire them.
**Assess blast radius across the account**
- Search recent CloudTrail for the same actor/IP touching other buckets, KMS keys used by those buckets, and IAM changes (new access keys, policy attachments, role assumptions) that could indicate broader compromise paths consistent with ransomware playbooks.
- **Correlate with threat signals.** Review other related alerts, GuardDuty S3-related findings, AWS Config drift on the bucket and its policy, and any SOAR/IR runbook executions tied to ransomware triage.
**Check protections and recovery posture on the bucket**
- Verify whether S3 Versioning and (if in use) Object Lock legal hold are enabled; note prior versions available for the affected key, and whether lifecycle rules might expire them.
### False Positive Analysis:
- **Planned tests or red-team exercises.** Confirm change tickets or test windows for staging/dev buckets; red teams often drop “ransom-note-like” files during exercises.
- **Benign automation naming.** Some data-migration or backup tools may use “readme”/“recovery”-style filenames; validate by `user.agent`, principal, and target environment (dev vs prod).
- **Log/archive buckets.** Exclude infrastructure/logging buckets (for example, `AWSLogs`, CloudTrail, access logs) per rule guidance to reduce noise.
**Correlate with threat signals**
- Review other related alerts, GuardDuty S3-related findings, AWS Config drift on the bucket and its policy, and any SOAR/IR runbook executions tied to ransomware triage.
### Response and Remediation:
### False positive analysis
- Planned tests or red-team exercises
- Benign automation naming. Some data-migration or backup tools may use “readme”/“recovery”-style filenames; validate by `user.agent`, principal, and target environment (dev vs prod).
### Response and remediation
**Immediate, low-risk actions (safe for most environments)**
- **Preserve context:** Export the triggering `PutObject` CloudTrail record(s), plus 15–30 min before/after, to an evidence bucket (restricted access).
- **Snapshot configuration:** Record current bucket settings (Block Public Access, Versioning, Object Lock, Bucket Policy, Lifecycle rules) and any KMS keys used.
- **Quiet the spread:** Pause destructive automation: disable/bypass lifecycle rules that would expire/delete object versions; temporarily pause data pipelines targeting the bucket.
- **Notify owners:** Inform the bucket/application owner(s) and security leadership.
- **Preserve context** : Export the triggering `PutObject` CloudTrail record(s), plus 15–30 min before/after, to an evidence bucket (restricted access).
- **Snapshot configuration** : Record current bucket settings (Block Public Access, Versioning, Object Lock, Bucket Policy, Lifecycle rules) and any KMS keys used.
- **Quiet the spread** : Pause destructive automation: disable/bypass lifecycle rules that would expire/delete object versions; temporarily pause data pipelines targeting the bucket.
- **Notify owners** : Inform the bucket/application owner(s) and security leadership.
**Containment options (choose the least disruptive first)**
- **Harden exposure:** If not already enforced, enable `Block Public Access` for the bucket.
- **Targeted deny policy (temporary):** Add a restrictive bucket policy allowing only IR/admin roles while you scope impact. Reconfirm critical workload dependencies before applying.
- **Credential risk reduction:** If a specific IAM user/key or role is implicated, rotate access keys; for roles, remove risky policy attachments or temporarily restrict with an SCP/deny statement.
- **Harden exposure** : If not already enforced, enable `Block Public Access` for the bucket.
- **Targeted deny policy (temporary)** : Add a restrictive bucket policy allowing only IR/admin roles while you scope impact. Reconfirm critical workload dependencies before applying.
- **Credential risk reduction** : If a specific IAM user/key or role is implicated, rotate access keys; for roles, remove risky policy attachments or temporarily restrict with an SCP/deny statement.
**Evidence preservation**
- Export relevant CloudTrail events, S3 server/access logs (if enabled), AWS Config history for the bucket/policy, and the suspicious object plus its previous versions (if Versioning is enabled).
@@ -77,11 +84,9 @@ This rule detects a successful `PutObject` to S3 where the object key matches co
- Ensure continuous CloudTrail data events for S3 are enabled in covered regions; enable/verify GuardDuty S3 protections and alerts routing.
- Add detections for related behaviors (policy tampering, bulk deletes, versioning/lifecycle toggles) and create allowlists for known maintenance windows.
**Communication & escalation**
- If you have an IR team/provider: escalate with the evidence bundle and a summary (bucket/key, actor, protections, related activity, business impact).
- If you do not have an IR team: designate an internal incident lead, track actions/time, and follow these steps conservatively. Favor reversible controls (temporary deny, key rotation) over invasive changes.
### Additional Information:
### Additional information
- For further guidance on managing S3 bucket security and protecting against ransomware, refer to the [AWS S3 documentation](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) and AWS best practices for security.
- [AWS IRP—Ransomware](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/IRP-Ransomware.md) (NIST-aligned template for evidence, containment, eradication, recovery, post-incident).
- [AWS Customer Playbook—Ransom Response (S3)](https://github.com/aws-samples/aws-customer-playbook-framework/blob/a8c7b313636b406a375952ac00b2d68e89a991f2/docs/Ransom_Response_S3.md) (bucket-level response steps: public access blocks, temporary deny, versioning/object lock, lifecycle considerations, recovery).
@@ -90,6 +95,7 @@ This rule detects a successful `PutObject` to S3 where the object key matches co
references = [
"https://stratus-red-team.cloud/attack-techniques/AWS/aws.impact.s3-ransomware-batch-deletion/",
"https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/",
"https://www.mdpi.com/2073-431X/10/11/145#computers-10-00145-f002",
]
risk_score = 47
rule_id = "7fda9bb2-fd28-11ee-85f9-f661ea17fbce"
@@ -114,8 +120,9 @@ file where
event.action == "PutObject" and
event.outcome == "success" and
/* Apply regex to match patterns only after the bucket name */
aws.cloudtrail.resources.arn regex "arn:aws:s3:::[^/]+/.*?(ransom|lock|crypt|enc|readme|how_to_decrypt|decrypt_instructions|recovery|datarescue).*" and
not aws.cloudtrail.resources.arn regex ".*(AWSLogs|CloudTrail|access-logs).*"
/* common ransom note file name keywords */
aws.cloudtrail.resources.arn regex~ "arn:aws:s3:::[^/]+/.*?(how|decrypt|restor|help|instruct|read|get|recov|save|encrypt|info|ransom).*"
and not aws.cloudtrail.resources.arn regex~ ".*(AWSLogs|CloudTrail|access-logs).*"
'''
[rule.investigation_fields]