IAM privilege escalation paths

The identity layer is the primary security boundary in AWS. During our cloud assessments, we analyze Identity and Access Management (IAM) configurations to map privilege escalation pathways. A classic escalation vector is misconfigured policy permissions, such as allowing a user to create new policy versions:

// VULNERABLE IAM policy allowing CreatePolicyVersion
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "iam:CreatePolicyVersion",
      "Resource": "*"
    }
  ]
}

The Exploit: If an attacker compromises a user account holding this policy, they can create a new version of the active policy containing admin access ("Action": "*") and set it as the default version, upgrading themselves to Full Administrator.

S3 bucket exposure and data leakage

Amazon S3 stores high-value assets: database backups, KYC documents (BVN details, selfie uploads), and PDF transaction statements. We audit S3 configurations to verify that access control lists (ACLs) and bucket policies do not allow anonymous read access:

# Audit check using AWS CLI to inspect bucket public access block settings
aws s3api get-public-access-block --bucket sensitive-kyc-bucket

The Fix: Force the Block Public Access setting on the bucket level. All user assets must be accessed via signed URLs generated on-the-fly by your backend application with short expiration times (e.g., 5 minutes).

Metadata Service (IMDSv2) enforcement

If an application running on an EC2 instance is vulnerable to Server-Side Request Forgery (SSRF), an attacker can request the AWS metadata endpoint to extract instance role credentials. In IMDSv1, this is a single HTTP request. We verify that IMDSv2 is enforced, which requires a session token and blocks SSRF access:

# Verify IMDSv2 requirement using AWS CLI
aws ec2 describe-instances --query "Reservations[*].Instances[*].[InstanceId,MetadataOptions.HttpTokens]"

The Fix: Configure all launch templates and running EC2 instances to require HttpTokens=required, forcing the metadata service to reject requests that do not present a session token.

The cloud security checklist

Verify these controls immediately inside your AWS Console:

Example finding

IAM policy bypass leading to S3 data exposure

During an AWS penetration test, we compromised an application server and accessed the instance metadata service. Because the server had a wildcard IAM policy attached (s3:* on resource *), we used the retrieved session credentials to download 150,000 PDF statements containing customer names and balances from an unrelated S3 bucket. Fix priority: critical. Remediated by applying least-privilege IAM policies to the instance role.

Running production systems on AWS? Secure your cloud configuration boundaries.

Book an AWS Cloud Audit

Frequently asked questions

What is IAM privilege escalation in AWS?

IAM privilege escalation occurs when a user or role has permissions that allow them to modify policy configurations or assume other roles with higher privileges, ultimately gaining administrator access to the AWS account.

How do you audit S3 bucket security?

We verify that S3 buckets enforce block public access settings, utilize server-side encryption (KMS), and configure access logging to monitor read/write requests.

What is the difference between AWS penetration testing and a configuration audit?

AWS configuration audits check settings against best-practice checklists (like CIS Benchmark). AWS penetration testing goes further by actively attempting to exploit misconfigurations, escalate privileges, and access customer databases.

Related reading

Blog: Fintech AWS security steps · Secrets management · API data leaks

Services: Secure architecture review · Penetration testing