S3 — CraftedSignal Threat Feed

Rapid Enumeration of AWS S3 Buckets

hello@craftedsignal.io — Fri, 01 May 2026 19:43:38 +0000

This threat brief covers suspicious activity related to the rapid enumeration of AWS S3 buckets. The activity is characterized by an AWS principal invoking read-only S3 control-plane APIs from the same source IP address within a short timeframe. This pattern is often associated with reconnaissance efforts, security scanning tools, or post-compromise enumeration activities. The behavior is similar to that observed with CSPM tools and by threat actors like Team PCP. The detection specifically excludes AWS service principals and requires programmatic-style sessions (i.e., not Management Console credentials). It focuses on scenarios where resource and identity fields are populated to avoid skewed results from null values. The detection threshold is set to greater than 15 distinct aws.cloudtrail.resources.arn values within a 10-second window.

Attack Chain

An attacker gains initial access to an AWS environment using compromised credentials or through an exposed IAM role. (T1530)
The attacker authenticates to AWS using the obtained credentials, creating a programmatic session.
The attacker issues a series of GetBucketAcl, GetBucketPublicAccessBlock, GetBucketPolicy, GetBucketPolicyStatus, and GetBucketVersioning API calls to S3.
These API calls are directed towards multiple distinct S3 buckets within a short timeframe (10 seconds).
The attacker collects information about the bucket’s access control lists (ACLs), public access blocks, policies, versioning status, and other metadata. (T1526, T1580, T1619)
The collected information is analyzed to identify publicly accessible buckets, misconfigurations, or sensitive data storage locations.
The attacker uses identified vulnerabilities to exfiltrate data.
The attacker attempts lateral movement within the AWS environment, leveraging the discovered information to compromise other resources.

Impact

Successful enumeration of S3 buckets can lead to the discovery of sensitive data, misconfigurations, and publicly accessible resources. This can result in data breaches, unauthorized access, and further compromise of the AWS environment. The enumeration allows an attacker to map out the S3 storage landscape, identifying targets for data exfiltration or privilege escalation. The rapid nature of the enumeration suggests automated scanning or reconnaissance, potentially indicating a larger attack campaign.

Recommendation

Deploy the following Sigma rule to detect rapid S3 bucket enumeration activity based on AWS CloudTrail logs, adjusting the threshold of 15 distinct buckets to suit your environment.
Investigate any alerts generated by the Sigma rule, focusing on the source IP address (source.ip), AWS principal ARN (aws.cloudtrail.user_identity.arn), and the list of accessed buckets (aws.cloudtrail.resources.arn).
Review IAM policies associated with the identified principal to ensure least privilege for S3 read APIs.
Monitor CloudTrail logs for related events, such as ListBuckets, GetObject, PutBucketPolicy, AssumeRole, or IAM changes, occurring within ±30 minutes of the detected enumeration activity.
Implement network-level restrictions on the source IP address if it is not authorized to perform S3 enumeration.
Document approved scanning accounts and add user agent filters to the provided Sigma rule to reduce noise from those identities.

AWS S3 Rapid Bucket Posture API Calls Indicate Reconnaissance

hello@craftedsignal.io — Sat, 11 Apr 2026 12:00:00 +0000

This threat brief details detection of rapid enumeration of AWS S3 bucket configurations. The activity is characterized by an AWS principal invoking read-only S3 control-plane APIs across numerous buckets within a short timeframe. This pattern is consistent with automated reconnaissance, security scanning, or post-compromise enumeration. The activity is detected by monitoring AWS CloudTrail logs for specific API calls such as GetBucketAcl, GetBucketPublicAccessBlock, GetBucketPolicy, GetBucketPolicyStatus, and GetBucketVersioning. The detection logic excludes AWS service principals and sessions using Management Console credentials to reduce false positives. This activity is relevant for defenders as it can signal early-stage reconnaissance by threat actors like Team PCP, or unauthorized data discovery within the AWS environment. The rule uses a threshold of 15 distinct buckets accessed within 10 seconds to identify suspicious behavior.

Attack Chain

