Common AWS IAM Misconfigurations

AWS IAM is powerful but easy to misconfigure. The same dozen or so patterns appear in nearly every AWS breach and audit finding. This article catalogs them with detection guidance and remediation.

---

1. Wildcard Policies (Action: *, Resource: *)

Pattern: Identity-based policy granting all actions on all resources.

Risk: Effectively AdministratorAccess. One compromised principal = full account compromise.

Detection:

• Search policies for "Action": "*" AND "Resource": "*".
• Identify principals with AdministratorAccess or equivalent.

Remediation:

• Replace with least-privilege policy.
• If admin truly needed, restrict via boundary, MFA, IP, or break-glass pattern.

---

2. Long-Lived IAM User Access Keys

Pattern: IAM users with access keys never rotated, sometimes years old.

Risk: Credential leak via Git, logs, dev machine compromise. Long lifetime widens compromise window.

Detection:

• List IAM users; filter by access key age > 90 days.
• IAM Credential Report.

Remediation:

• Rotate immediately; preferably eliminate via Identity Center / OIDC federation.
• Detect leaked keys via GitGuardian / TruffleHog / GitHub secret scanning.

---

3. Root Account Misuse

Pattern: Root used for daily operations, no MFA, active access keys.

Risk: Full account loss on compromise. SCPs cannot constrain root.

Detection:

• Check root MFA presence.
• Check root access keys.
• Detect any root sign-in event in CloudTrail.

Remediation:

• Hardware MFA on root.
• Delete root access keys.
• Use Identity Center for daily admin.
• Alert on root activity.

---

4. Public S3 Buckets

Pattern: Bucket policy or ACL granting Principal: "*" access.

Risk: Data breach via public read; ransomware via public write.

Detection:

• IAM Access Analyzer.
• AWS Trusted Advisor.
• Macie for sensitive data.
• Continuous monitoring (Forestall, AWS Config rules).

Remediation:

• Block Public Access at account level.
• Tighten bucket policy.
• Use CloudFront + OAI for public-content distribution.

---

5. Over-Broad Trust Policies

Pattern: Roles whose trust policy allows Principal: "*" or large account lists without conditions.

Risk: Anyone (or anyone with access in linked accounts) can assume the role.

Detection:

• Audit trust policies for "Principal": "*".
• Identify cross-account trust without conditions / external IDs.

Remediation:

• Tight trust to specific principals.
• External ID for third-party trust.
• aws:PrincipalOrgID for internal cross-account.

---

6. Missing External ID for Vendor Trust

Pattern: Cross-account role for a vendor without sts:ExternalId condition.

Risk: Confused Deputy — vendor's other customers can leverage the trust to reach your account.

Detection:

• Audit trust policies referencing vendor account ARNs without external ID.

Remediation:

• Require external ID per AWS guidance for any third-party cross-account role.

---

7. Service Trust Without Conditions

Pattern: Role trusts an AWS service principal (e.g., s3.amazonaws.com) without aws:SourceArn / aws:SourceAccount.

Risk: Confused Deputy — any AWS account's resources of that service can trigger access via the role.

Detection:

• Audit service trust policies for missing aws:SourceArn/aws:SourceAccount conditions.

Remediation:

• Add aws:SourceArn (specific resource) or aws:SourceAccount (your account).

---

8. iam:PassRole Without Resource Restriction

Pattern: Principal can pass any role to any AWS service.

Risk: Privilege escalation — pass a high-privilege role to a Lambda you create.

Detection:

• Search for "iam:PassRole" with "Resource": "*".

Remediation:

• Scope iam:PassRole to specific role ARNs only.

---

9. Privilege Escalation IAM Permissions

Pattern: Principals with permissions that enable IAM-based escalation:

• iam:CreatePolicyVersion
• iam:AttachRolePolicy, iam:AttachUserPolicy, iam:AttachGroupPolicy
• iam:PutRolePolicy, iam:PutUserPolicy
• iam:UpdateAssumeRolePolicy
• iam:CreateAccessKey
• iam:UpdateLoginProfile
• iam:DeleteUserPermissionsBoundary / iam:DeleteRolePermissionsBoundary

Risk: Effective admin escalation by a low-privilege principal.

