IAM Privilege Escalation: How Attackers Go From Zero to Admin (And How to Stop Them)

Have you ever wondered if the AWS IAM permissions you’ve assigned could create hidden security holes? Like finding out your supposedly secure house has a secret door you never knew about.

You’re about to discover exactly how attackers can escalate privileges in AWS environments, turning minimal access into admin-level control.

This hands-on IAM privilege escalation lab will transform theoretical concerns into practical understanding.

AWS security is only as strong as your IAM configuration. Setting up a vulnerable lab environment lets you safely experience the exploitation techniques hackers use daily.

By the end, you’ll know precisely how to identify and fix the permission gaps in your own AWS accounts before someone else finds them first.

But here’s the thing about IAM permissions that most cloud engineers miss completely…

Understanding AWS IAM Fundamentals

Key IAM concepts every admin should know

When you’re diving into AWS IAM, you need to grasp these core concepts:

• Users: Individual people or services that need AWS access
• Groups: Collections of users with shared permissions
• Roles: Sets of permissions that can be assumed by users or services
• Policies: JSON documents defining what actions are allowed or denied

Think of policies as the rulebook, while users, groups, and roles are the players in your AWS environment. You’ll use these building blocks to create your security structure.

The principle of least privilege explained

Here’s the deal with least privilege: give people exactly what they need to do their job; nothing more.

When you grant excessive permissions, you’re basically leaving your front door wide open. An attacker who compromises an over-privileged account can wreak serious havoc.

Start with zero permissions and add only what’s necessary. This might feel like extra work upfront, but you’ll thank yourself later when you’re not dealing with an AWS privilege escalation nightmare.

How permissions work in AWS

AWS permissions follow a simple rule: everything is denied by default. You have to explicitly allow actions.

Your IAM permissions boil down to statements like this:

"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::your-bucket/*"

AWS evaluates permissions in this order:

1. Is there an explicit deny? If yes, access denied.
2. Is there an explicit allow? If yes, access granted.
3. If neither, access denied.

Remember that permissions can come from multiple places (user policies, group policies, resource policies), and they all get evaluated together.

Common IAM security vulnerabilities

Look out for these IAM security pitfalls:

• Overly permissive policies: Using wildcards (*) when specific actions would suffice
• Unused credentials: Old access keys gathering dust but still active
• Missing MFA: Accounts protected by just a password are sitting ducks
• Privilege creep: Permissions accumulating over time without review
• Misconfigured trust relationships: Allowing unintended services or accounts to assume roles

These vulnerabilities create perfect conditions for AWS IAM privilege escalation attacks. Regular security audits using tools like AWS Config and IAM Access Analyzer can help you spot and fix these issues before an attacker does.

Setting Up Your AWS Privilege Escalation Lab

A. Required AWS account configurations

To set up your AWS privilege escalation lab, you’ll need a properly configured AWS account. Start with a fresh AWS account – definitely don’t experiment in your production environment! Enable MFA on your root account immediately and create a dedicated administrative IAM user for lab management.

Make sure your account has these configurations:

• CloudTrail enabled across all regions
• AWS Config activated to track resource changes
• IAM Access Analyzer to identify unintended access
• Budget alerts set to avoid unexpected costs (privilege escalation testing rarely costs much, but better safe than sorry)

B. Installing necessary tools and utilities

Grab these essential tools to make your life easier:

• AWS CLI: Your command-line best friend for AWS interactions
• AWS CloudShell: Browser-based alternative if you prefer not to install locally
• AWS IAM Policy Simulator: Test permissions without making real API calls
• Pacu: Open-source AWS exploitation framework for testing privilege escalation
• Scout Suite: Assessment tool that analyzes your AWS security posture
• Prowler: Command-line tool for AWS security best practices assessment

C. Creating practice IAM users with different permission levels

Time to create your test subjects! Set up these IAM users:

1. ReadOnlyUser: Assign AWS-managed ReadOnlyAccess policy
2. DeveloperUser: Add limited write permissions to specific services
3. PowerUser: Grant the AWS managed PowerUserAccess policy
4. CustomUser: Create a user with deliberately misconfigured permissions for escalation practice

For realistic scenarios, create custom policies with common misconfigurations like overly permissive resource statements or dangerous condition elements.

D. Configuring monitoring for your lab activities

You’ll want visibility into what’s happening during your tests:

• Set up CloudWatch alarms for suspicious API calls
• Create custom CloudTrail event filters for privilege escalation indicators
• Enable GuardDuty to detect anomalous behavior
• Configure EventBridge rules to notify you of security policy changes
• Implement real-time notifications via SNS to track critical actions

E. Establishing safety guardrails for experimentation

Don’t let your lab become a security problem itself:

• Use Service Control Policies (SCPs) to establish hard boundaries
• Create IP-based restrictions for account access
• Set resource limits to prevent accidental resource creation
• Implement automated cleanup scripts to remove test resources
• Establish a dedicated VPC with proper network ACLs for networked resources
• Configure permission boundaries for all IAM users in your lab