An attacker gains access to AWS credentials, possibly through compromised credentials or misconfigured IAM roles.
The attacker uses the acquired credentials to authenticate to the AWS environment.
The attacker executes a script or tool that calls multiple S3 APIs (e.g., GetBucketAcl, GetBucketPolicy) to gather information about S3 buckets.
The tool iterates through a list of buckets, querying the configuration of each.
The attacker collects the responses from the S3 API calls, mapping out bucket names, permissions, and access control lists.
The attacker analyzes the collected data to identify potentially sensitive data or misconfigured buckets.
Based on the findings, the attacker may proceed to exfiltrate data from accessible buckets (T1530).
The attacker may also attempt to modify bucket policies or access controls to gain further access or persistence.

Impact

Successful reconnaissance of S3 bucket configurations allows attackers to identify vulnerable buckets, potentially leading to data breaches or unauthorized access to sensitive information. The source material does not provide specific victim counts or sectors. However, the impact can range from exposure of confidential data to full compromise of the AWS environment, depending on the level of access gained and the sensitivity of the data stored in the targeted buckets. Identifying the activity early can prevent further exploitation.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect rapid S3 bucket posture API calls (see: “AWS S3 Rapid Bucket Enumeration”).
Review IAM policies and enforce least privilege on S3 read APIs to limit the scope of potential reconnaissance activities.
Monitor CloudTrail logs for the same aws.cloudtrail.user_identity.arn and source.ip within approximately ±30 minutes for follow-on patterns such as ListBuckets, GetObject, PutBucketPolicy, or AssumeRole activities (see Overview).
Rotate or disable keys for the affected identity, revoke active role sessions where possible, and restrict the source IP at the network layer if it is not authorized (see Overview).
Whitelist approved scanning accounts and tune the Sigma rule to reduce noise from those identities (see Overview).

MinIO SSE Metadata Injection via Replication Headers Leads to Data Unreadability

hello@craftedsignal.io — Fri, 27 Mar 2026 22:26:05 +0000

A flaw in MinIO’s extractMetadataFromMime() function allows any authenticated user with s3:PutObject permission to inject internal server-side encryption (SSE) metadata into objects. This is achieved by sending crafted X-Minio-Replication-* headers on a normal PutObject request. The MinIO server incorrectly maps these headers to X-Minio-Internal-* encryption metadata without validating if the request is a legitimate replication request. Objects written in this manner contain bogus encryption keys and become permanently unreadable through the S3 API. This vulnerability affects all MinIO releases up to the final release of the minio/minio open-source project, specifically versions introduced after commit 468a9fae83e965ecefa1c1fdc2fc57b84ece95b0 (included in RELEASE.2024-03-30T09-41-56Z). It was resolved in MinIO AIStor RELEASE.2026-03-26T21-24-40Z.

Attack Chain

Attacker authenticates to the MinIO server with valid credentials having s3:PutObject permissions.
The attacker crafts a malicious PutObject request targeting a specific bucket and object key.
The attacker includes X-Minio-Replication-Server-Side-Encryption-* headers in the PutObject request.
The attacker omits the X-Minio-Source-Replication-Request header, which would normally indicate a legitimate replication request.
The MinIO server’s extractMetadataFromMime() function incorrectly maps the crafted X-Minio-Replication-* headers to X-Minio-Internal-Server-Side-Encryption-* headers.
The server writes the object metadata, including the bogus encryption keys, to the object storage.
Subsequent GetObject or HeadObject requests for the modified object will fail because the server treats the object as encrypted with non-existent or incorrect keys.
The attacker achieves a targeted denial-of-service, rendering the object permanently unreadable via the S3 API.

Impact

This vulnerability enables a targeted denial-of-service attack. An attacker can selectively corrupt individual objects or entire buckets within a MinIO deployment. Successful exploitation results in permanent data loss, as affected objects become unreadable through the S3 API. This can disrupt critical services relying on the object storage and potentially impact a large number of users if entire buckets are targeted.

Recommendation

Upgrade to MinIO AIStor version RELEASE.2026-03-26T21-24-40Z or later to patch the vulnerability as documented in the release notes.
Implement a reverse proxy or load balancer rule to drop or reject any request containing X-Minio-Replication-Server-Side-Encryption-* headers that does not also include X-Minio-Source-Replication-Request, mitigating the injection path as described in the Workarounds section.
Review and restrict IAM policies to limit s3:PutObject grants to trusted principals only, reducing the attack surface as noted in the Workarounds section.

S3Browser IAM Policy Creation with Default Bucket Name

hello@craftedsignal.io — Fri, 26 Jan 2024 12:00:00 +0000

