Varonis Threat Labs (VTL) discovered an evasive vulnerability that limits visibility into anonymous requests in CloudTrail Network Activity events. Regardless of whether the bucket's permissions allow or deny anonymous access, there were no logs in the Network Activity trail indicating any anonymous requests. In some cases, there were no logs at all.
Without anonymous activity being logged, organizations risk attackers inside their private cloud networks interacting with public buckets invisibly, evading detection by security teams entirely.
This discovery follows our publication, The Silent Attackers: Exploiting VPC Endpoints to Expose AWS Accounts Without a Trace, which revealed how VPC endpoint policies could have been abused to expose the AWS account IDs of any valid S3 bucket, a vulnerability AWS quickly fixed. We are thankful for the collaboration between VTL and AWS Vulnerability Disclosure Program to ensure systems are safe.
Continue reading to learn how anonymous S3 requests can evade AWS logging.
What is anonymous access in S3 buckets?
Anonymous access refers to interactions with AWS S3 buckets where the requester is not required to provide authentication credentials. Anonymous requests are typically used to access publicly available S3 resources and do not include a signature or any identifying information about the requester.
How the attack works
Anonymous requests did not appear in networking trails while conducting our research.
In Amazon CloudTrail, the primary distinction between data events and management events is that management events are always collected and can be found in the event history or a configured trail, whereas a trail must be configured to collect data events. Events by anonymous actors that are logged in data or management events did not have a corresponding Network Activity event.
Let’s break down anonymous requests into cases based on the VPC endpoint policy and the target bucket:
- When an attacker uses anonymous access within a VPC to get data from a bucket within the account, requests made by an anonymous actor trigger a log in the account.
- When an attacker uses anonymous access within a VPC to get data from a bucket external to the account, no events were logged in the account at all.
But, what about the target account?
When an anonymous request was made to an external S3 bucket through a VPC endpoint, no CloudTrail event was generated at the source account — neither Network Activity, nor management/data events.
Do we have logs at the target account?
- If the VPC endpoint policy allowed access, anonymous requests generated management/data events in the target account.
- If the VPC endpoint policy denied access, the request was blocked at the network layer. In this case, no events were created, including in Network Activity, management/data trails, and in both accounts.
By denying the endpoint policy in the compromised account, attackers could have interacted with public buckets anonymously and invisibly, evading detection by security teams entirely.
The diagram below shows how anonymous requests were processed before the fix and what events were shown for anonymous requests to all internal and external buckets.
How missing logs impact enterprises and security teams
When logs are missing, the consequences are severe.
Imagine an attacker compromising an internal application server in your private VPC. From there, they can use the existing VPC endpoint to connect to an external S3 bucket they control. Because the traffic flows through the VPC endpoint, no events are logged in your source AWS account when using anonymous access. The attacker can then quietly upload sensitive business data or intellectual property to their bucket without triggering alerts. When your security team investigates later on, there is no forensic trail — no evidence of what data was taken, when it was stolen, or information on who took it. This lack of visibility makes detection and response nearly impossible for enterprises.
One might assume that the absence of anonymous events is harmless, but that’s misleading. Despite them providing only minimal context of the identity making the request anonymous events serve as an indication that activity is happening in your environment and gives security teams a chance to investigate and enforce controls before data loss occurs.
Without logs, there is absolutely zero visibility, leaving organizations unaware of the activity and unable to detect or respond until the damage is already done. Other examples include:
- An attacker downloading malware from their S3 bucket into a VPC behind a VPC endpoint
- Attacking other companies from the victim organization’s cloud network
AWS’ response
In partnership with AWS, updates were made to log all anonymous API requests made to external S3 buckets. Here is what AWS had to say:
“AWS released updates that change AWS CloudTrail's logging behavior for Virtual Private Cloud (VPC) endpoint policy events. With this change, CloudTrail now logs all anonymous API requests made to external S3 buckets via VPC endpoints as CloudTrail network activity events and are delivered to the VPC endpoint owner's account. Anonymous API calls are requests made to an AWS service endpoint that do not include standard AWS authentication information, such as SigV4 signatures, IAM user credentials, or temporary security credentials. While most AWS services require authentication, some like S3 and SQS support anonymous access when explicitly configured for public websites.
CloudTrail network activity events enable VPC endpoint owners to record AWS API calls made using their VPC endpoints from a private VPC to AWS services. Network activity events provide visibility into resource operations performed within a VPC. For example, logging network activity events helps VPC endpoint owners detect when credentials from outside their organization attempt to access their VPC endpoints.
To learn more about CloudTrail network activity events, please refer to our documentation.
We thank Varonis Threat Labs for reporting this issue and collaborating with AWS."
Mitigation strategies for evasive attacks
To reduce the risk of evasion attacks, we recommend the following:
- Restrict VPC Endpoint policies: Apply least privilege principles to VPC endpoint policies. Explicitly deny anonymous access and enforce IAM conditions for all requests
- Audit bucket policies regularly: Identify and remediate public or overly permissive bucket policies
- Enable alerts on policy changes: Set up notifications for any changes to VPC endpoint or bucket policies
Continuously examining new services as a security researcher is essential — not only to understand their behavior, but also to uncover hidden risks and help ensure they are safer for everyone. We appreciate the immediate collaboration from the AWS Vulnerability Disclosure Program to limit this vulnerability's impact.
Explore more Varonis Threat Labs research.
