Users & Groups
AWS IAM Users & Groups
Theory
IAM Users
IAM Users represent permanent identities within an AWS account, typically corresponding to individual people or applications that require long-term access to AWS resources. Unlike roles which provide temporary credentials, users have persistent credentials including passwords for console access and access keys for programmatic access. Each user is uniquely identified by a username within the account, an ARN in the format arn:aws:iam::123456789012:user/username, and an immutable UserID starting with AIDA that persists even if the user is renamed.
When you create an IAM user, it starts with no permissions whatsoever. AWS follows the principle of implicit deny by default. Permissions must be explicitly granted through one or more mechanisms: managed policies attached directly to the user, inline policies embedded within the user entity itself, or permissions inherited from group memberships. This multi-layered approach allows for flexible permission management while maintaining security through the least privilege principle.
IAM users can have several types of credentials attached to them. A login profile provides password-based access to the AWS Management Console, with configurable password policies including complexity requirements, expiration, and reuse prevention. For programmatic access, users can have up to two access keys simultaneously, which is useful during key rotation. Additionally, MFA devices can be attached to users to require multi-factor authentication for console access or sensitive API operations.
From a security perspective, IAM users represent a significant attack surface. Unlike temporary role credentials that expire automatically, user credentials persist until explicitly deleted or rotated. This permanence creates risks including credential exposure through accidental commits to GitHub repositories, hardcoded credentials in application configuration files, credentials leaked in logs or error messages, and stale credentials from former employees or decommissioned applications. Additionally, users with permissions to create or modify other users can potentially escalate their privileges or establish persistence through backdoor accounts.
IAM Groups
IAM Groups are collections of IAM users that simplify permission management at scale. Rather than attaching policies to each user individually, you can organize users into groups based on job function, department, or privilege level, then attach policies to the group itself. Any user who is a member of the group automatically inherits all permissions granted to that group, making it easy to ensure consistent permissions across teams.
It's important to understand that groups are not true AWS identities in the same way that users and roles are. Groups have no credentials of their own and cannot be authenticated as principals. You cannot assume a group, and you cannot specify a group as the principal in a resource-based policy or trust policy. Groups exist purely as organizational constructs within IAM for permission management convenience. They're identified by a group name and an ARN in the format arn:aws:iam::123456789012:group/groupname.
A single user can belong to multiple groups simultaneously, and AWS will evaluate all policies from all groups when determining the user's effective permissions. However, groups cannot be nested within other groups—AWS maintains a flat group structure. This means you cannot create a hierarchy of groups like "Developers → Senior Developers → Team Leads." Instead, you must assign users directly to each relevant group and use policy conditions or permission boundaries if you need more granular control.
The security implications of groups center around their role in privilege escalation paths. An attacker who gains permissions to add users to groups (through iam:AddUserToGroup) can elevate their privileges by adding their compromised user to a more privileged group like "Administrators." Similarly, the ability to modify group policies (iam:PutGroupPolicy or iam:AttachGroupPolicy) allows an attacker to grant additional permissions to all members of a group, potentially affecting multiple users at once. Groups also provide a subtle persistence mechanism, even if you remove explicit policies from a user, they may still retain permissions through group memberships that might be overlooked during incident response.
Permission Inheritance and Evaluation
When an IAM user makes an AWS API request, AWS evaluates all applicable policies to determine whether to allow or deny the request. For users who are members of groups, this evaluation includes policies from multiple sources. AWS collects all identity-based policies attached directly to the user, all inline policies embedded in the user, and all policies attached to every group the user belongs to. These policies are logically combined using a union operation—the user's effective permissions are the sum of all allowed actions across all these policies.
However, this union of permissions is subject to critical restrictions. If any policy contains an explicit Deny statement that matches the request, the request is denied regardless of any Allow statements. This explicit deny always takes precedence. Additionally, if permission boundaries are configured for the user, the effective permissions become an intersection of the identity-based policies and the boundary. The user can only perform actions that are allowed by both. The same intersection logic applies when Service Control Policies (SCPs) are in effect at the AWS Organizations level.
This complex evaluation logic creates both security opportunities and risks. Organizations can use permission boundaries to set maximum privilege limits that cannot be exceeded, even if a user gains additional policy attachments. But attackers who understand this logic can identify which permissions to target for privilege escalation. For example, if a user has a permission boundary that allows iam:*, an attacker only needs to gain iam:AttachUserPolicy to attach any policy they want, since the boundary won't restrict them. Understanding the full permission evaluation chain is essential for both defense and offense.
User and Group Metadata
IAM users and groups contain various metadata fields that provide valuable information for both legitimate administration and reconnaissance. For users, the CreateDate field indicates when the user was created, the PasswordLastUsed field shows when the user last logged into the console, and Tags can contain arbitrary key-value pairs that might reveal information about the user's purpose or department. Users also have a Path attribute that can be used to organize users into hierarchies like /division/department/, though this is purely organizational and has no security impact.
Access key metadata is particularly valuable for attackers. The ListAccessKeys API reveals access key IDs, creation dates, and status (Active/Inactive) for all keys attached to a user. The GetAccessKeyLastUsed API shows when and where a specific access key was last used, including the service that was accessed and the region. This information helps attackers identify stale credentials that might not be actively monitored, or understand which credentials are most valuable based on their usage patterns.
For groups, metadata is simpler but still useful. The CreateDate shows when the group was created, and the group's attached policies reveal its privilege level. By examining which users belong to which groups and what policies are attached, an attacker can map out the privilege structure of an organization and identify high-value targets. Groups with names like "Administrators," "SecurityAudit," or "Developers" immediately reveal their purpose and potential privilege level.
Practice
The enumeration techniques described in this section require authenticated access to the AWS account. If you don't have credentials yet, you can enumerate IAM users without authentication using resource-based policy validation techniques.
See the dedicated Unauthenticated Enumeration page for techniques to discover valid IAM users, roles, and root user emails in a target account without any credentials.
Enumerating Users
The first step in attacking IAM users is discovering which users exist in the account and what permissions they have. This reconnaissance provides the foundation for identifying privilege escalation paths and understanding the account's security posture.
The AWS CLI provides straightforward methods to enumerate all users in the account. This basic enumeration reveals user names, ARNs, creation dates, and user IDs, giving you an initial inventory of potential targets.
The list-users operation returns a wealth of metadata including the CreateDate which reveals when the user was created, the PasswordLastUsed timestamp showing console activity, the Path for organizational hierarchy, and any Tags that might contain sensitive information about the user's purpose. Look for recently created users that might indicate response to a compromise, or very old users that might be forgotten and have weak passwords.
Pacu's IAM enumeration module automates user discovery and provides a comprehensive view of all users, their permissions, group memberships, and attached policies in a single operation.
Pacu stores all enumerated data in its database, allowing you to query and analyze it later. The module automatically identifies high-privilege users based on attached policies, finds users with console access but no MFA, and highlights potential security misconfigurations like inactive access keys that are still enabled.
ScoutSuite performs comprehensive security audits of IAM users and generates a detailed HTML report highlighting security issues including users without MFA, stale credentials, and overly permissive policies.
The generated report includes sections for users with console access but no MFA, users with old access keys that should be rotated, users with inline policies (which violate best practices), and users with administrator access. The report also shows user activity based on password last used and access key last used timestamps, helping identify dormant accounts.
CloudFox provides specialized enumeration focused on identifying privilege relationships and potential attack paths involving IAM users.
CloudFox excels at visualizing relationships between users, groups, and permissions. It can generate graphs showing which users belong to which groups, and which policies grant which permissions. This visualization makes it easy to identify privilege escalation paths that might not be obvious from raw API output.
Enumerating User Permissions
Once you've identified the users in an account, the next critical step is understanding what permissions each user has. This tells you what actions you can currently perform and what additional permissions you might need to escalate privileges.
Enumerating user permissions requires querying multiple API endpoints to collect all managed policies, inline policies, and group-inherited permissions, then combining them to understand the user's effective permissions.
To get a complete picture, you need to enumerate managed policies attached to the user, inline policies embedded in the user, all groups the user belongs to, and all policies attached to those groups. Then retrieve the actual policy documents to see what actions and resources are allowed. This manual process can be tedious for users with many group memberships.
Pacu's permission enumeration module automatically collects and analyzes all permissions from managed policies, inline policies, and group memberships, providing a clear view of what the user can do.
The iam__enum_permissions module retrieves all policy documents, parses them, and presents a unified view of allowed actions. It highlights wildcard permissions like s3:* or iam:* that grant broad access. The iam__privesc_scan module goes further by analyzing these permissions and identifying specific privilege escalation methods you can use based on your current access.
The enumerate-iam tool takes a different approach by actively testing permissions through brute force. Rather than relying on policy documents, it attempts thousands of API calls to determine exactly what actions you can perform.
This approach is valuable when you don't have permissions to read IAM policies (iam:GetPolicy, iam:GetUserPolicy), but you want to discover what you can actually do. The tool makes read-only API calls for hundreds of different actions and records which ones succeed. This can reveal permissions granted through resource-based policies or service control policies that wouldn't appear in identity-based policy documents.
However, be aware that this generates significant CloudTrail logs and may trigger security alerts.
Enumerating Groups
Understanding which groups exist and what permissions they have reveals organizational structure and potential privilege escalation paths through group membership manipulation.
Enumerating groups involves listing all groups, examining their members, and analyzing their attached policies to understand the privilege landscape.
Pay special attention to groups with names suggesting elevated privileges like "Administrators," "PowerUsers," "Developers," or "SecurityAudit." Also look for groups with broad IAM permissions (iam:*) or administrator access (arn:aws:iam::aws:policy/AdministratorAccess), as these are prime targets for privilege escalation through AddUserToGroup.
Pacu's IAM enumeration automatically maps out all groups, their members, and their permissions, providing a complete view of group-based permission inheritance.
Pacu highlights groups that grant administrative or highly privileged access, making it easy to identify which groups you'd want to add your user to for privilege escalation. It also shows which users belong to multiple privileged groups, indicating high-value targets for credential compromise.
ScoutSuite audits groups for security issues including overly broad permissions, groups with only one member (suggesting the group is unnecessary), and groups with inline policies that violate best practices.
The ScoutSuite report identifies groups with administrator access, groups that have both managed and inline policies (increasing complexity), and groups with very few members that might indicate abandoned organizational structures. It also shows groups with permissions to modify IAM policies or users, which are key targets for privilege escalation.
Enumerating Access Keys
Access keys are the credentials used for programmatic access, and discovering which keys exist, their status, and usage patterns reveals attack opportunities and persistence mechanisms.
Enumerating access keys requires querying each user individually to see their keys, then optionally checking when those keys were last used.
The ListAccessKeys API returns the access key ID, creation date, and status (Active or Inactive) for each key. Users can have up to two access keys, which is often used during key rotation. The GetAccessKeyLastUsed API reveals the last date, time, service, and region where the key was used, helping identify stale credentials that might not be monitored.
Pacu automatically enumerates all access keys across all users, identifies stale or unused keys, and flags security issues like keys that have never been rotated.
Pacu's enumeration identifies old access keys that violate security best practices (AWS recommends rotating keys every 90 days), keys that have never been used (suggesting they were created but forgotten), and users with two active keys (which might indicate incomplete rotation). These represent opportunities for credential compromise or privilege escalation if you can update or create keys.
CreateUser - Creating Backdoor Users
If you have the iam:CreateUser permission, you can create a new IAM user in the account. This is a powerful privilege escalation technique because you can create a user with a known password and access keys, then attach policies to grant that user whatever permissions you want (subject to your own permissions on policy attachment).
Creating a backdoor user involves creating the user entity, creating access keys for programmatic access, optionally creating a login profile for console access, and attaching policies to grant permissions.
The newly created user provides persistent backdoor access even if your original credentials are revoked. To avoid detection, consider using subtle naming like "aws-service-user" or "backup-automation" that blends in with legitimate service accounts. Also avoid attaching obviously powerful policies like AdministratorAccess, instead grant only the specific permissions you need, which is less likely to trigger alerts.
Pacu can automate the backdoor user creation process, including generating strong random passwords and storing the credentials for later use.
The module allows you to specify which policies to attach and whether to create console access, programmatic access, or both. It also provides options for subtle naming and avoiding detection by limiting the permissions granted.
CreateLoginProfile - Password Reset Attack
If you have iam:CreateLoginProfile permission for a user who doesn't currently have console access, you can create a login profile with a password you control, effectively taking over their console access. This works for users created for programmatic access only who never had a console password set.
This technique is particularly effective against service accounts or application users that were created with access keys but no console password. These accounts often have broad permissions for automation purposes but are rarely monitored for console login activity. By setting the --no-password-reset-required flag, you avoid forcing a password change on first login, which could alert the user if they later attempt to access the console.
UpdateLoginProfile - Password Change Attack
If you have iam:UpdateLoginProfile permission, you can change the password for any user that already has console access, effectively taking over their account.
Unlike CreateLoginProfile which only works on users without console access, UpdateLoginProfile targets users who already have a login profile. This is more likely to be noticed because the legitimate user will be locked out when their password stops working. However, it provides immediate access to any permissions the target user has, including console-based workflows and MFA-protected operations if you can satisfy the MFA requirement.
To reduce detection risk, you could change the password, perform your malicious actions quickly, then change it back to the original password. However, you'd need to know the original password hash, which isn't available through the API. A more subtle approach is to target dormant accounts that haven't logged in recently (check PasswordLastUsed) where the password change is less likely to be noticed.
AddUserToGroup - Privilege Escalation via Group Membership
If you have the iam:AddUserToGroup permission, you can add any user (including your own) to any group, instantly inheriting all permissions attached to that group. This is one of the most straightforward privilege escalation techniques when high-privilege groups exist.
The escalation involves identifying a high-privilege group, then adding your user to that group to inherit its permissions immediately.
The permission change is effective immediately. you don't need to obtain new credentials or assume a new session. Your existing access keys or console session will now have the additional permissions from the group. Look for groups named "Administrators," "PowerUsers," "SecurityAudit," or any group with attached policies like AdministratorAccess or PowerUserAccess.
Pacu's privilege escalation scanner identifies when you can use AddUserToGroup for privilege escalation and provides step-by-step instructions.
Pacu can also automate the escalation process, adding your user to the specified group and verifying the new permissions.
AttachUserPolicy - Direct Permission Grant
If you have iam:AttachUserPolicy permission, you can attach any AWS managed policy or customer managed policy to any user, including yourself. This provides direct privilege escalation by granting whatever permissions you want, limited only by permission boundaries if they're configured.
This technique requires that the policy you want to attach already exists. You cannot create new managed policies without iam:CreatePolicy.
However, AWS provides dozens of predefined managed policies including AdministratorAccess (full access), PowerUserAccess (full access except IAM), ReadOnlyAccess, and service-specific policies. If there are custom managed policies in the account, you can attach those as well, potentially granting you permissions the policy creator intended for other users.
PutUserPolicy - Inline Policy Privilege Escalation
If you have iam:PutUserPolicy permission, you can create or modify inline policies attached directly to users. This allows you to grant yourself or another user arbitrary permissions without needing to attach existing managed policies.
Inline policies are less visible than managed policies in many security tools, making this a slightly more subtle privilege escalation method.
Additionally, if you have iam:PutUserPolicy but not iam:AttachUserPolicy, this may be your only path to escalating privileges through policy manipulation. The policy document can grant any permissions you want, limited only by permission boundaries or SCPs if configured.
RemoveUserFromGroup - Denial of Service
If you have iam:RemoveUserFromGroup permission, you can remove users from their groups, effectively revoking all group-inherited permissions. This can be used for denial of service attacks against other users, or to cover your tracks by removing users from security monitoring groups
This attack is most effective against users who derive all or most of their permissions from group memberships rather than directly attached policies.
Removing them from their groups can render them unable to perform their job functions, causing operational disruption. It can also be used defensively by an attacker to remove security team members from groups that grant access to CloudTrail, GuardDuty, or other monitoring services, making it harder for the organization to detect the ongoing attack.
DeleteUser - Account Destruction
If you have iam:DeleteUser and related permissions, you can delete IAM users to cause denial of service or destroy evidence. However, deleting a user requires first removing all of its dependencies including group memberships, attached policies, inline policies, access keys, login profiles, MFA devices, and SSH keys.
This comprehensive deletion process requires multiple IAM permissions including iam:RemoveUserFromGroup, iam:DetachUserPolicy, iam:DeleteUserPolicy, iam:DeleteAccessKey, iam:DeleteLoginProfile, and iam:DeleteUser. Having all of these permissions is relatively uncommon, but if you do have them, you can cause significant disruption by deleting critical users.
Be aware that this generates extensive CloudTrail logs and is highly likely to trigger alerts in any monitored environment.
Targeted Credential Deletion - Selective Denial of Service
Rather than deleting entire users, you can selectively delete specific credential types to disrupt access while being more subtle. This approach targets individual authentication methods, making it harder to detect and diagnose, while still preventing legitimate access.
The iam:DeleteLoginProfile permission allows you to remove a user's console password, preventing them from logging into the AWS Management Console while leaving their programmatic access intact.
This technique is particularly effective against administrators who primarily use the web console for day-to-day operations. They'll be locked out of the console but may not immediately realize why if they don't frequently use the CLI. The disruption is targeted, only console access is affected., which can delay detection compared to complete account lockout.
To maximize impact, target users who:
Have MFA configured for console but not API access
Primarily use the AWS web console for administrative tasks
Manage resources through CloudFormation or other console-based workflows
The iam:DeleteAccessKey permission allows you to delete a user's access keys, preventing all programmatic access including AWS CLI, SDKs, and API calls.
This is more disruptive than deleting login profiles because it breaks:
All automation and scripts using those credentials
CI/CD pipelines configured with the access keys
Applications and services authenticating with the keys
Third-party integrations using the credentials
The impact is immediate and widespread across all systems using those credentials. However, it's also more likely to be quickly detected because automated systems will start failing immediately, generating alerts from application monitoring tools.
The iam:DeleteSSHPublicKey permission allows you to delete SSH public keys used for AWS CodeCommit authentication, preventing Git repository access.
This targets developers and DevOps engineers who use Git over SSH for CodeCommit repositories. The impact includes:
This is often overlooked during incident response because teams focus on access keys and console passwords, allowing the disruption to persist longer. Additionally, SSH key deletion is less commonly logged and monitored compared to access key operations.
The iam:DeleteServiceSpecificCredential permission allows you to delete service-specific credentials like CodeCommit HTTPS credentials, disrupting Git operations over HTTPS.
This prevents HTTPS-based Git operations against CodeCommit, complementing SSH key deletion to completely block repository access. Combined SSH and service-specific credential deletion creates a complete CodeCommit access denial without affecting other AWS services.
For maximum disruption, combine all credential deletion techniques to completely lock a user out of AWS across all access methods.
This script removes all credential types, making the user completely unable to access AWS through any method. The user account still exists (so it doesn't trigger alerts for user deletion), but it's completely unusable until credentials are recreated.
Resources
Last updated