The S3Browser utility is being used to create Inline IAM policies within AWS. This activity is flagged as suspicious when the policy includes the default S3 bucket name placeholder value of . This could indicate that the user has not properly configured the policy or is unaware of the implications of using a generic placeholder, potentially granting unintended access to S3 resources. This behavior was observed being used by the threat actor Guivil. The use of S3Browser in this manner poses a risk of privilege escalation, persistence, and unauthorized access to sensitive data stored in S3 buckets.

Attack Chain

An attacker gains initial access to an AWS account, possibly through compromised credentials or misconfigured IAM roles (T1078.004).
The attacker utilizes the S3Browser utility to interact with AWS S3 buckets.
The attacker attempts to create an Inline IAM policy using S3Browser.
The attacker fails to replace the default bucket name placeholder with a specific bucket ARN.
The attacker saves the IAM policy with the default bucket name placeholder, leading to a broad or unintended scope of permissions.
The poorly configured policy is applied to a user, role, or group.
The attacker potentially escalates privileges or gains unauthorized access to S3 resources.
The attacker persists in the environment with the newly created or modified IAM policy.

Impact

Creation of an IAM policy with the default bucket name placeholder leaves S3 buckets open to potential unauthorized access. A successful attack could lead to data exfiltration, data modification, or denial of service. The scope of the impact depends on the specific permissions granted within the policy and the resources accessible through the affected IAM user, role, or group.

Recommendation

Deploy the Sigma rule “AWS IAM S3Browser Templated S3 Bucket Policy Creation” to your SIEM and tune for your environment to detect this specific activity.
Investigate any instances where PutUserPolicy events are associated with the S3Browser user agent (logsource: aws/cloudtrail).
Review existing IAM policies for the presence of the default bucket name placeholder arn:aws:s3:::/* (logsource: aws/cloudtrail).

AWS S3 Bucket Deletion Detected via CloudTrail

hello@craftedsignal.io — Tue, 02 Jan 2024 14:27:00 +0000

The deletion of S3 buckets is a critical event to monitor in AWS environments. While legitimate administrative actions may involve bucket deletion, unauthorized or accidental removal of buckets can lead to significant data loss and business disruption. This brief focuses on detecting such events through AWS CloudTrail logs, which record API calls made within the AWS infrastructure. Monitoring for DeleteBucket events helps identify potential malicious activity or unintentional misconfigurations that could compromise data availability and integrity. This detection focuses on identifying DeleteBucket API calls, successful or otherwise, within CloudTrail logs to provide early warning of potential data compromise.

Attack Chain

An attacker gains unauthorized access to an AWS account through compromised credentials or a privilege escalation exploit.
The attacker lists existing S3 buckets to identify potential targets using the ListBuckets API call.
The attacker identifies a target S3 bucket containing sensitive data.
The attacker attempts to delete the target S3 bucket by issuing a DeleteBucket API call using the AWS CLI or SDK.
CloudTrail logs the DeleteBucket event, including the user identity, timestamp, and bucket name.
If successful, the S3 bucket and its contents are permanently deleted.
The attacker may attempt to remove CloudTrail logs to cover their tracks, using the DeleteTrail API call.

Impact

The deletion of an S3 bucket results in the permanent loss of all data stored within that bucket. This can lead to service disruption, data breaches, and financial losses, especially if the bucket contained critical business data or backups. The impact can range from temporary inconvenience to complete business failure depending on the criticality of the data lost and the organization’s backup and recovery capabilities. Without proper monitoring and alerting, an S3 bucket deletion can go unnoticed for extended periods, hindering incident response efforts and potentially exacerbating the damage.

Recommendation

Deploy the provided Sigma rule to your SIEM to detect S3 bucket deletion events in CloudTrail logs.
Investigate any detected DeleteBucket events to verify their legitimacy and ensure they were authorized by appropriate personnel.
Implement multi-factor authentication (MFA) for all AWS accounts to prevent unauthorized access and reduce the risk of credential compromise.
Enforce strict IAM policies and regularly review user permissions to minimize the blast radius of compromised accounts.
Enable versioning on S3 buckets to allow for the recovery of accidentally deleted objects, mitigating the impact of data loss.
Implement data backup and disaster recovery plans to ensure business continuity in the event of a successful bucket deletion attack.