Potential AWS S3 Bucket Ransomware Note Uploaded

  1[metadata]
  2creation_date = "2024/04/17"
  3integration = ["aws"]
  4maturity = "production"
  5updated_date = "2025/09/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 a common ransomware note file name or extension such as ransom or .lock. 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    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.
 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> **Disclaimer**:
 28> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
 29
 30### Investigating Potential AWS S3 Bucket Ransomware Note Uploaded
 31
 32This 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).
 33
 34#### Possible Investigation Steps:
 35- **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. 
 36- **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. 
 37- **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. 
 38- **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. 
 39- **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. 
 40- **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. 
 41
 42### False Positive Analysis:
 43- **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. 
 44- **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). 
 45- **Log/archive buckets.** Exclude infrastructure/logging buckets (for example, `AWSLogs`, CloudTrail, access logs) per rule guidance to reduce noise. 
 46
 47### Response and Remediation:
 48
 49**1. Immediate, low-risk actions (safe for most environments)**
 50- **Preserve context:** Export the triggering `PutObject` CloudTrail record(s), plus 15–30 min before/after, to an evidence bucket (restricted access). 
 51- **Snapshot configuration:** Record current bucket settings (Block Public Access, Versioning, Object Lock, Bucket Policy, Lifecycle rules) and any KMS keys used.
 52- **Quiet the spread:** Pause destructive automation: disable/bypass lifecycle rules that would expire/delete object versions; temporarily pause data pipelines targeting the bucket.
 53- **Notify owners:** Inform the bucket/application owner(s) and security leadership.
 54
 55**2. Containment options (choose the least disruptive first)**
 56- **Harden exposure:** If not already enforced, enable `Block Public Access` for the bucket.
 57- **Targeted deny policy (temporary):** Add a restrictive bucket policy allowing only IR/admin roles while you scope impact. Reconfirm critical workload dependencies before applying.
 58- **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.
 59
 60**3. Evidence preservation**
 61- 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).
 62- Document actor ARN, source IPs, user agent(s), exact `bucketName`/`key`, and timestamps. Maintain a simple chain-of-custody note for collected artifacts.
 63
 64**4. Scope and hunting (same actor/time window)**
 65- Look for `DeleteObject(s)`, unusual `PutObject` volume, `PutBucketPolicy`, `PutPublicAccessBlock`, `PutBucketVersioning` changes, `PutBucketLifecycleConfiguration`, and cross-account access.
 66- Cross reference other buckets touched by the same actor/IP; recent IAM changes (new keys, policy/role edits); GuardDuty findings tied to S3/credentials.
 67
 68**5. Recovery (prioritize data integrity)**
 69- 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.
 70- 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.
 71- Carefully remove any temporary deny policy only after credentials are rotated, policies re-validated, and no ongoing destructive activity is observed.
 72
 73**6. Post-incident hardening**
 74- Enforce `Block Public Access`, enable Versioning (and MFA-Delete where appropriate), and review bucket policies for least privilege.
 75- Ensure continuous CloudTrail data events for S3 are enabled in covered regions; enable/verify GuardDuty S3 protections and alerts routing.
 76- Add detections for related behaviors (policy tampering, bulk deletes, versioning/lifecycle toggles) and create allowlists for known maintenance windows.
 77
 78**7. Communication & escalation**
 79- If you have an IR team/provider: escalate with the evidence bundle and a summary (bucket/key, actor, protections, related activity, business impact).
 80- 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.
 81
 82### Additional Information:
 83- 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.
 84- [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). 
 85- [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). 
 86"""
 87
 88references = [
 89    "https://stratus-red-team.cloud/attack-techniques/AWS/aws.impact.s3-ransomware-batch-deletion/",
 90    "https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/",
 91]
 92risk_score = 47
 93rule_id = "7fda9bb2-fd28-11ee-85f9-f661ea17fbce"
 94setup = "AWS S3 data types need to be enabled in the CloudTrail trail configuration to capture PutObject API calls."
 95severity = "medium"
 96tags = [
 97    "Domain: Cloud",
 98    "Data Source: AWS",
 99    "Data Source: Amazon Web Services",
100    "Data Source: AWS S3",
101    "Use Case: Threat Detection",
102    "Tactic: Impact",
103    "Resources: Investigation Guide",
104]
105timestamp_override = "event.ingested"
106type = "eql"
107
108query = '''
109file where
110  event.dataset == "aws.cloudtrail" and
111  event.provider == "s3.amazonaws.com" and
112  event.action == "PutObject" and
113  event.outcome == "success" and
114  /* Apply regex to match patterns only after the bucket name */
115  aws.cloudtrail.resources.arn regex "arn:aws:s3:::[^/]+/.*?(ransom|lock|crypt|enc|readme|how_to_decrypt|decrypt_instructions|recovery|datarescue).*" and
116  not aws.cloudtrail.resources.arn regex ".*(AWSLogs|CloudTrail|access-logs).*"
117'''
118
119[rule.investigation_fields]
120field_names = [
121    "@timestamp",
122    "user.name",
123    "user_agent.original",
124    "source.ip",
125    "aws.cloudtrail.user_identity.arn",
126    "aws.cloudtrail.user_identity.type",
127    "aws.cloudtrail.user_identity.access_key_id",
128    "aws.cloudtrail.resources.arn",
129    "aws.cloudtrail.resources.type",
130    "tls.client.server_name",
131    "event.action",
132    "event.outcome",
133    "cloud.account.id",
134    "cloud.region",
135    "aws.cloudtrail.request_parameters",
136    "aws.cloudtrail.response_elements"
137]
138
139[[rule.threat]]
140framework = "MITRE ATT&CK"
141[[rule.threat.technique]]
142id = "T1485"
143name = "Data Destruction"
144reference = "https://attack.mitre.org/techniques/T1485/"
145
146[[rule.threat.technique]]
147id = "T1486"
148name = "Data Encrypted for Impact"
149reference =  "https://attack.mitre.org/techniques/T1486/"
150
151[rule.threat.tactic]
152id = "TA0040"
153name = "Impact"
154reference = "https://attack.mitre.org/tactics/TA0040/"