AWS Pentesting: S3 Bucket Recon

AWS S3 is one of the most popular storage solutions, but it’s also a common misconfiguration target that can lead to critical data exposure. As a cloud penetration tester, understanding how to conduct recon for S3 buckets is crucial in assessing the external security posture of an organization’s AWS environment. In this walkthrough, we’ll cover the methods to check for exposed S3 buckets and analyze the access level for different scenarios: when a bucket is publicly exposed, when you have AWS keys, and how to validate access permissions.

In this walkthrough, we will use a combination of S3 buckets from flaws.cloud, Dafthack’s glitchcloud bucket, and my own s3 bucket.

http://flaws.cloud/

Lets say we have a target company that has a domain of flaws.cloud, we can quickly check the tech stack used using Wappalyzer browser extension. In the image below it shows its possibly using S3.

We can then check the “page source” if there is any domain or URL that is pointing to S3.

We can then also used, Grayhatwarfare, a good site to look for exposed S3, Azure blobs, etc. In the image below, it happens that it has no entry for flaws cloud. We can move on with other tools.

We can also perform some Google Dorking. Some example of Google Dorks are shown below.

Google Dorking

site:.s3.amazonaws.com "company" 
site:http://s3.amazonaws.com intitle:index.of.bucket “”
site:s3.amazonaws.com "index of /" s3 
inurl:s3.amazonaws.com intitle:"AWS S3 Explorer"

One of my go-to tools for checking S3 buckets is Cloud_enum. It’s a powerful and efficient tool for enumerating cloud resources especially S3. You can find it on this GitHub link.

cloud_enum.py -k flaws.cloud --disable-azure --disable-gcp

The image below shows the exposed S3 bucket named “flaws.cloud”. This tool will try to automatically list all the files in the open S3 buckets.

For comparison, I have set up an S3 bucket named “rootaddictlabforrecon”. Note that if you will do a recon on this bucket, it will not be available as this has been deleted.

In the image below, I have selected “ACL disabled” and “Block all public access”. Previously, there was a settings in S3 that says, “Authenticated users group”, meaning all users within the AWS environment can access your bucket. This default has already been removed.

Running Cloud_enum again, shows that the status of my bucket is “Protected”. Again, even it says “Protected” try to access the S3 bucket while you are authenticated with your own credentials.

Next, when trying to list the bucket while not using any credentials, we can use the “ — no-sign-request” option as shown below.

aws s3 ls s3://<bucketname> --no-sign-request

When we attempted it with a “Protected” bucket, we got an ‘AccessDenied” error.

Lets then try to access the bucket using a valid AWS key.

aws configure --profile <profile name>

We can see a new error that says “ no identity-based policy allows the s3:ListBucket action”. This is because our user has not been assigned a permission to the bucket or our IAM user has no ‘s3:ListBucket” permission set.

I then returned to my AWS console and changed the permission of my IAM user to have “AmazonS3ReadOnlyAccess” access to the target S3 bucket.

We can now see the difference. This time, our IAM user can list the S3 bucket.

aws s3 cp s3://rootaddictlabforrecon/s3-sample-secrets.png . --profile <profile name>

When downloading the files from S3

You may try to download the whole directory by using s3 sync:

aws s3 sync s3://bucketname <localfolder> --profile <profile name>

Another finding or test case when assessing S3, is if the bucket is writable. Let’s say its a publicly accessible bucket, no sensitive file available in the bucket but users can upload files, best practice to flag it because threat actors can use this S3 to host their malicious files or replace existing files in the bucket.

aws s3 cp <location of the local file>  s3://<bucket name> --profile <profile name>

The image above shows when an S3 bucket is not writable.

The image below show that our user has write permission to S3.

Conclusion:

In this walkthrough, we showed how to perform recon for exposed S3 buckets. We covered various AWS CLI commands to list, download, and upload files to an S3 bucket. Additionally, we explored common error, including cases where access is denied due to the use of — no-sign-request, when valid credentials are required, and when proper permissions are correctly configured on the S3 bucket.”

References:
http://flaws.cloud/
https://pwnedlabs.io/labs/aws-s3-enumeration-basics
https://github.com/dafthack/CloudPentestCheatsheets/blob/master/cheatsheets/AWS.md
https://cloudbreach.io/blog/intro-to-aws-enumeration-part-1/