By

Adrien

●

Published 2025-11-05

AWS Customer Support Policy for Penetration Testing: AWS Cloud Security/Penetration Testing

• AWS allows security assessments of your own AWS-hosted assets; testing AWS-owned infrastructure or other customers’ resources is prohibited.​
• Testing must respect the shared responsibility model; you are responsible for what you deploy and configure, AWS is responsible for the underlying cloud.​
• No prior approval is generally required for common customer resources and services, but activities that resemble or cause service disruption remain disallowed.​

# Install for Linux x86_64
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install
aws --version

# Install for MacOS
curl "https://awscli.amazonaws.com/AWSCLIV2.pkg" -o "AWSCLIV2.pkg"
sudo installer -pkg AWSCLIV2.pkg -target /
aws --version

For Windows you need to download the installer (MSI File) and then check the version.

aws --version

You can install the PowerShell cmdlets for AWS Services using the following commands.

Install-Module -Name AWS.Tools.Installer -Scope CurrentUser
Install-AWSToolsModule AWS.Tools.Common,AWS.Tools.EC2,AWS.Tools.S3,AWS.Tools.IdentityManagement -CleanUp -Force

# Legacy Module (Optional)
Install-Module -Name AWSPowerShell -Scope CurrentUser

Multi-cloud OSINT tool. Enumerate public resources in AWS, Azure, and Google Cloud.

Tool Name: cloud_enum

pip3 install -r ./requirements.txt
./cloud_enum.py -k targetname -t 10 --disable-azure --disable-gcp

The goal here is to search for secrets and password that may grant us an Initial Access.

• Google Dorking
• Look for sensitive documents
• Code Repositories

Tools:

• GitLeaks
• TruffleHog

#Scan a repo
trufflehog git https://github.com/trufflesecurity/test_keys --results=verified

#Scan an organization
trufflehog github --org=trufflesecurity --results=verified

An S3 bucket takeover happens when an application, build system, or DNS record still references an S3 bucket name that no longer exists. Because S3 bucket names are globally unique, an outsider can create a new bucket with that exact name and start receiving traffic or content intended for the original bucket.

Why ?

• Dangling DNS/CNAME: A subdomain (for example, files.company.com) points to targetbucket.s3.amazonaws.com, but the bucket was deleted; creating targetbucket allows control over that endpoint.​
• Deleted staging/artifact buckets: CI/CD or CDK/bootstrap processes reference predictable bucket names; if those buckets are removed later, an attacker can re-create them and intercept artifacts or templates.​
• Global uniqueness: S3 enforces globally unique names across all accounts; once a name is free, any account can claim it.

What are the risks ?

• Content injection: Host malicious files or modified assets under a trusted subdomain or path, enabling phishing, malware delivery, or supply‑chain tampering.​
• Data interception: Apps that upload logs, builds, or user content to the now‑recreated bucket may leak sensitive data to the attacker.​
• Redirects and brand impersonation: Control over asset endpoints lets attackers inject scripts, deface sites, or perform credential harvesting on look‑alike resources.​

You may found AWS keys with this json format.

{
"AccessKeyId": "AKIAxxxxxxxxxxxxxxxx",
"SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYxxxxxxxxxx"
}

Short and Long term Keys

• ASIA...: Means Temporary AccessKeys
  • These must be used together with a SessionToken and have an explicit expiration.
  • Temporary security credentials issued by AWS STS (for example, from AssumeRole)
• AKIA...: Means Long Terme AccessKeys
  • These do not include a SessionToken by themselves.
  • Standard access key for an IAM user (long‑lived until deactivated/rotated)

There are multiple ways to manage your credentials with the aws CLI.

This command will ask you the AccessKeyId and the SecretAccessKey

aws configure

Validate the credentials using the "whoami" command

aws sts get-caller-identity

You have the possibility to use $ENV variables

export AWS_ACCESS_KEY_ID=…; 
export AWS_SECRET_ACCESS_KEY=…; 
export AWS_SESSION_TOKEN=…; 
aws sts get-caller-identity

If you find different credential or manage to gain access to mulitple users, you'll better use the profile feature from aws cli.

aws configure --profile Dev
#Ask AccessKeyId and SecretAccessKey
aws sts get-caller-identity --profile Dev

aws configure --profile Prod
#Ask AccessKeyId and SecretAccessKey
aws sts get-caller-identity --profile Prod

For multiple terminal you can initialize a $ENV variable such as

export AWS_PROFILE=dev;

This will create a Dev profile session. You can manage your different Access Keys with the configuration file located in ~/.aws/config and ~/.aws/credentials

[dev]
aws_access_key_id=AKIADEVEXAMPLEKEYID
aws_secret_access_key=devSecretKeyGoesHere/abc123EXAMPLE

[prod]
aws_access_key_id=AKIAPRODEXAMPLEKEYID
aws_secret_access_key=prodSecretKeyGoesHere/def456EXAMPLE

[profile dev]
region=us-east-1
output=json

[profile prod]
region=us-west-2
output=json

This part isn't really focused into pentesting but it could give you some highlight about the configuration of the AWS Tenant.

Tool Name: ScoutSuite

python scout.py aws --access-key-id $AWS_ACCESS_KEY_ID --secret-access-key $AWS_SECRET_ACCESS_KEY

You can generate an Attack Surface list with the Compute Dashboard or the database dashboard.

Prowler is like ScoutSuite and can generate a compliance check with a nice and shiny template, but the scan ca take few hours to perform. It's using aws cli

Tool Name: Prowler

#Running Scans from the terminal and generate differents reports format
prowler aws -M csv json-asff json-ocsf html


# List the available checks and services
prowler aws --list-checks
prowler aws --list-services

#Running an HTML Dashboard
prowler dashboard

The EC2 Instance Metadata Service is reachable only from inside an instance at http://169.254.169.254 and exposes instance attributes, IAM role credentials, and other metadata for local workloads.

IMDSv2 is the current default/required mode in many environments; it adds a session-oriented, hop‑by‑hop token that callers must obtain before requesting metadata, unlike IMDSv1 which allowed unauthenticated HTTP GETs.

To request a token and then query metadata with IMDSv2, first create a token via an HTTP PUT including a TTL header, then pass that token in subsequent requests via the X-aws-ec2-metadata-token header.

#From the compromised EC2
TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")

curl -s -H "X-aws-ec2-metadata-token: $TOKEN" "http://169.254.169.254/latest/meta-data/"

Common targets include the iam/ subtree to discover role name and retrieve short‑lived credentials usable against AWS APIs.

#From the compromised EC2, get the role name
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" "http://169.254.169.254/latest/meta-data/iam/security-credentials/"

#Ask the json for this role name
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" "http://169.254.169.254/latest/meta-data/iam/security-credentials/<ROLE_NAME>"