You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
No major query logic changes needed. This rule is performing as expected in telemetry, known to be a bit noisier in development environments where bucket configuration changes and deletions happen often.
- updated Description and IG
- reduced execution window
- updated MITRE mapping
- updated tags
- added highlighted fields
Amazon S3 is a scalable storage service where configurations like policies, replication, and encryption ensure data security and compliance. Adversaries may delete these configurations to evade defenses, disrupt data protection, or conceal malicious activities. The detection rule monitors successful deletions of these configurations, signaling potential defense evasion attempts by correlating specific CloudTrail events.
38
+
Amazon S3 is a scalable storage service where configurations like policies, replication, and encryption ensure data security and compliance. The detection rule monitors successful deletions of these configurations via the following APIs: `DeleteBucketPolicy`, `DeleteBucketReplication`, `DeleteBucketCors`, `DeleteBucketEncryption` or `DeleteBucketLifecycle`. These operations can be used by an adversary to remove visibility, erase governance or compliance controls, or prepare a bucket for destructive or exfiltration activity.
39
+
Deleting or disabling important configurations may hamper audit trails, hide malicious changes, or reduce the ability for recovery. The detection of these deletes is therefore a potential indicator of defense evasion or impact techniques.
31
40
32
-
### Possible investigation steps
41
+
#### Possible investigation steps
33
42
34
-
- Review the CloudTrail logs for the specific event.provider:s3.amazonaws.com and event.action values to identify the user or role responsible for the deletion actions.
35
-
- Examine the event.outcome:success field to confirm that the deletion actions were completed successfully and not attempted or failed.
36
-
- Investigate the IAM policies and permissions associated with the user or role identified to determine if they have legitimate access to perform such deletions.
37
-
- Check for any recent changes in IAM roles or policies that might have inadvertently granted excessive permissions.
38
-
- Correlate the timing of the deletion events with other suspicious activities or alerts in the AWS environment to identify potential patterns or coordinated actions.
39
-
- Assess the impact of the deleted configurations on data security and compliance, and determine if any critical data protection mechanisms were affected.
43
+
- **Identify the Actor and Context**
44
+
- Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.access_key_id` and `aws.cloudtrail.user_identity.type` to identify who performed the deletion.
45
+
- Determine whether the actor typically manages bucket configurations, or if this is an unusual identity for this kind of operation.
46
+
- Check `source.ip`, `user_agent.original`, `cloud.region` for anomalous behaviour (unfamiliar IPs, new tooling or region, off-hours actions).
47
+
48
+
- **Determine the Affected Bucket and Configuration Type**
49
+
- Examine `aws.cloudtrail.request_parameters` (and `aws.cloudtrail.resources.arn`) to identify the bucket and the sub-resource that was removed.
50
+
- Determine whether the bucket is used for critical data (audit logs, backups, data warehouse). If so, the deletion is higher risk.
51
+
52
+
- **Correlate with Other Activity to Establish Chain of Events**
53
+
- Search for preceding or concurrent CloudTrail events by the same actor or on the same bucket, e.g.:
54
+
- Removal of logging or access controls (`PutBucketLogging`, `PutBucketAcl`, `PutBucketPolicy`).
55
+
- Object-level actions soon after configuration removal (`DeleteObject`, `DeleteObjects`, `PutObject`, cross-account copy) that suggest data removal or exfiltration.
56
+
- Review for configuration additions or changes immediately prior (e.g., versioning disabled, replication removed) — could form part of a larger attack sequence.
57
+
58
+
- **Evaluate Intent and Risk**
59
+
- Confirm whether the change is aligned with an approved change control process (maintenance, re-architecting, cost-optimization).
60
+
- If no documented justification, or if it affects buckets with sensitive or compliance-related data, treat it as potential malicious behavior.
61
+
- Prioritize buckets where configuration deletion significantly reduces visibility or recovery capability.
40
62
41
63
### False positive analysis
42
64
43
-
- Routine administrative actions by authorized personnel may trigger alerts when they update or remove bucket configurations as part of regular maintenance. To manage this, create exceptions for specific user roles or IAM users known to perform these tasks regularly.
44
-
- Automated scripts or tools used for infrastructure management might delete and recreate bucket configurations as part of their operation. Identify these scripts and exclude their associated actions from triggering alerts by using specific identifiers or tags.
45
-
- Scheduled policy updates or compliance checks that involve temporary removal of configurations can also result in false positives. Implement time-based exceptions for these known activities to prevent unnecessary alerts.
46
-
- Development and testing environments often undergo frequent configuration changes, which can mimic suspicious behavior. Exclude these environments from the rule by using environment-specific tags or identifiers.
65
+
- **Scheduled Maintenance or Re-architecture**:
66
+
- Valid operations may include migrating buckets, retiring services, or reorganizing storage; verify through change logs.
67
+
- **Automation/DevOps Activity**:
68
+
- Infrastructure-as-Code pipelines or lifecycle clean-up tasks may remove configurations; validate known automation scopes and service-principals.
69
+
- **Test/Development Buckets**:
70
+
- Non-production environments may frequently change bucket configurations; document and consider whitelisting accordingly.
47
71
48
72
### Response and remediation
49
73
50
-
- Immediately revoke any unauthorized access to the affected S3 bucket by reviewing and updating the bucket's access policies and permissions.
51
-
- Restore the deleted configurations by applying the latest known good configuration settings for policies, replication, encryption, and other affected components.
52
-
- Conduct a thorough audit of recent IAM activity to identify any unauthorized or suspicious actions related to the S3 bucket configurations.
53
-
- Escalate the incident to the security operations team for further investigation and to determine if additional AWS resources or accounts have been compromised.
54
-
- Implement additional monitoring and alerting for any future unauthorized configuration changes to S3 buckets, focusing on the specific actions identified in the detection rule.
55
-
- Review and enhance IAM policies to enforce the principle of least privilege, ensuring only authorized users have the necessary permissions to modify S3 bucket configurations.
56
-
- Coordinate with the incident response team to assess the impact of the configuration deletions on data security and compliance, and take necessary steps to mitigate any identified risks.
74
+
**1. Containment & Immediate Actions**
75
+
- Temporarily restrict the IAM user or role that performed the deletion, especially for `DeleteBucketPolicy`, `DeleteBucketEncryption`, or `DeleteBucketLifecycle`.
76
+
- Restore missing configurations as soon as possible (e.g., re-apply bucket policy, lifecycle rules, inventory configuration) to prevent further blind spots.
77
+
78
+
**2. Investigation & Scope Assessment**
79
+
- Using CloudTrail and S3 Data Events, check object‐level activity from the timeframe immediately before and after the configuration deletion. Look for bulk deletes, new uploads, or copies to external accounts.
80
+
- Check whether other buckets in the account suffered similar configuration changes – potentially part of a wider campaign.
57
81
58
-
## Setup
82
+
**3. Recovery & Hardening**
83
+
- Recover affected bucket configurations and ensure they match your organizational baseline and compliance standards (e.g., logging enabled, inventory configured, lifecycle rules active).
84
+
- Enable AWS Config rules such as `s3-bucket-policy-check`, `s3-bucket-lifecycle-configuration-check`, `s3-bucket-logging-enabled` to monitor for unauthorized changes.
85
+
- Apply least‐privilege for configuration deletion permissions; segregate duties so bucket config deletion can only be done via controlled workflows and require multi-step approval.
59
86
60
-
The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
87
+
**4. Lessons Learned & Prevention**
88
+
- Conduct a post-incident review to determine root cause (credential compromise, misconfigured automation, malicious insider) and strengthen monitoring, alerting and access controls accordingly.
0 commit comments