Common Privilege Escalation Techniques in AWS

A. Exploiting misconfigured role trust relationships

When you’re working in AWS, role trust relationships can be a goldmine for privilege escalation. Trust policies define which entities can assume a role – and when they’re misconfigured, you’ve got an open door.

For example, if a role trusts all AWS accounts ("Principal": {"AWS": "*"}), anyone could potentially assume it. Even more common is overly permissive conditions like missing external ID requirements or broad service principals.

Try this in your lab: Look for roles with trust relationships that include wildcards or minimal conditions. Once you find one, you can use sts:AssumeRole to jump into that role and inherit its permissions.

B. Leveraging service-linked role permissions

AWS creates service-linked roles automatically when you use certain services. They come with pre-defined permissions that you might not even realize exist in your account.

These roles are perfect privilege escalation targets because they often have expansive permissions to manage resources. For instance, the AmazonEKSClusterPolicy grants significant control over network interfaces and security groups.

In your testing, check what service-linked roles exist in your environment using:

aws iam list-roles | grep "AWSServiceRoleFor"

C. Using AWS managed policies to gain additional access

AWS managed policies are convenient but often provide way more permissions than you actually need. If you’ve got permission to attach policies to your own user or role, you’re sitting on a privilege escalation vector.

The infamous iam:AttachUserPolicy permission is particularly dangerous – with it, you can grant yourself admin access in seconds:

aws iam attach-user-policy --user-name YourUsername --policy-arn arn:aws:iam::aws:policy/AdministratorAccess

D. Chaining permissions for vertical privilege escalation

The real artistry in AWS privilege escalation is chaining multiple permissions together. You might start with limited access to Lambda, then use that to create a function that assumes a role with broader EC2 permissions, which you then leverage to access sensitive data.

A classic chain might look like:

1. Use lambda:CreateFunction to deploy code
2. Function leverages instance profile credentials
3. Those credentials access S3 buckets containing secrets
4. Secrets provide database access with elevated privileges

The power is in the combination – permissions that seem harmless alone become dangerous when linked together.

Hands-on Lab Exercises for IAM Privilege Escalation

A. From read-only to admin: A step-by-step exercise

Ready to get your hands dirty with some real AWS privilege escalation? In this exercise, you’ll start with just read-only permissions and work your way up to full admin access.

First, log into the AWS console with your read-only user. You can only view resources, but that’s enough to start your journey. Search for IAM policies with loose permissions using:

aws iam list-policies --scope Local --query 'Policies[*].[PolicyName,Arn]'

Look for policies containing wildcards like iam:* or overly permissive statements. Once you find one, check if your user can:

aws iam attach-user-policy --user-name YourUsername --policy-arn foundPolicyArn

If successful, you’ve just escalated your privileges! Now you can create access keys with:

aws iam create-access-key --user-name targetUser

B. Escalating through resource-based policy weaknesses

Resource-based policies are gold mines for privilege escalation. You’ll attack S3 buckets first.

List all S3 buckets you can see:

aws s3 ls

For each bucket, check its policy:

aws s3api get-bucket-policy --bucket bucket-name

Found a bucket with a policy allowing s3:PutBucketPolicy? That’s your ticket up! Modify the policy to give yourself admin rights:

aws s3api put-bucket-policy --bucket bucket-name --policy file://new-policy.json

Your modified policy should include permissions to assume roles or access other AWS services.

C. Exploiting IAM permission boundaries misconfiguration

Permission boundaries are meant to limit your power, but they’re often misconfigured.

First, check if any permission boundary is applied to your user:

aws iam get-user --user-name YourUsername

If you see a PermissionsBoundary field, examine it:

aws iam get-policy --policy-arn boundaryPolicyArn
aws iam get-policy-version --policy-arn boundaryPolicyArn --version-id v1

Look for gaps like:

• Missing deny statements for critical actions
• Allowed creation of new resources without boundaries
• iam:PassRole permissions

If you find iam:CreateRole and iam:PassRole permissions, create a new role with admin permissions and attach it to an EC2 instance you control.

D. Using temporary credentials to gain persistent access

Temporary doesn’t have to mean short-lived in AWS.

Once you’ve escalated privileges, secure your access by:

1. Creating a backdoor IAM user:

aws iam create-user --user-name maintenance-automation
aws iam attach-user-policy --user-name maintenance-automation --policy-arn arn:aws:iam::aws:policy/AdministratorAccess

2. Setting up access keys:

aws iam create-access-key --user-name maintenance-automation

3. Creating a Lambda function that refreshes credentials daily and sends them to an external endpoint you control.

Store these credentials securely – you now have persistent admin access even if your initial entry point is discovered and closed.

Detecting and Preventing Privilege Escalation

Implementing effective CloudTrail monitoring

When you’re running an AWS environment, CloudTrail is your best friend for detecting privilege escalation. It logs every API call, showing who did what and when. You’ll want to set up CloudTrail across all regions and direct logs to a dedicated, restricted S3 bucket.

