Potential AWS S3 Bucket Ransomware Note Uploaded

  1[metadata]
  2creation_date = "2024/04/17"
  3integration = ["aws"]
  4maturity = "production"
  5updated_date = "2026/01/30"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Identifies potential ransomware note being uploaded to an AWS S3 bucket. This rule detects the PutObject S3 API call
 11with 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
 12S3 bucket may retrieve, delete, and replace objects with ransom notes to extort victims.
 13"""
 14false_positives = [
 15    """
 16    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.
 17    """,
 18]
 19from = "now-6m"
 20index = ["filebeat-*", "logs-aws.cloudtrail-*"]
 21language = "eql"
 22license = "Elastic License v2"
 23name = "Potential AWS S3 Bucket Ransomware Note Uploaded"
 24note = """
 25## Triage and analysis
 26
 27### Investigating Potential AWS S3 Bucket Ransomware Note Uploaded
 28
 29This 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).
 30
 31### Possible investigation steps
 32
 33**Confirm the actor and session details** 
 34- 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. 
 35
 36**Inspect the object key and bucket context** 
 37- 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. 
 38
 39**Pivot to related S3 activity around the same time** 
 40- 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. 
 41
 42**Assess blast radius across the account** 
 43- 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. 
 44
 45**Check protections and recovery posture on the bucket** 
 46- 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. 
 47
 48**Correlate with threat signals** 
 49- 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. 
 50
 51### False positive analysis
 52- Planned tests or red-team exercises
 53- 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). 
 54
 55
 56### Response and remediation
 57
 58**Immediate, low-risk actions (safe for most environments)**
 59- **Preserve context** : Export the triggering `PutObject` CloudTrail record(s), plus 15–30 min before/after, to an evidence bucket (restricted access). 
 60- **Snapshot configuration** : Record current bucket settings (Block Public Access, Versioning, Object Lock, Bucket Policy, Lifecycle rules) and any KMS keys used.
 61- **Quiet the spread** : Pause destructive automation: disable/bypass lifecycle rules that would expire/delete object versions; temporarily pause data pipelines targeting the bucket.
 62- **Notify owners** : Inform the bucket/application owner(s) and security leadership.
 63
 64**Containment options (choose the least disruptive first)**
 65- **Harden exposure** : If not already enforced, enable `Block Public Access` for the bucket.
 66- **Targeted deny policy (temporary)** : Add a restrictive bucket policy allowing only IR/admin roles while you scope impact. Reconfirm critical workload dependencies before applying.
 67- **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.
 68
 69**Evidence preservation**
 70- 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).
 71- Document actor ARN, source IPs, user agent(s), exact `bucketName`/`key`, and timestamps. Maintain a simple chain-of-custody note for collected artifacts.
 72
 73**Scope and hunting (same actor/time window)**
 74- Look for `DeleteObject(s)`, unusual `PutObject` volume, `PutBucketPolicy`, `PutPublicAccessBlock`, `PutBucketVersioning` changes, `PutBucketLifecycleConfiguration`, and cross-account access.
 75- Cross reference other buckets touched by the same actor/IP; recent IAM changes (new keys, policy/role edits); GuardDuty findings tied to S3/credentials.
 76
 77**Recovery (prioritize data integrity)**
 78- If Versioning is enabled, restore last known-good versions for impacted objects. Consider applying Object Lock legal hold to clean versions during recovery if configured.
 79- If Versioning is not enabled, recover from backups (AWS Backup, replication targets). Enable Versioning going forward on critical buckets; evaluate Object Lock for high-value data.
 80- Carefully remove any temporary deny policy only after credentials are rotated, policies re-validated, and no ongoing destructive activity is observed.
 81
 82**Post-incident hardening**
 83- Enforce `Block Public Access`, enable Versioning (and MFA-Delete where appropriate), and review bucket policies for least privilege.
 84- Ensure continuous CloudTrail data events for S3 are enabled in covered regions; enable/verify GuardDuty S3 protections and alerts routing.
 85- Add detections for related behaviors (policy tampering, bulk deletes, versioning/lifecycle toggles) and create allowlists for known maintenance windows.
 86
 87
 88### Additional information
 89
 90- 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.
 91- [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). 
 92- [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). 
 93"""
 94
 95references = [
 96    "https://stratus-red-team.cloud/attack-techniques/AWS/aws.impact.s3-ransomware-batch-deletion/",
 97    "https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/",
 98    "https://www.mdpi.com/2073-431X/10/11/145#computers-10-00145-f002",
 99]
100risk_score = 47
101rule_id = "7fda9bb2-fd28-11ee-85f9-f661ea17fbce"
102setup = "AWS S3 data types need to be enabled in the CloudTrail trail configuration to capture PutObject API calls."
103severity = "medium"
104tags = [
105    "Domain: Cloud",
106    "Data Source: AWS",
107    "Data Source: Amazon Web Services",
108    "Data Source: AWS S3",
109    "Use Case: Threat Detection",
110    "Tactic: Impact",
111    "Resources: Investigation Guide",
112]
113timestamp_override = "event.ingested"
114type = "eql"
115
116query = '''
117file where
118  event.dataset == "aws.cloudtrail" and
119  event.provider == "s3.amazonaws.com" and
120  event.action == "PutObject" and
121  event.outcome == "success" and
122  /* Apply regex to match patterns only after the bucket name */
123  /* common ransom note file name keywords */
124  aws.cloudtrail.resources.arn regex~ "arn:aws:s3:::[^/]+/.*?(how|decrypt|restor|help|instruct|read|get|recov|save|encrypt|info|ransom).*"
125  and not aws.cloudtrail.resources.arn regex~ ".*(AWSLogs|CloudTrail|access-logs).*"
126'''
127
128[rule.investigation_fields]
129field_names = [
130    "@timestamp",
131    "user.name",
132    "user_agent.original",
133    "source.ip",
134    "aws.cloudtrail.user_identity.arn",
135    "aws.cloudtrail.user_identity.type",
136    "aws.cloudtrail.user_identity.access_key_id",
137    "aws.cloudtrail.resources.arn",
138    "aws.cloudtrail.resources.type",
139    "tls.client.server_name",
140    "event.action",
141    "event.outcome",
142    "cloud.account.id",
143    "cloud.region",
144    "aws.cloudtrail.request_parameters",
145    "aws.cloudtrail.response_elements"
146]
147
148[[rule.threat]]
149framework = "MITRE ATT&CK"
150[[rule.threat.technique]]
151id = "T1485"
152name = "Data Destruction"
153reference = "https://attack.mitre.org/techniques/T1485/"
154
155[[rule.threat.technique]]
156id = "T1486"
157name = "Data Encrypted for Impact"
158reference =  "https://attack.mitre.org/techniques/T1486/"
159
160[rule.threat.tactic]
161id = "TA0040"
162name = "Impact"
163reference = "https://attack.mitre.org/tactics/TA0040/"