Overly Permissive AWS IAM Policies

What Is This Vulnerability?

An AWS IAM role or policy that grants wildcard permissions (such as Action: * or Resource: *) gives far more access than needed. If an attacker compromises a service or user with this role, they gain unrestricted control over your entire AWS account, including the ability to create new users, exfiltrate data, or delete resources.

Why It Happens

Teams often use overly broad IAM policies during development because fine-grained policies take time to author. Managed policies like AdministratorAccess get attached to service roles for convenience. Without regular audits, these permissive policies persist into production and accumulate over time.

Example Code

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "*",
      "Resource": "*"
    }
  ]
}

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::my-app-uploads/*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "dynamodb:GetItem",
        "dynamodb:PutItem",
        "dynamodb:Query"
      ],
      "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/users"
    }
  ]
}

How Hackers Exploit It

Attackers who compromise any resource attached to an overprivileged IAM role can escalate privileges across the entire AWS account. They can create new IAM users with console access, spin up cryptocurrency miners on EC2, access all S3 buckets, read secrets from Secrets Manager, and modify CloudTrail logs to cover their tracks.

How to Fix It

Follow the principle of least privilege by granting only the specific actions and resources each service needs. Use IAM Access Analyzer to identify unused permissions and tighten policies. Set permission boundaries on roles. Schedule regular IAM credential reports and remove unused roles. Use AWS Organizations SCPs to set account-wide guardrails.

Frequently Asked Questions