IAM Privilege Escalation
An attacker or compromised principal has escalated their IAM permissions beyond what was intended. This can happen through overly permissive IAM policies, wildcard permissions, the ability to create or modify policies, or by assuming roles with broader access. Privilege escalation is often the second step after initial access.
Phase 1: Detection
Check GuardDuty for privilege escalation findings
GuardDuty detects anomalous IAM behavior that may indicate privilege escalation.
Search CloudTrail for policy modification events
Look for IAM policy creation, attachment, or modification events by the suspected principal.
for event in CreatePolicy PutUserPolicy PutRolePolicy AttachUserPolicy AttachRolePolicy CreateRole; do
echo "=== $event ==="
aws cloudtrail lookup-events \
--lookup-attributes AttributeKey=EventName,AttributeValue=$event \
--start-time <incident-start> \
--max-items 10
doneCheck for new role assumptions
An attacker with sts:AssumeRole permission can pivot to more powerful roles.
aws cloudtrail lookup-events \ --lookup-attributes AttributeKey=EventName,AttributeValue=AssumeRole \ --start-time <incident-start> --max-items 20
Phase 2: Containment
Attach deny-all policy to the escalating principal
Immediately block all actions by the principal that performed the escalation.
aws iam put-user-policy \
--user-name <username> \
--policy-name DenyAll-IncidentResponse \
--policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Deny","Action":"*","Resource":"*"}]}'Revoke permissions on escalated roles
If the attacker created or modified IAM policies, revert those changes immediately.
# List policy versions (attacker may have created new versions) aws iam list-policy-versions --policy-arn <policy-arn>
# Delete the attacker-created version aws iam delete-policy-version \ --policy-arn <policy-arn> \ --version-id v2
Revoke all active sessions for assumed roles
Add time-based deny conditions to invalidate any temporary credentials obtained through the escalated roles.
Phase 3: Eradication
Revert all IAM policy changes made during the incident
Compare current IAM policies against known-good baseline and revert any modifications.
# Get the current policy version aws iam get-policy-version \ --policy-arn <policy-arn> \ --version-id <version>
Remove attacker-created IAM entities
Delete any IAM users, roles, or policies created by the attacker for persistence.
# Find policies created during incident
aws iam list-policies --scope Local \
--query 'Policies[?CreateDate>=`<incident-start>`].{Name:PolicyName,Arn:Arn}' \
--output tableReview trust policies on all roles
The attacker may have modified role trust policies to allow cross-account access from attacker-controlled accounts.
for role in $(aws iam list-roles --query 'Roles[].RoleName' --output text); do
echo "=== $role ==="
aws iam get-role --role-name $role \
--query 'Role.AssumeRolePolicyDocument' 2>/dev/null
donePhase 4: Recovery
Re-apply least-privilege policies
Replace overly permissive policies with least-privilege versions based on actual usage.
# Use IAM Access Analyzer to generate least-privilege policies
aws accessanalyzer start-policy-generation \
--policy-generation-details '{"principalArn":"<role-arn>"}'Enable IAM Access Analyzer
Continuously analyze IAM policies for overly permissive access.
aws accessanalyzer create-analyzer \ --analyzer-name "org-analyzer" \ --type ORGANIZATION
Review and restrict iam:* permissions
Audit which principals have iam:CreatePolicy, iam:AttachRolePolicy, and other dangerous IAM permissions.
Phase 5: Lessons Learned
Implement permission boundaries
Use IAM permission boundaries to cap the maximum permissions that any role or user can have, even if someone attaches additional policies.
Deploy SCPs to prevent IAM escalation paths
Use SCPs to deny iam:CreatePolicy, iam:AttachRolePolicy, and other dangerous actions except for designated admin roles.
Run regular IAM Access Analyzer checks
Schedule periodic reviews of IAM Access Analyzer findings to detect permission drift.
Related Content
Need Help with Incident Response?
When an incident strikes, every minute counts. We help AWS teams prepare, detect, and respond to security incidents with proven expertise.