AWS IAM: identities, roles & privilege abuse

AWS IAM (Identity and Access Management) is the authorization and authentication layer controlling every interaction with AWS resources. AWS IAM uses four core constructs: users, groups, roles, and policies. Policies are JSON documents that explicitly allow or deny API actions on specific resources. IAM roles are assumed by entities such as EC2 instances, Lambda functions, or external principals via the AWS STS AssumeRole API call, which returns temporary credentials valid for 15 minutes to 12 hours. The boundary between least-privilege design and overly permissive configurations is where most cloud breaches originate. Wildcard actions like 'iam:*' or 'sts:*' in a policy statement, combined with a '*' resource, grant unrestricted control over the entire AWS account. Permission boundaries and Service Control Policies (SCPs) in AWS Organizations add guardrails but are frequently misconfigured or absent. Understanding how IAM evaluates policy intersections — explicit deny always wins, implicit deny is the default — is fundamental to auditing cloud environments and reasoning about blast radius in incident response scenarios.

Detecting AWS IAM abuse relies primarily on AWS CloudTrail, which logs every IAM and STS API call with source IP, user-agent, request parameters, and response status. Key events to monitor include 'AssumeRole' calls across account boundaries, 'CreateAccessKey' on existing users (especially IAM admin users), 'AttachUserPolicy' or 'PutUserPolicy' granting elevated permissions, and 'GetCallerIdentity' used for reconnaissance. SIEM rules should alert on CreateLoginProfile on accounts that had no console access, and on PassRole combined with ec2:RunInstances, a classic privilege escalation path. AWS GuardDuty detects several IAM threat patterns natively, including credential use from unusual geolocations or Tor exit nodes flagged via findings like 'UnauthorizedAccess:IAMUser/TorIPCaller'. CloudTrail Insights can surface statistically abnormal API call volumes. In multi-account environments, track AssumeRole chains across accounts using the roleSessionName field to correlate lateral movement. Always enable CloudTrail in all regions with log file integrity validation. S3 bucket policies protecting CloudTrail logs must deny 's3:DeleteObject' even to administrators to preserve forensic evidence.

Red Team operators enumerate IAM configurations using tools like Pacu, the AWS-focused exploitation framework, or enumerate-iam to brute-force allowed API calls against a set of credentials. A common privilege escalation path is 'iam:CreatePolicyVersion': an attacker with this permission creates a new default policy version granting 'iam:*' or 'AdministratorAccess', instantly elevating their privileges without touching existing role attachments. Another critical path is 'iam:PassRole' combined with 'lambda:CreateFunction' and 'lambda:InvokeFunction': the attacker creates a Lambda with a high-privileged role and triggers it to exfiltrate credentials or create backdoor IAM users. AWS Managed Policies such as 'PowerUserAccess' still allow 'iam:CreateServiceLinkedRole', which can be chained further. Mitigation requires enforcing permission boundaries on all programmatically created roles, enabling AWS Config rules like 'iam-no-inline-policy-check' and 'access-keys-rotated', and running regular IAM Access Analyzer findings reviews to identify externally accessible roles. Privilege escalation paths in IAM should be modeled using tools like PMapper (Principal Mapper) to graph reachable admin-level principals from any given starting credential set.