Securing AWS IAM Beyond the Wildcard

Developers write AWS IAM policies to unblock features, not to model security boundaries. When a service fails with an AccessDenied error, the fastest path to a green build is adding a wildcard. The change works, the feature deploys, and the ticket to clean up the policy is forgotten.

This operational pattern makes IAM misconfigurations the dominant finding category in cloud security assessments. The platform itself is not insecure. Rather, policy authoring is treated as a low-skill task, and policy evaluation is context-dependent. When conditions, resource ARNs, and trust policies interact, they create complex privilege escalation paths that static scanners often miss. Securing an AWS account requires understanding how these permissions chain together and implementing a systematic hardening workflow.

The Mechanics of Privilege Escalation

Many developers assume that as long as they do not grant administrator access directly, their accounts are secure. However, attackers regularly chain benign-looking permissions to achieve full administrative control.

One of the most common escalation primitives involves the iam:PassRole permission. By itself, passing a role does nothing. But when chained with a compute action like ec2:RunInstances, it becomes highly dangerous. If a principal has iam:PassRole on a privileged role and can launch an EC2 instance, they can attach that privileged role to the instance as an instance profile.

An attacker can then run a command to launch an instance with a reverse shell:

aws ec2 run-instances --image-id ami-0abcdef1234567890 --instance-type t3.micro --iam-instance-profile Name=PrivilegedAdminRole --user-data file://reverse-shell.sh

Once the instance is running, the attacker queries the Instance Metadata Service (IMDS) to extract the temporary security credentials of the privileged role:

curl http://169.254.169.254/latest/meta-data/iam/security-credentials/PrivilegedAdminRole

To remediate this, never allow iam:PassRole on all resources. Scope the permission to specific role ARNs and use the iam:PassedToService condition key to restrict which AWS services can assume the role.

Another silent escalation path is iam:CreatePolicyVersion. If an identity can create a new version of a customer-managed policy attached to themselves, they can bypass their current restrictions. They can simply write a new policy document that grants full access and set it as the default version:

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

Because this modification does not create a new IAM user or role, detection systems that only monitor for new entities will miss it. Remediation requires restricting iam:CreatePolicyVersion to specific policy ARNs or gating the action behind aws:RequestTag conditions.

Trust Policies and the Confused Deputy

While identity policies control what a principal can do, trust policies control who can assume a role. Misconfigurations here expose accounts to external access.

Setting the trust policy principal to a wildcard is a critical error:

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

This allows any AWS identity in the world to attempt to assume the role. It is almost always unintentional and should be replaced with explicit account or role ARNs.

For third-party integrations, omitting the ExternalId condition creates a classic confused deputy vulnerability. If a vendor integration role lacks a unique external ID, another customer of that same vendor can configure the vendor's platform to assume your role, gaining unauthorized access to your resources. Every cross-account trust policy for third-party vendors must require a unique, vendor-generated ExternalId condition.

Similarly, granting sts:AssumeRole on Resource: * allows a principal to assume any role in the account that trusts them, including administrative roles. This permission must always be scoped to specific target role ARNs.

The Developer Hardening Workflow

Hardening IAM is not a one-time project. It must be integrated into the development lifecycle.

First, eliminate inline policies on IAM users. Inline policies do not appear in the managed policy list, making them difficult to audit. They also do not transfer if a user is deleted and recreated with the same name. Move all permissions to customer-managed policies attached to IAM roles, not users.

Second, secure the root account. The root account should have no active access keys. Instead, use IAM Identity Center for administrative access and enforce multi-factor authentication on all administrative roles.

Third, move beyond simple static analysis. Standard scanners look at policies in isolation, but they cannot trace how permissions chain together across different roles. Use graph-based reasoning tools like PMapper to visualize and analyze effective permissions and identify hidden escalation paths. To actively test your defenses, use security tools like Pacu in a staging environment to simulate escalation attacks.

Finally, use native AWS CLI commands to audit and simulate policies during development:

aws iam simulate-principal-policy --policy-source-arn arn:aws:iam::123456789012:role/my-app-role --action-names ec2:RunInstances s3:GetObject

A Pragmatic Approach to Least Privilege

Achieving least privilege is difficult because teams fear breaking production workloads. However, leaving wildcards in place is a massive operational risk. By scoping resources, requiring external IDs on cross-account roles, and auditing permission chains with graph-based tools, you can close the most common avenues of cloud compromise without stalling your deployment pipeline.