Skip to content
HackIndex.io

Route53 and CloudFront Reconnaissance

5 min read Created May 24, 2026 Last updated May 24, 2026

Route53 and CloudFront leave distinct DNS fingerprints. Even without credentials, passive DNS and certificate transparency expose hosted zones, distribution endpoints, and dangling records. Start here before any authenticated enumeration. DNS fingerprinting costs nothing and reveals the attack surface quickly.

CloudFront Distribution Fingerprinting

CloudFront distributions resolve to *.cloudfront.net. A CNAME to a CloudFront hostname means the CDN sits in front of the origin. The origin server address is not exposed in DNS. Identify which domains route through CloudFront:

┌──(kali㉿kali)-[~]
└─$ dig $DOMAIN +short 
d1234abcd.cloudfront.net.
1.2.3.4

A CNAME to *.cloudfront.net confirms CloudFront is in the path. The distribution ID embedded in the CNAME hostname is account-specific. Multiple subdomains sharing the same distribution ID belong to the same CloudFront distribution. Note these for later correlation. Bulk check across subdomains:

┌──(kali㉿kali)-[~]
└─$ subfinder -d $DOMAIN -silent | dnsx -silent -cname | grep cloudfront

Route53 DNS Fingerprints

Route53 nameservers follow a predictable pattern. Every hosted zone gets four NS records spanning .com, .net, .org, and .co.uk TLDs. The numbers vary per zone, but the awsdns format never changes:

ns-123.awsdns-45.com
ns-678.awsdns-90.net
ns-1234.awsdns-56.org
ns-5678.awsdns-01.co.uk

Check if the target uses Route53. Any awsdns nameserver in the response confirms Route53 manages DNS for that domain:

┌──(kali㉿kali)-[~]
└─$ dig NS $DOMAIN +short | grep awsdns 
ns-123.awsdns-45.com.

Route53-hosted zones mean DNS changes are API-driven. This matters once you have AWS credentials. An IAM identity with route53:ChangeResourceRecordSets can add or modify records in any hosted zone it has access to. That permission enables DNS hijacking, phishing redirects via MX or A records, or internal traffic interception depending on the zone. Flag all Route53-hosted domains for credential-based follow-up.

Subdomain Enumeration

Run at least two passive sources and merge the results. Subfinder uses passive APIs. Amass adds historical DNS and certificate data. Certificate transparency via crt.sh catches subdomains that never appear in passive DNS logs.

┌──(kali㉿kali)-[~]
└─$ subfinder -d $DOMAIN -silent -all
┌──(kali㉿kali)-[~]
└─$ amass enum -passive -d $DOMAIN
┌──(kali㉿kali)-[~]
└─$ curl -s "https://crt.sh/?q=%25.$DOMAIN&output=json" | jq -r '.[].name_value' | sort -u | grep -v '*'

Filter results for AWS-specific subdomains. Hits on s3, execute-api, and elasticbeanstalk patterns are worth prioritizing. These services are common takeover targets when the underlying resource is deleted but the DNS record remains:

┌──(kali㉿kali)-[~]
└─$ subfinder -d $DOMAIN -silent | grep -E "s3|cloudfront|aws|lambda|execute-api|elb|elasticbeanstalk"

Subdomain Takeover via Dangling CNAMEs

Route53 and AWS services are common takeover targets. A CNAME pointing to an AWS endpoint that no longer exists is claimable. The underlying resource was deleted but the DNS record was left behind. High-value dangling targets include S3 buckets, Elastic Beanstalk environments, CloudFront distributions, and API Gateway custom domains. An S3 takeover lets you serve arbitrary content under the original subdomain. An Elastic Beanstalk takeover can allow hosting a malicious application on a trusted domain.

High-value dangling targets:

  • S3 buckets: serve arbitrary content under the original subdomain
  • Elastic Beanstalk: host a full application on a trusted domain
  • CloudFront distributions: intercept and serve traffic for the domain
  • API Gateway custom domains: respond to API calls meant for the target

Check for dangling CNAMEs. The script resolves each subdomain's CNAME target and flags any that return no A record. A dangling result needs manual confirmation: the target resource may be temporarily unavailable rather than truly deleted. Verify by attempting to claim the AWS resource before reporting:

┌──(kali㉿kali)-[~]
└─$ subfinder -d $DOMAIN -silent | while read sub; do
cname=$(dig CNAME $sub +short)
if [ -n "$cname" ]; then
resolved=$(dig $cname +short)
if [ -z "$resolved" ]; then
echo "[DANGLING] $sub -> $cname"
fi
fi
done 
[DANGLING] assets.example.com -> assets.example.com.s3.amazonaws.com.

Subjack fingerprints each subdomain against a signature database covering AWS S3, CloudFront, Elastic Beanstalk, and other providers. It catches cases the manual script misses by checking provider-specific error responses rather than DNS resolution alone:

┌──(kali㉿kali)-[~]
└─$ go install github.com/haccer/subjack@latest
┌──(kali㉿kali)-[~]
└─$ subjack -w subdomains.txt -t 100 -timeout 30 -o results.txt -ssl
Explain command
-w subdomains.txt File with subdomains to check.
-t 100 Concurrent threads.

API Gateway Endpoints

API Gateway public endpoints follow a known URL structure. The API ID is unique to each deployment. The region matches where the API was created. Stage names like prod, staging, dev, and v1 are common defaults. Finding an endpoint URL is often enough to start probing authentication and path enumeration:

https://$API_ID.execute-api.$REGION.amazonaws.com/$STAGE/

Discover API Gateway endpoints through JavaScript files, GitHub searches, or Burp passive scanning. Bundled front-end code often contains hardcoded execute-api URLs. GitHub code search finds them in public repositories. The gau command pulls URLs from Wayback Machine and other crawl sources without touching the live target:

┌──(kali㉿kali)-[~]
└─$ gau $DOMAIN | grep "execute-api"

API Gateway endpoints returning {"message":"Missing Authentication Token"} on / confirm the endpoint exists but has no route defined at the root. This response is normal for API Gateway and not an error in your request. Enumerate paths from there using wordlists targeting REST API path patterns. Check response headers for x-amzn-RequestId to confirm you are hitting API Gateway. A 403 response instead of the missing token message means authorization is enforced. IAM or a resource policy is likely configured at the API level. Note the API ID and region for credential-based follow-up.