Skip to content

[Rule Tuning] AWS S3 Bucket Server Access Logging Disabled #5254

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
+78 −32
Open

[Rule Tuning] AWS S3 Bucket Server Access Logging Disabled #5254

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
110 changes: 78 additions & 32 deletions rules/integrations/aws/defense_evasion_s3_bucket_server_access_logging_disabled.toml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,20 +2,21 @@
creation_date = "2024/07/12"
integration = ["aws"]
maturity = "production"
updated_date = "2025/01/15"
updated_date = "2025/10/27"

[rule]
author = ["Elastic"]
description = """
Identifies when server access logging is disabled for an Amazon S3 bucket. Server access logs provide a detailed record of requests made to an S3 bucket.
When server access logging is disabled for a bucket, it could indicate an adversary's attempt to impair defenses by disabling logs that contain evidence of malicious activity.
Identifies when server access logging is disabled for an Amazon S3 bucket. Server access logs provide a detailed record
of requests made to an S3 bucket. When server access logging is disabled for a bucket, it could indicate an adversary's
attempt to impair defenses by disabling logs that contain evidence of malicious activity.
"""
event_category_override = "event.type"
false_positives = [
"""
Bucket logging may be disabled by a system or network administrator. Verify whether the user identity and/or
user agent should be making changes in your environment. Bucket component deletions by unfamiliar
users should be investigated. If known behavior is causing false positives, it can be exempted from the
rule.
Bucket logging may be disabled by a system or network administrator. Verify whether the user identity and/or user
agent should be making changes in your environment. Bucket component deletions by unfamiliar users should be
investigated. If known behavior is causing false positives, it can be exempted from the rule.
""",
]
from = "now-6m"
Expand All @@ -24,42 +25,66 @@ language = "eql"
license = "Elastic License v2"
name = "AWS S3 Bucket Server Access Logging Disabled"
note = """

## Triage and analysis

### Investigating AWS S3 Bucket Server Access Logging Disabled

This rule detects when server access logging is disabled for an S3 bucket in AWS. Such configurations could potentially hide evidence of unauthorized access or malicious activity by preventing the recording of those requests.
> **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.

This detection alerts when the server-access logging configuration for an S3 bucket is changed so that logging is disabled.
Because detailed request logs are central to tracking object access, modifications here are significant from a visibility and forensics standpoint. They can signal that an adversary is preparing to act (exfiltrate, delete, or manipulate data) while minimizing audit evidence.

#### Possible investigation steps

**Identify the actor and context**
- Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and `aws.cloudtrail.user_identity.access_key_id` to determine the who/what of the change.
- Inspect `user_agent.original`, `source.ip`, `@timestamp`, `cloud.account.id`, `cloud.region` for unusual or non-standard access patterns (e.g., new user, external IP, off-hours).
- Check the bucket resource (via `aws.cloudtrail.resources.arn`, `aws.cloudtrail.resources.type`) to determine the bucket’s business role (e.g., logs, backups, sensitive data store).
- Consider whether the bucket houses audit logs or access logs; if so, disabling logging is especially suspicious and a higher risk.

**Correlate with related activities**
- Search for preceding or subsequent events by the same principal or for the same bucket:
- `DeleteObject`, `PutBucketAcl`, `PutBucketPolicy`, `RemoveBucketAccessPoint`, or other permissions changes (e.g., `PutBucketLifecycle`).
- `ListBucket`, `GetObject`, `CopyObject`, or large `GetObject` operations, especially from unusual IPs or cross-account.
- IAM changes in proximity: `AttachUserPolicy`, `CreateAccessKey`, `AssumeRole` by same principal or against the same principal.
- Review AWS Config or Audit logs to see if the bucket’s logging was previously enabled and how long it has been disabled.

**Evaluate intent and risk**
- If the bucket was being used to collect access logs or audit data, disabling logging significantly degrades forensic capability.
- Determine whether the actor has a legitimate business reason for modifying logging (ticket, change request, known automation).
- If not justified, treat this as a high-priority visibility compromise and proceed through escalation.

#### Detailed Investigation Steps
### False positive analysis

- **Review the Affected S3 Bucket**: Check the bucket details (`bucketName`) where server access logging has been disabled.
- Determine the contents and importance of the data stored in this bucket to assess the impact of disabled logging.
- **Review User Identity and Activity**:
- Investigate the user (`user_identity.arn`) who made the change. Determine whether this user's role typically involves managing S3 bucket configurations.
- Examine the authentication method and whether the access key used (`access_key_id`) is routinely used for such configurations or if it has deviated from normal usage patterns.
- Contact the account owner and confirm whether they are aware of this activity.
- Considering the source IP address and geolocation of the user who issued the command:
- Do they look normal for the calling user?
- If the source is an EC2 IP address, is it associated with an EC2 instance in one of your accounts or is the source IP from an EC2 instance that's not under your control?
- If it is an authorized EC2 instance, is the activity associated with normal behavior for the instance role or roles? Are there any other alerts or signs of suspicious activity involving this instance?
- **Contextualize with Recent Changes**: Compare this event against recent changes in S3 configurations. Look for any other recent permissions changes or unusual administrative actions.
- **Correlate with Other Activities**: Search for related CloudTrail events before and after this change to see if the same actor or IP address engaged in other potentially suspicious activities.
- Assess whether this behavior is prevalent in the environment by looking for similar occurrences involving other users.
- Storage teams may disable logging temporarily during migration or cost-optimisation exercises.
- Test or development buckets may routinely toggle logging for experimentation—document such buckets and roles.
- Trusted automation (tagged, known user-agent, internal IPs) may adjust logging. Consider allow-listing such automation while preserving watch-points for changes to high-sensitivity buckets.

### False Positive Analysis
### Response and remediation

- Verify the operational requirements that might necessitate disabling access logging, especially in environments where data retention policies are strictly governed for compliance and cost-saving reasons.
**1. Contain & restore visibility**
- Immediately re-enable server‐access logging for the affected bucket (ensure `LoggingEnabled=true` and correct `TargetBucket/Prefix`).
- If you suspect activity while logging was disabled, preserve any remaining object versions, cross-account access logs, or S3 Inventory data.

### Response and Remediation
**2. Investigate scope and impact**
- Use CloudTrail Lake or Athena to query access to the bucket and objects for the timeframe when logging was disabled.
- Identify external IP addresses, unusual principals, or rapid object transfers or deletions.

- **Immediate Review**: If the change was unauthorized, consider reverting the change immediately to prevent potential data loss.
- **Enhance Monitoring**: Implement monitoring to alert on changes to logging configurations across your S3 environments.
- **User Education**: Ensure that users with access to critical resources like S3 buckets are aware of the best practices and company policies regarding data retention and security.
**3. Recover & harden**
- Apply bucket-policy or SCP restrictions to prevent unauthorized modifications of `PutBucketLogging` for audit/logging buckets.
- Enable AWS Config rule (e.g., `cloudtrail-s3-bucket-access-logging`) to alert if logging is disabled.
- Ensure logging target buckets are configured with retention, versioning, and immutability (S3 Object Lock) to prevent tampering.

### Additional Information
**4. Improve & monitor**
- Update your incident response playbook to include this scenario (see AWS IR + Customer Playbook Framework).
- Educate stakeholders (storage, DevOps, security) that any change to logging configuration on buckets — especially audit/log buckets should be treated as a security event and ticketed.

For further guidance on monitoring Amazon S3 and ensuring compliance with organizational data retention and security policies, refer to the AWS official documentation on [Monitoring Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/monitoring-overview.html).
### Additional information

- AWS documentation on [S3 Server Access Logging](https://docs.aws.amazon.com/AmazonS3/latest/userguide/ServerLogs.html)
- [AWS Incident Response Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/tree/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks)
- [AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs)
"""
references = [
"https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketLogging.html",
Expand All @@ -81,7 +106,8 @@ timestamp_override = "event.ingested"
type = "eql"

query = '''
any where event.dataset == "aws.cloudtrail"
info where event.dataset == "aws.cloudtrail"
and event.provider == "s3.amazonaws.com"
and event.action == "PutBucketLogging"
and event.outcome == "success"
and not stringContains(aws.cloudtrail.request_parameters, "LoggingEnabled")
Expand All @@ -99,8 +125,28 @@ id = "T1562.008"
name = "Disable or Modify Cloud Logs"
reference = "https://attack.mitre.org/techniques/T1562/008/"



[rule.threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"

[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",
"event.action",
"event.outcome",
"cloud.account.id",
"cloud.region",
"aws.cloudtrail.request_parameters",
]

Loading