Introduction to IAM
AWS Identity and Access Management (IAM) is a global, region-agnostic AWS service that provides authentication (proving who you are) and authorization (determining what you’re allowed to do) for every interaction with the AWS and it’s API.
Think of AWS as a massive office building. Inside that building are rooms full of valuable assets — servers, databases, files, applications. IAM (Identity and Access Management) is the building’s entire security system: the keycards, the locks, the reception desk, and the visitor log — all in one.
Its one job is to answer two questions for every action taken in AWS:
Who are you? and What are you allowed to do?
AWS IAM operates on default deny. If there’s no policy explicitly allowing something, it’s blocked — no exceptions. You’re not locking things down; you’re opening up only what’s needed. That’s the principle of least privilege in practice, and it’s the foundation of every secure AWS environment.
Core Concepts of IAM
Users
Users represent people or applications. They have long-term credentials like usernames, passwords, and access keys. Each user gets credentials (a password for the console, or access keys for programmatic access via CLI/API). These credentials are long-term, meaning they don’t expire on their own, which is exactly why leaked access keys are such a big deal in AWS security.
Groups
Groups are a way to manage permissions for multiple users at once. If you have ten developers who all need the same access, it’s far easier to put them in a group and apply one policy — rather than duplicating it across ten individual users.
Policies
Policies define what a user, group, or role can and can’t do. They’re written in JSON and attached to IAM entities. There are two types:
- Managed Policies — Reusable across users and groups. Easier to manage and scale.
- Inline Policies — Attached directly to one specific user or group. Harder to track and often the source of privilege escalation bugs in real-world environments.
Roles
Roles are like users but without long-term credentials. You assume a role temporarily, and AWS issues credentials that expire after a set period. For example, a security analyst investigating an incident might assume a role granting access to logs for a few hours — and lose that access once the session ends. Roles are a key tool for enforcing the principle of least privilege.
In pentests, most of the misconfigurations I find come down to forgotten policies and unnecessary role assignments to users and services.
Why IAM Matters for Pentesting
As a pentesters, we are not hunting for zero-days — we are hunting for misconfigurations just like you would do in assumed breach scenario in internal assessments. AWS gives users and teams a ton of flexibility, and with that flexibility comes a wide attack surface.
Here’s what to look for:
- Privilege Escalation — Can you go from a low-privilege user to an admin? This is the most common and most impactful finding in cloud environments.
- Lateral Movement — Even without admin access, can you move sideways into another user, role, or resource with sensitive access — like an S3 bucket full of customer data?
- Data Exfiltration — Can you take over a Lambda function and forward data to an external server?
- Persistence — If you can create access keys for another user, you can quietly backdoor their account without changing their password. That kind of access is hard to detect without solid logging and alerting in place.
What to Watch For
When reviewing IAM permissions, always check for these four things:
- Users with excessive permissions
- Roles that can be assumed by unintended principals
- Policies that use wildcards (e.g.,
"Action": "*"or"Resource": "*") - Services or Lambda functions with elevated permissions that could be abused