Detection:

• Identify principals with these permissions outside the central IAM admin team.

Remediation:

• Restrict to specific resources or remove entirely.
• Require MFA + boundary protections for IAM administration.

---

10. Service-Specific Escalation Combos

• lambda:CreateFunction + iam:PassRole on high-privilege role = escalate via Lambda.
• ec2:RunInstances + iam:PassRole = escalate via EC2 instance profile.
• cloudformation:CreateStack + iam:PassRole = escalate via CFN.
• glue:CreateDevEndpoint with PassRole.
• sagemaker:CreateNotebookInstance with PassRole.
• datapipeline:CreatePipeline with PassRole.

Detection / Remediation: scope iam:PassRole; restrict service "create" permissions; permission boundaries; SCP guardrails.

---

11. Inactive Users / Roles / Keys

Pattern: IAM identities not used in 90+ days still active.

Risk: Forgotten attack surface; credentials potentially leaked.

Detection:

• IAM Credential Report (last activity).
• IAM Access Analyzer "unused access" findings.

Remediation:

• Quarterly cleanup.
• Disable then delete after grace period.

---

12. Identity Center Permission Sets Too Broad

Pattern: Permission Sets attaching AdministratorAccess to wide groups.

Risk: Over-permissioning amplified across many accounts.

Detection:

• Audit Permission Sets for AdministratorAccess/PowerUserAccess.
• Map to which groups receive them.

Remediation:

• Tier Permission Sets (Read, Power, Admin).
• Limit Admin to small groups; require approval / break-glass.

---

13. Lack of MFA Enforcement

Pattern: Console users without MFA; no Conditional / Identity Center enforcement.

Risk: Phishing / credential stuffing → account compromise.

Detection:

• IAM Credential Report (mfa_active).
• Identity Center MFA settings.

Remediation:

• Enforce MFA via Identity Center; for IAM users, enforce via condition (aws:MultiFactorAuthPresent) on policies.

---

14. Missing CloudTrail / Centralized Logging

Pattern: CloudTrail not enabled in all regions, not centralized, or with missing data events.

Risk: Blind to attacker activity; impossible to investigate.

Detection:

• CloudTrail status per account.
• Aggregator presence.

Remediation:

• Multi-region CloudTrail with management + data events.
• Centralize to logging account; immutable bucket; long retention.

---

15. SCPs Missing or Permissive

Pattern: No SCPs at OU level; or only FullAWSAccess.

Risk: No baseline guardrails; misconfigurations spread freely.

Detection:

• List SCPs across OUs.
• Identify accounts with no restrictive SCPs.

Remediation:

• Apply baseline SCPs (deny root usage, deny public S3, deny disabling CloudTrail/GuardDuty, region restriction, etc.).

---

16. Insecure IMDSv1 on EC2

Pattern: EC2 metadata service v1 enabled — vulnerable to SSRF credential theft.

Risk: Capital-One-style data breach.

Detection:

• List EC2 instances with IMDSv1 enabled.

Remediation:

• Enforce IMDSv2 via launch templates and SCP.

---

17. Stale Cross-Account Vendor Trust

Pattern: Cross-account roles still trust decommissioned vendors.

Risk: Old vendor credentials may still authorize.

Detection:

• Inventory cross-account trust; map to current vendor list.

Remediation:

• Remove on offboarding.

---

18. Inline Policies Sprinkled Everywhere

Pattern: Inline policies on individual users/roles instead of customer-managed.

Risk: Hard to audit; drift; inconsistent permissions.

Detection:

• Count inline policies per principal.

Remediation:

• Convert to customer-managed policies in version control.

---

How Forestall Helps

Forestall continuously evaluates your AWS Organization for these (and many more) misconfiguration patterns, ranks them by impact (especially attack-path proximity to admin or sensitive data), and tracks remediation. Findings include the affected principals, resources, and recommended fixes.

---

Conclusion

A small number of misconfiguration patterns drive most AWS IAM risk. Inventory, detect, and remediate them — wildcard policies, long-lived keys, public buckets, broad trust, escalation IAM permissions, missing MFA — and you'll close most attack surface. Make detection continuous, not annual, and you'll keep it closed as your AWS estate evolves.