[Rule Tuning] Potential AWS S3 Bucket Ransomware Note Uploaded (#5149)
* [Rule Tuning] Potential AWS S3 Bucket Ransomware Note Uploaded - changed this from ESQL to EQL. While initially were only able to isolate uploaded file names using the `aws.cloudtrail.request_parameters` field, we now can use the target.entity.id field to isolate the uploaded file arn. I've adjusted the regex pattern to distinguish between the bucket name and the file uploaded, both of which are included in the target.entity.id field. - I chose eql instead of esql to 1. provide more meaningful alert context to the user and 2. allow for easier exclusions for the user. Right now these alerts aren't generating much meaningful context. - edits to description - new investigation guide using specific AWS IR Ransomware Playbooks as additional context - additional MITRE technique * added highlighted fields added highlighted fields * fixed MITRE reference * added cloudtrail index mapping * Update rules/integrations/aws/impact_s3_bucket_object_uploaded_with_ransom_extension.toml Co-authored-by: Jonhnathan <26856693+w0rk3r@users.noreply.github.com> * using aws.cloudtrail.resources.arn instead of target.entity.id using aws.cloudtrail.resources.arn instead of target.entity.id * Apply suggestions from code review --------- Co-authored-by: Jonhnathan <26856693+w0rk3r@users.noreply.github.com> Co-authored-by: shashank-elastic <91139415+shashank-elastic@users.noreply.github.com>
This commit is contained in:
Isai
+91
-67
@@ -2,70 +2,96 @@
|
||||
creation_date = "2024/04/17"
|
||||
integration = ["aws"]
|
||||
maturity = "production"
|
||||
updated_date = "2025/07/16"
|
||||
updated_date = "2025/09/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 extension such as `.ransom`, or `.lock`. Adversaries with access to a misconfigured
|
||||
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
|
||||
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 sequence of
|
||||
events is not part of a legitimate operation before taking action.
|
||||
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.
|
||||
""",
|
||||
]
|
||||
from = "now-9m"
|
||||
language = "esql"
|
||||
from = "now-6m"
|
||||
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
|
||||
language = "eql"
|
||||
license = "Elastic License v2"
|
||||
name = "Potential AWS S3 Bucket Ransomware Note Uploaded"
|
||||
note = """## Triage and analysis
|
||||
note = """
|
||||
## Triage and analysis
|
||||
|
||||
> **Disclaimer**:
|
||||
> 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.
|
||||
|
||||
### Investigating Potential AWS S3 Bucket Ransomware Note Uploaded
|
||||
|
||||
This rule detects the `PutObject` S3 API call with a common ransomware note file extension such as `.ransom`, or `.lock`. Adversaries with access to a misconfigured S3 bucket may retrieve, delete, and replace objects with ransom notes to extort victims.
|
||||
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).
|
||||
|
||||
#### Possible Investigation Steps:
|
||||
|
||||
- **Identify the Actor**: Review the `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` fields to identify who performed the action. Verify if this actor typically performs such actions and if they have the necessary permissions.
|
||||
- **Review the Request Details**: Examine the `aws.cloudtrail.request_parameters` to understand the specific details of the `PutObject` action. Look for any unusual parameters that could suggest unauthorized or malicious modifications.
|
||||
- **Analyze the Source of the Request**: Investigate the `source.ip` and `source.geo` fields to determine the geographical origin of the request. An external or unexpected location might indicate compromised credentials or unauthorized access.
|
||||
- **Contextualize with Timestamp**: Use the `@timestamp` field to check when the ransom note was uploaded. Changes during non-business hours or outside regular maintenance windows might require further scrutiny.
|
||||
- **Inspect the Ransom Note**: Review the `aws.cloudtrail.request_parameters` for the `PutObject` action to identify the characteristics of the uploaded ransom note. Look for common ransomware file extensions such as `.txt`, `.note`, `.ransom`, or `.html`.
|
||||
- **Correlate with Other Activities**: Search for related CloudTrail events before and after this action to see if the same actor or IP address engaged in other potentially suspicious activities.
|
||||
- **Check for Object Deletion or Access**: Look for `DeleteObject`, `DeleteObjects`, or `GetObject` API calls to the same S3 bucket that may indicate the adversary accessing and destroying objects before placing the ransom note.
|
||||
- **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.
|
||||
- **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.
|
||||
- **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.
|
||||
- **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.
|
||||
- **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.
|
||||
- **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.
|
||||
|
||||
### False Positive Analysis:
|
||||
|
||||
- **Legitimate Administrative Actions**: Confirm if the `PutObject` action aligns with scheduled updates, maintenance activities, or legitimate administrative tasks documented in change management systems.
|
||||
- **Consistency Check**: Compare the action against historical data of similar activities performed by the user or within the organization. If the action is consistent with past legitimate activities, it might indicate a false alarm.
|
||||
- **Verify through Outcomes**: Check the `aws.cloudtrail.response_elements` and the `event.outcome` to confirm if the upload was successful and intended according to policy.
|
||||
- **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.
|
||||
|
||||
### Response and Remediation:
|
||||
|
||||
- **Immediate Review and Reversal if Necessary**: If the activity was unauthorized, remove the uploaded ransom notes from the S3 bucket and review the bucket's access logs for any suspicious activity.
|
||||
- **Enhance Monitoring and Alerts**: Adjust monitoring systems to alert on similar `PutObject` actions, especially those involving sensitive data or unusual file extensions.
|
||||
- **Educate and Train**: Provide additional training to users with administrative rights on the importance of security best practices concerning S3 bucket management and the risks of ransomware.
|
||||
- **Audit S3 Bucket Policies and Permissions**: Conduct a comprehensive audit of all S3 bucket policies and associated permissions to ensure they adhere to the principle of least privilege.
|
||||
- **Incident Response**: If there's an indication of malicious intent or a security breach, initiate the incident response protocol to mitigate any damage and prevent future occurrences.
|
||||
**1. 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.
|
||||
|
||||
**2. 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.
|
||||
|
||||
**3. 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).
|
||||
- Document actor ARN, source IPs, user agent(s), exact `bucketName`/`key`, and timestamps. Maintain a simple chain-of-custody note for collected artifacts.
|
||||
|
||||
**4. Scope and hunting (same actor/time window)**
|
||||
- Look for `DeleteObject(s)`, unusual `PutObject` volume, `PutBucketPolicy`, `PutPublicAccessBlock`, `PutBucketVersioning` changes, `PutBucketLifecycleConfiguration`, and cross-account access.
|
||||
- Cross reference other buckets touched by the same actor/IP; recent IAM changes (new keys, policy/role edits); GuardDuty findings tied to S3/credentials.
|
||||
|
||||
**5. Recovery (prioritize data integrity)**
|
||||
- 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.
|
||||
- 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.
|
||||
- Carefully remove any temporary deny policy only after credentials are rotated, policies re-validated, and no ongoing destructive activity is observed.
|
||||
|
||||
**6. Post-incident hardening**
|
||||
- Enforce `Block Public Access`, enable Versioning (and MFA-Delete where appropriate), and review bucket policies for least privilege.
|
||||
- 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.
|
||||
|
||||
**7. 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:
|
||||
|
||||
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. Additionally, consult the following resources for specific details on S3 ransomware protection:
|
||||
- [ERMETIC REPORT - AWS S3 Ransomware Exposure in the Wild](https://s3.amazonaws.com/bizzabo.file.upload/PtZzA0eFQwV2RA5ysNeo_ERMETIC%20REPORT%20-%20AWS%20S3%20Ransomware%20Exposure%20in%20the%20Wild.pdf)
|
||||
- [AWS S3 Ransomware Batch Deletion](https://stratus-red-team.cloud/attack-techniques/AWS/aws.impact.s3-ransomware-batch-deletion/)
|
||||
- [S3 Ransomware Part 1: Attack Vector](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)
|
||||
- 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).
|
||||
"""
|
||||
|
||||
references = [
|
||||
"https://s3.amazonaws.com/bizzabo.file.upload/PtZzA0eFQwV2RA5ysNeo_ERMETIC%20REPORT%20-%20AWS%20S3%20Ransomware%20Exposure%20in%20the%20Wild.pdf",
|
||||
"https://stratus-red-team.cloud/attack-techniques/AWS/aws.impact.s3-ransomware-batch-deletion/",
|
||||
"https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/",
|
||||
]
|
||||
risk_score = 47
|
||||
rule_id = "7fda9bb2-fd28-11ee-85f9-f661ea17fbce"
|
||||
setup = "AWS S3 data types need to be enabled in the CloudTrail trail configuration."
|
||||
setup = "AWS S3 data types need to be enabled in the CloudTrail trail configuration to capture PutObject API calls."
|
||||
severity = "medium"
|
||||
tags = [
|
||||
"Domain: Cloud",
|
||||
@@ -77,44 +103,38 @@ tags = [
|
||||
"Resources: Investigation Guide",
|
||||
]
|
||||
timestamp_override = "event.ingested"
|
||||
type = "esql"
|
||||
type = "eql"
|
||||
|
||||
query = '''
|
||||
from logs-aws.cloudtrail-*
|
||||
|
||||
// any successful uploads via S3 API requests
|
||||
| where
|
||||
event.dataset == "aws.cloudtrail"
|
||||
and event.provider == "s3.amazonaws.com"
|
||||
and event.action == "PutObject"
|
||||
and event.outcome == "success"
|
||||
|
||||
// extract object key from API request parameters
|
||||
| dissect aws.cloudtrail.request_parameters "%{?ignore_values}key=%{Esql.aws_cloudtrail_request_parameters_object_key}}"
|
||||
|
||||
// regex match against common ransomware naming patterns
|
||||
| where
|
||||
Esql.aws_cloudtrail_request_parameters_object_key rlike "(.*)(ransom|lock|crypt|enc|readme|how_to_decrypt|decrypt_instructions|recovery|datarescue)(.*)"
|
||||
and not Esql.aws_cloudtrail_request_parameters_object_key rlike "(.*)(AWSLogs|CloudTrail|access-logs)(.*)"
|
||||
|
||||
// keep relevant ECS and derived fields
|
||||
| keep
|
||||
tls.client.server_name,
|
||||
aws.cloudtrail.user_identity.arn,
|
||||
Esql.aws_cloudtrail_request_parameters_object_key
|
||||
|
||||
// aggregate by server name, actor, and object key
|
||||
| stats
|
||||
Esql.event_count = count(*)
|
||||
by
|
||||
tls.client.server_name,
|
||||
aws.cloudtrail.user_identity.arn,
|
||||
Esql.aws_cloudtrail_request_parameters_object_key
|
||||
|
||||
// filter for rare single uploads (likely test/detonation)
|
||||
| where Esql.event_count == 1
|
||||
file where
|
||||
event.dataset == "aws.cloudtrail" and
|
||||
event.provider == "s3.amazonaws.com" and
|
||||
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).*"
|
||||
'''
|
||||
|
||||
[rule.investigation_fields]
|
||||
field_names = [
|
||||
"@timestamp",
|
||||
"user.name",
|
||||
"user_agent.original",
|
||||
"source.ip",
|
||||
"aws.cloudtrail.user_identity.arn",
|
||||
"aws.cloudtrail.user_identity.type",
|
||||
"aws.cloudtrail.user_identity.access_key_id",
|
||||
"aws.cloudtrail.resources.arn",
|
||||
"aws.cloudtrail.resources.type",
|
||||
"tls.client.server_name",
|
||||
"event.action",
|
||||
"event.outcome",
|
||||
"cloud.account.id",
|
||||
"cloud.region",
|
||||
"aws.cloudtrail.request_parameters",
|
||||
"aws.cloudtrail.response_elements"
|
||||
]
|
||||
|
||||
[[rule.threat]]
|
||||
framework = "MITRE ATT&CK"
|
||||
@@ -123,6 +143,10 @@ id = "T1485"
|
||||
name = "Data Destruction"
|
||||
reference = "https://attack.mitre.org/techniques/T1485/"
|
||||
|
||||
[[rule.threat.technique]]
|
||||
id = "T1486"
|
||||
name = "Data Encrypted for Impact"
|
||||
reference = "https://attack.mitre.org/techniques/T1486/"
|
||||
|
||||
[rule.threat.tactic]
|
||||
id = "TA0040"
|
||||
|
||||
Reference in New Issue
Block a user