Don’t just collect logs—analyze them. Look for suspicious activities like:

• Policy changes to IAM roles
• Creation of new admin users
• Modifications to existing permissions
• Use of temporary credentials with elevated privileges

Setting up alerts for suspicious IAM activities

Amazon EventBridge (formerly CloudWatch Events) can be your early warning system. Create rules that trigger when risky IAM actions occur:

aws events put-rule --name "IAMAdminChanges" --event-pattern '{"source":["aws.iam"],"detail-type":["AWS API Call via CloudTrail"],"detail":{"eventSource":["iam.amazonaws.com"],"eventName":["Create*","Delete*","Attach*","Detach*"]}}'

Connect these alerts to SNS topics so you get email or SMS notifications when someone’s trying to climb your IAM privilege ladder.

Using AWS Config rules to identify risky configurations

AWS Config gives you continuous assessment of your IAM setup. Enable these rules:

• iam-policy-no-statements-with-admin-access
• iam-user-no-policies-check
• iam-root-access-key-check

Custom rules can catch even more sophisticated privilege escalation paths:

function evaluateCompliance(configurationItem) {
if (hasWildcardPermissions(configurationItem)) {
return "NON_COMPLIANT";
}
return "COMPLIANT";
}

Automation techniques for continuous IAM security assessment

Automate your IAM security with these approaches:

• Run AWS IAM Access Analyzer daily to find unintended access
• Use AWS Security Hub to aggregate findings
• Deploy tools like CloudSploit or Prowler through scheduled tasks

This script can help you automatically revoke suspicious permissions:

def remediate_excessive_permissions(role_name, policy_name):
# Code to detect and remove overly permissive policies
iam.detach_role_policy(RoleName=role_name, PolicyArn=policy_arn)

Regular IAM access reviews and remediation

Schedule monthly reviews of your IAM environment. Check for:

• Unused credentials (>90 days inactive)
• Overly permissive policies
• Service roles with dangerous permissions combinations
• Trust relationships that could enable privilege escalation

Create a baseline of normal IAM activities and compare the current state against it. Document your findings and remediation steps in a central repository to track improvements over time.

Advanced IAM Security Hardening Techniques

A. Implementing Service Control Policies (SCPs) effectively

Think of SCPs as guardrails for your AWS environment. They’re your first line of defense against privilege escalation attacks. To implement them effectively:

1. Start with a deny-list approach:

   { "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "iam:CreateAccessKey", "Resource": "*", "Condition": { "StringLike": { "aws:PrincipalArn": "arn:aws:iam::*:role/restricted-*" } } } ] }

2. Apply SCPs at the OU level rather than individual accounts
3. Test your SCPs thoroughly in a non-production environment first

B. Leveraging permission boundaries for defense-in-depth

Permission boundaries are your secret weapon against privilege escalation. They cap what IAM entities can do, even if their policies would allow more.

Set up boundaries that:

• Restrict actions on critical IAM resources
• Prevent modification of boundary policies themselves
• Apply to all roles that developers can create

{
"Version": "2012-10-17", 
"Statement": [
{
"Effect": "Allow",
"Action": "*",
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestedRegion": ["us-gov-west-1", "cn-north-1"]
}
}
},
{
"Effect": "Deny",
"Action": "iam:*",
"Resource": "*"
}
]
}

C. Using AWS Organizations for multi-account security

AWS Organizations gives you superpowers to control privilege escalation across accounts.

Your security approach should include:

• A dedicated security account that controls policies
• Restricted access to the management account
• Centralized logging in a separate account
• Automated compliance checks using AWS Config rules

D. Managing cross-account access safely

Cross-account access is where privilege escalation often happens. Keep it tight by:

1. Using the principle of least privilege for all cross-account roles
2. Setting up external ID requirements for any third-party access
3. Implementing strict conditions based on source IP, MFA status, and request context
4. Regularly auditing cross-account relationships with AWS IAM Access Analyzer

Remember, your cross-account roles should be as restrictive as possible while still allowing legitimate work to happen.

Mastering AWS IAM is a critical skill for cloud security professionals, and practicing privilege escalation techniques in a controlled lab environment provides invaluable hands-on experience.

By understanding IAM fundamentals, setting up your own testing environment, and exploring common escalation paths, you’ve gained practical knowledge that directly translates to better cloud security posture management.

The detection and prevention techniques you’ve learned, along with advanced IAM hardening methods, will help you build more robust AWS environments.

As you continue your AWS security journey, remember that the skills developed in this lab represent just the beginning. Keep practicing, stay updated with AWS security best practices, and regularly test your environments for potential IAM misconfigurations.

Whether you’re aiming to enhance your defensive capabilities or pursuing a career in cloud security, the hands-on experience gained through this privilege escalation lab will serve as a solid foundation for your continued growth in AWS security.

I’ve also built a platform that shows you how to build the right hands-on cybersecurity skills to help businesses achieve their cloud security goals while you build the career you love for a better, higher-paying reward. Check it out here and start working on projects that will help you get hired.

The Author