IAM Is Your Cloud's Biggest Attack Surface. Treat It That Way.

Every cloud penetration test we run starts the same way: we map IAM. Before we look at exposed services, before we check for vulnerable applications, before we enumerate storage buckets — we look at who can do what.

The reason is simple: in cloud environments, IAM misconfigurations consistently provide the fastest path from initial access to full environment compromise. And they’re everywhere.

Why IAM Is the Problem

Traditional network security thinking treats your perimeter as the primary control — keep the attackers out, and your internal systems are safe. Cloud changes this model fundamentally.

In a cloud environment, authorization is access control. There’s no network perimeter separating a misconfigured Lambda function from your production RDS instance if the execution role has rds:* permissions. The question isn’t whether an attacker can route packets to your database — it’s whether they can obtain credentials that let them call the API.

This is why breach scenarios in cloud environments often look like:

1. Exploit a web application vulnerability → execute server-side code
2. Read instance metadata endpoint → obtain IAM role credentials
3. Use role credentials → enumerate and escalate to broader permissions
4. Achieve full environment control without ever “hacking” anything in the traditional sense

Steps 3 and 4 are pure IAM exploitation. And they’re preventable.

---

The Most Common IAM Failures We Find

1. Overpermissioned Roles and Service Accounts

This is the most universal finding. Developers, under time pressure, attach AdministratorAccess or roles/owner to service accounts because it makes things work. The security debt accumulates silently.

In AWS: EC2 instances running application code with IAM roles that have iam:*, s3:*, or ec2:*. The application only needs to write to one S3 bucket — but the role gives it access to everything.

In GCP: Service accounts used by Cloud Run services with roles/owner or roles/editor at the project level. These bindings are a single credential compromise away from full project access.

In Azure: Managed identities assigned Contributor at the subscription level when the workload only needs to interact with a single storage account.

The fix sounds simple: apply least privilege. In practice, it requires knowing what permissions your workloads actually use — which requires either careful analysis or using cloud-native tooling like AWS IAM Access Analyzer or GCP Policy Analyzer.

2. Wildcard Conditions and Missing Conditions

IAM policies with "Resource": "*" and no condition keys are an access control failure waiting to happen. Similarly, policies that grant permissions to assume any role without sts:ExternalId or source-account conditions create confused deputy vulnerabilities.

What to look for in AWS:

{
  "Effect": "Allow",
  "Action": "sts:AssumeRole",
  "Resource": "*"
}

This policy, attached to a Lambda or EC2 role, allows that workload to assume any role in any account that trusts it. If the workload is compromised, the blast radius is enormous.

3. Stale and Unused Credentials

AWS IAM access keys that were created for a one-off task and never rotated. GCP service account keys downloaded for local development and committed to version control. Azure service principals created for a deprecated integration still holding active credentials.

Unused credentials are gifts for attackers. They sit in the cloud IAM configuration quietly, waiting to be discovered — via GitHub search, via credential scanning, via a compromised developer laptop.

AWS IAM Access Advisor shows you when credentials were last used. Anything unused in 90+ days should be revoked. Most organizations have dozens of these.

4. Cross-Account Trust Misconfigurations

In AWS multi-account environments, cross-account role assumption is standard. What’s not standard: validating that the trust relationships are locked down correctly.

A common vulnerability: a development account has a role that trusts the production account’s CI/CD role for deployments. If the development account is compromised, the attacker can pivot directly to production.

Trust policies need to be as restrictive as possible:

• Specify exact principals (not "Principal": "*")
• Use sts:ExternalId for third-party integrations
• Use condition keys to restrict source IP or VPC

5. The Metadata Endpoint and SSRF

This isn’t strictly an IAM misconfiguration — but it’s where IAM failures get exploited. When an application has an SSRF vulnerability, the cloud instance metadata endpoint (169.254.169.254 in AWS, metadata.google.internal in GCP) returns temporary credentials for the attached IAM role.

If that role is overpermissioned, SSRF becomes immediate privilege escalation.

AWS IMDSv2 was introduced specifically to mitigate this — by requiring a PUT request to get a session token before metadata can be retrieved, making SSRF harder to exploit against the metadata endpoint. But many older instances still run IMDSv1.

Check your instances:

aws ec2 describe-instances \
  --query 'Reservations[*].Instances[*].[InstanceId,MetadataOptions.HttpTokens]' \
  --output table

Any instance showing optional (IMDSv1) on a workload with an attached role should be migrated to required (IMDSv2).

---

Privilege Escalation Paths We Actually Use

When we perform cloud penetration tests, these are the IAM-based privilege escalation paths we test most frequently.

AWS: iam:CreatePolicyVersion

If a compromised credential has iam:CreatePolicyVersion on a policy attached to an admin-equivalent role, the attacker can create a new version of that policy granting full administrator access, then set it as the default version.

aws iam create-policy-version \
  --policy-arn arn:aws:iam::123456789:policy/TargetPolicy \
  --policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":"*","Resource":"*"}]}' \
  --set-as-default

This grants full permissions in a single API call. No vulnerability exploitation required — just IAM abuse.

AWS: iam:PassRole + ec2:RunInstances

If a compromised credential can pass an admin role to a new EC2 instance and launch that instance, the attacker can create an instance with an admin role, SSH to it, and use the metadata endpoint to obtain admin credentials.

GCP: iam.serviceAccounts.actAs + Cloud Functions

If a compromised service account has iam.serviceAccounts.actAs on a higher-privileged service account, the attacker can deploy a Cloud Function that runs as that higher-privileged account and calls back with the access token.

The full list of AWS privilege escalation paths (maintained by Rhino Security Labs) currently contains over 20 distinct techniques. If your cloud environment hasn’t been tested against these, you don’t know your real exposure.

---

How to Audit Your Own IAM Configuration

You don’t need a penetration tester to do an initial IAM review. Here’s where to start:

AWS:

• Run PMapper to visualize privilege escalation paths
• Review IAM Access Analyzer findings in each region
• Pull the credential report: aws iam generate-credential-report
• Use AWS Config rules: IAM_USER_UNUSED_CREDENTIALS_CHECK, IAM_NO_INLINE_POLICY_CHECK

GCP:

• Review IAM policy bindings for roles/owner and roles/editor at project level
• Audit service account key age: gcloud iam service-accounts keys list
• Enable Policy Analyzer and review recommendations

Azure:

• Review Privileged Identity Management (PIM) assignments
• Check for permanent Owner/Contributor assignments at subscription scope
• Enable Defender for Cloud IAM recommendations

---

The One Thing to Do Today

If you do nothing else from this post, do this: pull a list of all IAM roles/service accounts attached to production compute workloads (EC2, GKE, Cloud Run, Azure VMs) and check what permissions they have.

If any of them have admin-equivalent permissions, you have a critical finding. Fix those first.

Everything else — rotation schedules, cross-account trust, privilege escalation path analysis — is important, but overpermissioned production workloads are the most common and most immediately impactful problem.

---

APPSECREW’s Cloud Security assessments cover IAM privilege escalation testing, cross-account trust analysis, and full cloud penetration testing across AWS, GCP, and Azure. Contact us to scope an engagement.