From 1c59a6addef8fbcc6934d194554205aabdfc6912 Mon Sep 17 00:00:00 2001 From: Isai <59296946+imays11@users.noreply.github.com> Date: Thu, 5 Feb 2026 21:34:38 -0500 Subject: [PATCH] [Rule Tuning] Potential AWS S3 Bucket Ransomware Note Uploaded (#5657) * [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 --- ..._object_uploaded_with_ransom_keyword.toml} | 65 ++++++++++--------- 1 file changed, 36 insertions(+), 29 deletions(-) rename rules/integrations/aws/{impact_s3_bucket_object_uploaded_with_ransom_extension.toml => impact_s3_bucket_object_uploaded_with_ransom_keyword.toml} (53%) diff --git a/rules/integrations/aws/impact_s3_bucket_object_uploaded_with_ransom_extension.toml b/rules/integrations/aws/impact_s3_bucket_object_uploaded_with_ransom_keyword.toml similarity index 53% rename from rules/integrations/aws/impact_s3_bucket_object_uploaded_with_ransom_extension.toml rename to rules/integrations/aws/impact_s3_bucket_object_uploaded_with_ransom_keyword.toml index d2aec5fd0..7b9446c87 100644 --- a/rules/integrations/aws/impact_s3_bucket_object_uploaded_with_ransom_extension.toml +++ b/rules/integrations/aws/impact_s3_bucket_object_uploaded_with_ransom_keyword.toml @@ -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]