Mistrusted Advisor: Evading Detection with Public S3 Buckets and Potential Data Exfiltration in AWS

August 20, 2025
Jason Kao

Executive Summary

In May 2025, we uncovered multiple undocumented techniques to evade detection by bypassing AWS Trusted Advisor’s S3 Security Checks. Leveraging these methods, we were able to bypass detection by Trusted Advisor’s S3 security scans and configure buckets with public and anonymous permissions via bucket policies and ACLs which permit data access open to the world and potential data exfiltration - all without triggering a single alert.

Under these conditions, Trusted Advisor incorrectly reported these public S3 buckets as secure, potentially leaving sensitive data exposed to data exfiltration and data breaches.  Trusted Advisor’s S3 Bucket Permission check is one of the only complimentary S3 security detective controls offered natively by AWS without enablement.  All AWS customers get Trusted Advisor’s S3 security check for free (customers with certain paid support plans receive API access and auto-refreshed checks).

This post will cover our security findings with Trusted Advisor including a walkthrough, our recommendations, our partnership with AWS to resolve these issues, and AWS's response. While we appreciate AWS addressing the issue, we found AWS's customer communication lacking and that their communication downplayed the impact and severity of this issue.

Example of an improperly reported S3 Bucket Security Check by Trusted Advisor (There should be 1 of 1 buckets that grant global access with 13 excluded items).

We reported this issue to AWS in May 2025. As of late June, 2025 this is no longer an issue.

Timeline

Finding Overview

We discovered 3 distinct scenarios where Trusted Advisor’s alerting could be bypassed and would not alert on Public Buckets:

With these scenarios, a bucket could then be configured for data exfiltration with any of the following granting public access:

In this case, we found the following:

Trusted Advisor’s Inaccurate Reporting for Amazon S3 Bucket Permissions

Trusted Advisor surfaces a summary of all the findings and will also improperly summarize this inaccurate reporting as not a finding.

Trusted Advisor's Inaccurate Summary Recommendations

Background and Walkthrough

Trusted Advisor Background

Trusted Advisor is a AWS Management & Governance Service that includes security capabilities as well.  Trusted Advisor offers checks over 6 categories including security, performance, fault tolerance, service limits, operational excellence, and cost optimization.

One of these Trusted Advisor security checks that all AWS Accounts have access to is the Trusted Advisor check for Amazon S3 Bucket Permissions (Check ID: Pfx0RwqBli).  This check looks for ACLs, bucket policies, and block public access status to evaluate S3 buckets for open access.

Relevant Trusted Advisor S3 Alert Criteria (from AWS):

Technical Walkthrough

Note: We excluded 13 buckets from the Trusted Advisor check to also denote the difference between excluded and ignored buckets from AWS.  Additionally, we used an account on the basic AWS Support plan, so we did not have access to the Trusted Advisor API.

With Block Public Access disabled at both the account and bucket level, the following could grant public access:

The following S3 bucket policy will set public read via s3:GetObject on our target bucket.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PublicRead",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::fog-pub-acl/*"
        }
    ]
}

The following AWS CLI command will set public write and public write bucket ACLs.

aws s3api put-bucket-acl --bucket fog-pub-acl \
--grant-write uri=http://acs.amazonaws.com/groups/global/AllUsers \
--grant-read uri=http://acs.amazonaws.com/groups/global/AllUsers

With the above set, Trusted Advisor will report action recommended (red) as the bucket is now public.  However, we can modify a bucket policy with one of the following payloads:

In this case, we’ll use s3:GetBucketPublicAccessBlock to craft a still public policy:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PublicRead",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::fog-pub-acl/*"
        },
        {
		        "Sid": "DenyBucketBPA",
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:GetBucketPublicAccessBlock",
            "Resource": "arn:aws:s3:::fog-pub-acl"
        }
    ]
}

When such a policy is applied, no high-severity or medium-severity Trusted Advisor alert is triggered.  Upon refresh of the Trusted Advisor S3 Security Check, the check status reports as green (no problems detected).

Trusted Advisor’s Inaccurate Security Summary with S3 Bucket Permissions

Thus, we now have evaded detection by bypassing AWS Trusted Advisor’s S3 Security Check and configured a bucket with public and anonymous permissions via bucket policies and ACLs that permits for data access open to the world and potential data exfiltration - all without triggering a single alert.

Our Thoughts and Observations

Here’s our take on AWS’s response.

‍

AWS Public Statement and Communications

‍

AWS’s Initial Communication to Affected Customers

‍

AWS's amended statement as provided to Fog Security

‍

Conclusion

While AWS provides multiple configuration options for enhancing S3 data security and access—such as ACLs, bucket policies, and Block Public Access Settings—our research highlights the complexity of how these settings interact. We found that certain combinations can evade security tooling and create publicly accessible S3 buckets without detection. Notably, detection by AWS’s own Trusted Advisor service could be bypassed with specific configurations.

We believe in customer transparency and that “security is job zero.”  While we appreciate AWS addressing the issue, we believe the communication is lacking and downplays the impact of this issue.  See Corey Quinn’s take on a recent security issue with Amazon Q and communication here.

AWS posted a public bulletin for a similar finding in 2023 here.

We recommend the following:

If you have any questions or feedback on our research, contact us at info@fogsecurity.io.

Subscribe to stay up to date on cloud data security and our work.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Copyright Fog Security