AWS S3 Bucket Server Access Logging Disabled

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.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2024/07/12"
  3integration = ["aws"]
  4maturity = "production"
  5updated_date = "2026/01/16"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Identifies when server access logging is disabled for an Amazon S3 bucket. Server access logs provide a detailed record
 11of requests made to an S3 bucket. When server access logging is disabled for a bucket, it could indicate an adversary's
 12attempt to impair defenses by disabling logs that contain evidence of malicious activity.
 13"""
 14event_category_override = "event.type"
 15false_positives = [
 16    """
 17    Bucket logging may be disabled by a system or network administrator. Verify whether the user identity and/or user
 18    agent should be making changes in your environment. Bucket component deletions by unfamiliar users should be
 19    investigated. If known behavior is causing false positives, it can be exempted from the rule.
 20    """,
 21]
 22from = "now-6m"
 23index = ["filebeat-*", "logs-aws.cloudtrail*"]
 24language = "eql"
 25license = "Elastic License v2"
 26name = "AWS S3 Bucket Server Access Logging Disabled"
 27note = """
 28## Triage and analysis
 29
 30### Investigating AWS S3 Bucket Server Access Logging Disabled
 31
 32This detection alerts when the server-access logging configuration for an S3 bucket is changed so that logging is disabled.  
 33Because 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.
 34
 35#### Possible investigation steps
 36
 37**Identify the actor and context**
 38   - 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.  
 39   - 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).
 40   - 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).
 41        - Consider whether the bucket houses audit logs or access logs; if so, disabling logging is especially suspicious and a higher risk.
 42
 43**Correlate with related activities**
 44   - Search for preceding or subsequent events by the same principal or for the same bucket:  
 45     - `DeleteObject`, `PutBucketAcl`, `PutBucketPolicy`, `RemoveBucketAccessPoint`, or other permissions changes (e.g., `PutBucketLifecycle`).  
 46     - `ListBucket`, `GetObject`, `CopyObject`, or large `GetObject` operations, especially from unusual IPs or cross-account.  
 47     - IAM changes in proximity: `AttachUserPolicy`, `CreateAccessKey`, `AssumeRole` by same principal or against the same principal.  
 48   - Review AWS Config or Audit logs to see if the bucket’s logging was previously enabled and how long it has been disabled.
 49
 50**Evaluate intent and risk**
 51   - If the bucket was being used to collect access logs or audit data, disabling logging significantly degrades forensic capability.  
 52   - Determine whether the actor has a legitimate business reason for modifying logging (ticket, change request, known automation).  
 53   - If not justified, treat this as a high-priority visibility compromise and proceed through escalation.
 54
 55### False positive analysis
 56
 57- Storage teams may disable logging temporarily during migration or cost-optimisation exercises.  
 58- Test or development buckets may routinely toggle logging for experimentation—document such buckets and roles.  
 59- 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.
 60
 61### Response and remediation
 62
 63**Contain & restore visibility**
 64   - Immediately re-enable server‐access logging for the affected bucket (ensure `LoggingEnabled=true` and correct `TargetBucket/Prefix`).  
 65   - If you suspect activity while logging was disabled, preserve any remaining object versions, cross-account access logs, or S3 Inventory data.  
 66
 67**Investigate scope and impact**
 68   - Use CloudTrail Lake or Athena to query access to the bucket and objects for the timeframe when logging was disabled.  
 69   - Identify external IP addresses, unusual principals, or rapid object transfers or deletions.
 70
 71**Recover & harden**
 72   - Apply bucket-policy or SCP restrictions to prevent unauthorized modifications of `PutBucketLogging` for audit/logging buckets.  
 73   - Enable AWS Config rule (e.g., `cloudtrail-s3-bucket-access-logging`) to alert if logging is disabled.  
 74   - Ensure logging target buckets are configured with retention, versioning, and immutability (S3 Object Lock) to prevent tampering.
 75
 76**Improve & monitor**
 77   - Update your incident response playbook to include this scenario (see AWS IR + Customer Playbook Framework).  
 78   - 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.
 79
 80### Additional information
 81
 82- AWS documentation on [S3 Server Access Logging](https://docs.aws.amazon.com/AmazonS3/latest/userguide/ServerLogs.html)  
 83- [AWS Incident Response Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/tree/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks)  
 84- [AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs)  
 85"""
 86references = [
 87    "https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketLogging.html",
 88    "https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-server-access-logging.html",
 89]
 90risk_score = 47
 91rule_id = "a6788d4b-b241-4bf0-8986-a3b4315c5b70"
 92severity = "medium"
 93tags = [
 94    "Domain: Cloud",
 95    "Data Source: AWS",
 96    "Data Source: Amazon Web Services",
 97    "Data Source: Amazon S3",
 98    "Use Case: Asset Visibility",
 99    "Tactic: Defense Evasion",
100    "Resources: Investigation Guide",
101]
102timestamp_override = "event.ingested"
103type = "eql"
104
105query = '''
106info where event.dataset == "aws.cloudtrail"
107   and event.provider == "s3.amazonaws.com"
108   and event.action == "PutBucketLogging"
109   and event.outcome == "success"
110   and not stringContains(aws.cloudtrail.request_parameters, "LoggingEnabled")
111'''
112
113
114[[rule.threat]]
115framework = "MITRE ATT&CK"
116[[rule.threat.technique]]
117id = "T1562"
118name = "Impair Defenses"
119reference = "https://attack.mitre.org/techniques/T1562/"
120[[rule.threat.technique.subtechnique]]
121id = "T1562.008"
122name = "Disable or Modify Cloud Logs"
123reference = "https://attack.mitre.org/techniques/T1562/008/"
124
125
126
127[rule.threat.tactic]
128id = "TA0005"
129name = "Defense Evasion"
130reference = "https://attack.mitre.org/tactics/TA0005/"
131
132[rule.investigation_fields]
133field_names = [
134    "@timestamp",
135    "user.name",
136    "user_agent.original",
137    "source.ip",
138    "aws.cloudtrail.user_identity.arn",
139    "aws.cloudtrail.user_identity.type",
140    "aws.cloudtrail.user_identity.access_key_id",
141    "aws.cloudtrail.resources.arn",
142    "aws.cloudtrail.resources.type",
143    "event.action",
144    "event.outcome",
145    "cloud.account.id",
146    "cloud.region",
147    "aws.cloudtrail.request_parameters",
148]

Triage and analysis

Investigating AWS S3 Bucket Server Access Logging Disabled

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.

False positive analysis

  • 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.

Response and remediation

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.

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.

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.

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.

Additional information

References

Related rules

to-top