Leaking an AWS account ID might seem harmless, but it can pose a security threat, resulting in different attack paths. Because of the risk, keeping your AWS account ID out of service names, infrastructure, or public-facing resources is strongly advised.
While exposing an account ID does not provide a direct attack path, it can still aid attackers in identifying vulnerable misconfigurations, escalating privileges, brute-forcing IAM usernames, and validating their existence based on differences in AWS error messages.
Although AWS has addressed several known enumeration techniques, Varonis Threat Labs recently discovered a new, simple, and effective way to retrieve the AWS Account ID of any S3 bucket, due to a lack of proper sanitization of CloudTrail Network Activity events.
While researchers like Sam Cox also leveraged Simple Storage Service (S3) buckets to reveal account IDs, this vulnerability is faster, easier, and more discreet — it doesn’t generate logs on the target account.
We responsibly disclosed this finding through the AWS Vulnerability Disclosure Program (VDP), which helps improve the security of AWS infrastructure and prevents unnecessary exposure of account IDs. AWS released the following statement:
“AWS is aware of a publication titled "The Silent Attackers: Exploiting VPC Endpoints to Expose AWS Accounts of S3 Buckets Without a Trace," which describes an issue where cross-account calls for CloudTrail Network Activity Events could return the resource owner's account ID in the event delivered to the API caller. This issue only happened when the API caller and resource owner accounts differed, and if the call failed due to denied access.
"On June 20, 2025, we released a defense-in-depth feature enhancement to address the issue. This enhancement redacts the owner account ID for this scenario. No customer action is required.
"While account IDs, like any identifying information, should be used and shared carefully, they are not considered secret, sensitive, or confidential information. Since including account IDs in this case is neither necessary nor proper, we chose to redact them out of an abundance of caution for customers who may have created buckets with sensitive or identifiable information within their names, contrary to best practices.
We would like to thank Varonis for reporting this concern to AWS.”
The abuse and how it worked
While exploring CloudTrail’s newest addition, ״Network Activity events״ we discovered a simple technique that exposes the account ID of any valid S3 bucket, regardless of its privacy settings. This method leaves no trace in the target account’s logs, making it a stealthy and effective method for enumeration.
The process involves configuring the attacker’s AWS environment and making a single API call:
- Deploy a VPC endpoint for S3 buckets with a policy that denies all requests to all buckets outside their own AWS account
- Set a CloudTrail trail that captures Network Activity events
- Initiate an API request to the target S3 bucket from within the VPC endpoint
As a result, a network activity event is created and recorded in the attacker's network activity trail, and the account ID of the S3 bucket is exposed. Since the request is denied at the VPC level in the attacker's account, no logs will be produced in the target account.
To fully understand this, let's review a few AWS services: CloudTrail, VPC endpoints, and S3.
AWS CloudTrail
AWS CloudTrail is the logging and monitoring service in AWS. It records API calls and console requests (such as login) in an AWS account. Four types of events can be recorded:
- Management events
- Data events
- Insight events
- Network Activity events
Management events are recorded to CloudTrail automatically, whereas recording other event types must be explicitly configured in a trail. Whenever an identity requests an action on a service configured in a trail, an event describing the request and response will be created, providing details on the identity, the target resource, the response, etc.
Logging Network Activity events is a recently added feature that provides visibility into API calls within a Virtual Private Cloud (VPC) using a VPC endpoint. Specifically, only network activity event log operations were denied by VPC endpoints. Network Activity events support several services, including S3 buckets, which will be generated due to a lack of permissions to a private S3 bucket from an external AWS account. A new event in the trail will be created, capturing the failed request. In addition, an event at the target account will be created to describe the failed attempt. However, access attempts were denied due to the VPC endpoint policy. If a trail is configured to log management or data events for S3 buckets, a denied access attempting access will not record any events in the management or data trails.
In an erroneous management or data event, the property “account id” under the resource object that holds the target bucket account ID is overridden by the text “HIDDEN_DUE_TO_SECURITY_REASONS.” This is done because the identity requesting access to the target resource is denied. Since the target resource is outside the AWS account, the target AWS Account ID should not be revealed.
It should look like this:
AWS VPC Endpoint
AWS VPC Endpoint enables private connectivity between your VPC and supported AWS services without requiring an internet gateway, NAT device, or VPN connection.
A VPC endpoint to the S3 service works by adding a route to your VPC's route table, allowing traffic to flow directly to S3 buckets over the AWS network. When a principal (such as an EC2 instance, Lambda function, or an IAM user) sends an API request to perform an S3 action from within the VPC, the traffic is automatically routed through the VPC endpoint.
Policies can be attached to a VPC Endpoint to control access to the connected service. These policies use the same JSON-based syntax as standard AWS IAM policies. An example of a VPC endpoint policy allows traffic from all principals to perform all S3 actions on all resources.
This policy is not recommended as it allows all S3 traffic through the VPC to all resources by all principals.
It is important to note that when a VPC endpoint policy allows access, it doesn’t automatically grant permission to the requesting identity. The identity must also have the necessary permissions through a resource-based or identity-based policy. In such cases, the request proceeds to the resource level, generating a network activity event in the trail, along with a management or data event — both in the requester account and the target account, if trails are configured.
However, when the VPC endpoint policy explicitly denies access, the request is blocked at the network layer and never reaches the resource. This results in a single network activity event with the error message "VpceAccessDenied" in the requester account.
No management or data events are created in either account, leaving the target account completely unaware of the attempt.
Denying access to all resources in the VPC endpoint policy was the most critical step in exposing bucket account IDs to which the identity has no access.
AWS always overrides the account ID of a target bucket when access is denied due to a lack of permissions, such as a “DeniedAccess” error. However, when the “VpceAccessDenied” error was added, we discovered the account IDs were not overwritten, exposing the account ID of any bucket as long as the bucket name is known to the attacker.
The VPC endpoint policy denying all access looks like this:
AWS Simple Storage Service (S3)
Amazon S3 stores data in containers called buckets, and each file within a bucket is referred to as an object. S3 supports resource-based policies (bucket policies) for controlling access at the bucket level, along with additional security features, like Block Public Access and ownership controls.
Since the VPC is attached to the VPC endpoint, all S3 API calls executed inside the VPC will be denied by the endpoint policy. For example, the output of running ‘aws s3 ls s3://target-bucket’ should look like this:
Since we configured a trail to collect network activity events, this event appeared in the trail within a few minutes. It looked like this:
The target account ID was exposed at the ‘Resources’ object in the event above. As previously mentioned, the event was not logged anywhere else since the request was denied due to the VPC endpoint at the network level.
Since AWS added the redaction of account IDs to these network activity records, the event now looks like this:
Limitations
It is important to note that this technique did not directly help discover or enumerate S3 buckets. It only worked if the attacker knew the target bucket's name. This technique helped discover the account ID where the bucket was created.
Reduce risk
This blog post details a vulnerability I discovered while researching a newly introduced AWS feature. The exposure of account IDs through network activity events—even when access to private S3 buckets is denied — reminds us that even with strong principles like least privilege and external data protection in place, new features can introduce unexpected behaviors that are easy to overlook.
To reduce risk:
- Encrypt logs at rest and in transit, ensuring that sensitive metadata remains protected.
- Redact sensitive identifiers from logs to prevent unintended exposure.
- Avoid exposing account IDs in resource names.
- Use VPC endpoints and private connectivity in AWS to further reduce the attack surface by isolating traffic from the public internet.
Combined with a proactive security mindset, these practices can help teams anticipate and mitigate impactful risks that may emerge as cloud platforms evolve and introduce new capabilities.
We are sincerely grateful to the AWS Vulnerability Disclosure Program Team for their quick and thoughtful response throughout the disclosure process.
Protect your AWS environment
You can’t secure what you can’t see. Get a free Cloud Data Risk Assessment to uncover exposed account IDs, misconfigured buckets, and other silent risks hiding in your cloud.
.png)
