« Suspicious SeIncreaseBasePriorityPrivilege Use Potential AWS S3 Bucket Ransomware Note Uploaded »
Elastic Docs ›Elastic Security [8.19] ›Downloadable rule update v8.19.8

AWS S3 Bucket Enumeration or Brute Force

edit
IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

AWS S3 Bucket Enumeration or Brute Force

edit

Identifies a high number of failed S3 operations against a single bucket from a single source address within a short timeframe. This activity can indicate attempts to collect bucket objects or cause an increase in billing to an account via internal "AccessDenied" errors.

Rule type: threshold

Rule indices:

  • logs-aws.cloudtrail-*

Severity: low

Risk score: 21

Runs every: 5m

Searches indices from: now-6m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

Tags:

  • Domain: Cloud
  • Data Source: AWS
  • Data Source: Amazon Web Services
  • Data Source: AWS S3
  • Resources: Investigation Guide
  • Use Case: Log Auditing
  • Tactic: Impact
  • Tactic: Discovery
  • Tactic: Collection

Version: 6

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

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 AWS S3 Bucket Enumeration or Brute Force

This rule detects when many failed S3 operations (HTTP 403 AccessDenied) hit a single bucket from a single source address in a short window. This can indicate bucket name enumeration, object/key guessing, or brute-force style traffic intended to drive cost or probe for misconfigurations. 403 requests from outside the bucket owner’s account/organization are not billed, but 4XX from inside the owner’s account/org can still incur charges. Prioritize confirming who is making the calls and where they originate.

Possible investigation steps

  • Investigate in Timeline. Investigate the alert in timeline (Take action → Investigate in timeline) to retrieve and review all of the raw CloudTrail events that contributed to the threshold alert. Threshold alerts only display the grouped fields; Timeline provides a way to see individual event details such as request parameters, full error messages, and additional user context.
  • Confirm entity & target. Note the rule’s threshold and window. Identify the target bucket (tls.client.server_name) and the source (source.address). Verify the caller identity details via any available aws.cloudtrail.user_identity fields.
  • Actor & session context. In CloudTrail events, pivot 15–30 minutes around the spike for the same source.address or principal. Determine if the source is:
  • External to your account/organization (recon/cost DDoS risk is lower for you due to 2024 billing change).
  • Internal (same account/org)—higher cost risk and possible misuse of internal automation.
  • Bucket posture snapshot. Record S3 Block Public Access, Bucket Policy, ACLs, and whether Versioning/Object Lock are enabled. Capture any recent PutBucketPolicy, PutPublicAccessBlock, PutBucketVersioning, or lifecycle changes.
  • Blast radius. Check for similar spikes to other buckets/regions, or parallel spikes from the same source. Review any GuardDuty S3 findings and AWS Config drift related to the bucket or principal.
  • Business context. Contact the bucket/app owner. Validate whether a migration, scanner, or broken job could legitimately cause bursts.

False positive analysis

  • Expected jobs / broken automation. Data movers, posture scanners, or failed credentials can generate 403 storms. Validate with userAgent, ARNs, change windows, and environment (dev/stage vs prod).
  • External probing. Internet-origin enumeration often looks like uniform 403s from transient or cloud-provider IPs and typically has no business impact and no billing if outside your account/org. Tune thresholds or allowlist known scanners if appropriate.

Response and remediation

1. Immediate, low-risk actions - Preserve evidence. Export CloudTrail records (±30 minutes) for the bucket and source address into an evidence bucket with restricted access. - Notify owners. Inform the bucket/application owner and security lead; confirm any maintenance windows.

2. Containment options - External-origin spikes: Verify Block Public Access is enforced and bucket policies are locked down. Optionally apply a temporary deny-all bucket policy allowing only IR/admin roles while scoping. - Internal-origin spikes: Identify the principal. Rotate access keys for IAM users, or restrict involved roles (temporary deny/SCP, remove risky policies). Pause broken jobs/pipelines until validated.

3. Scope & hunting - Review Timeline and CloudTrail for related events: PutBucketPolicy, PutPublicAccessBlock, PutBucketVersioning, lifecycle changes, unusual PutObject/DeleteObject volumes, or cross-account access. - Check GuardDuty S3 and Config drift findings for signs of tampering or lateral movement.

4. Recovery & hardening - If data impact suspected: with Versioning, restore known-good versions; otherwise, recover from backups/replicas. - Enable Versioning on critical buckets going forward; evaluate Object Lock legal hold if enabled. - Ensure Block Public Access, least-privilege IAM policies, CloudTrail data events for S3, and GuardDuty protections are consistently enforced.

Additional information

Rule query

edit
  event.dataset: "aws.cloudtrail" and
  event.provider : "s3.amazonaws.com" and
  aws.cloudtrail.error_code : "AccessDenied" and
  tls.client.server_name : *

Framework: MITRE ATT&CKTM

« Suspicious SeIncreaseBasePriorityPrivilege Use Potential AWS S3 Bucket Ransomware Note Uploaded »