AWS Identity and Access Management (IAM) controls who can access AWS resources and which actions they can perform. However, overly permissive policies, unsafe trust relationships, excessive role permissions, and poorly controlled service integrations can allow a user or compromised workload to obtain privileges beyond those originally intended.

IAM privilege escalation does not always require exploiting a software vulnerability. An attacker may abuse legitimate AWS API operations to modify policies, assume a more powerful role, create credentials, or cause a service to perform privileged actions.

This article examines common IAM privilege-escalation paths, the CloudTrail evidence investigators should examine, practical detection strategies, and defensive controls for reducing the risk of unauthorised privilege expansion.

1. Introduction: When a Read-Only Identity Becomes an Administrator

A cloud security team receives an alert concerning an unfamiliar IAM policy change in an AWS account.

The activity began with an identity that normally performs routine application maintenance. CloudTrail records show that the identity modified an IAM permission, followed by a role assumption and access to resources that were not part of its usual workload.

The account did not initially have unrestricted administrative access. Instead, the sequence of API calls may have allowed the identity to obtain additional permissions through an existing configuration weakness.

The investigation must establish several facts:

• Which identity initiated the activity?

• What permissions did the identity have before the incident?

• Which IAM policies or trust relationships were modified?

• Was a more privileged role assumed?

• Which resources were accessed after the privilege change?

• Was the activity authorised, and what was its impact?

This scenario illustrates a key cloud security principle: effective permissions depend on how identities, policies, roles, trust relationships, and service permissions interact—not simply on the name assigned to a user or role.

2. Understanding AWS IAM Privilege Escalation

AWS IAM privilege escalation occurs when an identity gains or exercises permissions beyond its intended level of access.

This can happen through:

• Overly permissive identity-based policies.

• Policies that allow users to modify their own permissions.

• Unsafe role trust policies.

• Excessive permissions to pass IAM roles to AWS services.

• Misconfigured service roles and resource policies.

• Unrestricted policy-version management.

• Compromised access keys or temporary credentials.

• Weak separation between development and production permissions.

For example, an identity may be permitted to update a Lambda function and pass a powerful execution role to it. If the identity can also cause that function to execute, the combined permissions may create a path to actions available to the execution role.

The individual permissions might have been granted for legitimate development work. The security weakness lies in how they combine.

Authentication versus authorisation

Authentication establishes which identity is attempting to access AWS. Authorisation determines which actions that identity is permitted to perform.

A successful authentication event therefore does not mean that the identity is authorised to perform every subsequent operation. Conversely, a privilege-escalation incident can involve entirely valid authentication followed by unauthorised API activity.

Investigators must evaluate the effective permissions available at the time of the incident, including applicable identity policies, resource policies, permissions boundaries, session policies, service control policies (SCPs), and explicit denies.

3. Common IAM Misconfigurations That Enable Escalation

3.1 Unrestricted IAM Policy Modification

Permissions such as iam:PutUserPolicy, iam:PutRolePolicy, or iam:AttachUserPolicy can be dangerous when granted too broadly.

Depending on the target identity and applicable policy restrictions, these actions may allow an identity to add or attach permissions that substantially increase its capabilities.

Investigators should examine whether a principal can modify its own policies, alter policies attached to another privileged identity, or grant permissions that were supposed to require approval.

Relevant CloudTrail event names include:

• PutUserPolicy

• PutRolePolicy

• AttachUserPolicy

• AttachRolePolicy

• PutGroupPolicy

• AttachGroupPolicy

The presence of one of these events does not automatically establish privilege escalation. The target identity, policy contents, resulting effective permissions, and subsequent activity must be evaluated.

3.2 IAM Policy-Version Manipulation

AWS managed policies support multiple versions, including a default version that determines the permissions applied by the policy.

A principal with excessive policy-version management permissions may be able to create a new version of a managed policy and make it the default.

Relevant API operations include:

• CreatePolicyVersion

• SetDefaultPolicyVersion

If the new default policy grants additional privileges, identities using that policy may gain broader access without a new policy being attached to them.

Investigators should compare the policy versions before and after the event, identify the principal responsible for the change, and determine which identities were affected.

3.3 Dangerous iam:PassRole Permissions

The iam:PassRole permission allows an identity to pass an IAM role to an AWS service that needs to act using that role.

It does not, by itself, allow the principal to assume the role directly. However, it can become a privilege-escalation risk when combined with permissions to configure or execute a service using a more privileged role.

For example, a principal might have permissions to:

1. Create or modify a Lambda function.

2. Pass an execution role to that function.

3. Invoke the function or otherwise cause it to execute.

If the role grants permissions that the principal does not have directly, and no effective restrictions prevent the operation, the service may perform actions using those permissions.

Investigators should examine:

• Which role was passed.

• Whether the role was intended for that service.

• What permissions the role provided.

• Whether the principal could modify or invoke the relevant resource.

• Whether the service actually executed privileged operations.

Restrict iam:PassRole to specific approved role ARNs and, where appropriate, use conditions such as iam:PassedToService to limit which AWS services may receive a role.

3.4 Unsafe Role Trust Policies

IAM roles use trust policies to define which principals can assume them.

A trust policy that allows an unintended principal to assume a powerful role can expose privileged access, particularly when combined with overly broad identity permissions or weak cross-account trust restrictions.

Investigators should examine:

• The role's trust policy before and after the incident.

• The principals permitted to assume the role.

• Cross-account trust relationships.

• Conditions involving external IDs, source identity, organisation identifiers, or other relevant controls.

• CloudTrail records showing role-assumption activity.

Relevant events include UpdateAssumeRolePolicy and AssumeRole.

A role trust policy should not be assessed in isolation. The investigator must determine whether the calling identity could satisfy the trust policy and whether the resulting role session could perform the suspected actions.

3.5 Excessive Permissions to Create or Modify Credentials

Credential-related permissions can introduce persistence or expand access to other identities.

Examples include:

• iam:CreateAccessKey

• iam:UpdateAccessKey

• iam:CreateLoginProfile

• iam:UpdateLoginProfile

The risk depends on the target identity, existing authentication controls, and the principal's effective permissions.

For example, creating an access key for another IAM user may give the requesting identity a way to authenticate as that user if the key can be retrieved and the user has useful permissions. Creating a key does not automatically grant administrative privileges, and the secret access key is generally available only at creation.

Investigators should establish which identity was targeted, whether the credential was created successfully, whether it was subsequently used, and which resources it accessed.

4. Reconstructing a Privilege-Escalation Chain

A single API event may appear harmless when examined independently. The sequence of operations often reveals the security significance.

Consider this hypothetical investigation:

Time (UTC)CloudTrail eventInvestigative significance10:12ConsoleLogin or an API authentication context is observedEstablishes an initial identity or session, subject to the available evidence10:16CreatePolicyVersionMay indicate a managed policy was modified10:17SetDefaultPolicyVersionMay activate the changed permissions10:21AssumeRoleMay establish a session for another role10:24ListBuckets or another resource-discovery API callMay indicate reconnaissance using the resulting identity10:29Sensitive resource API operationsMay indicate use of the expanded permissions

This is an illustrative sequence, not evidence of a real incident. Other escalation paths may involve inline policies, role trust changes, service roles, credentials, or different API calls.

The investigator should answer four questions at each stage:

1. Did the API operation succeed?

2. What permissions or access changed as a result?

3. Can the next event be linked to the same identity, session, or activity?

4. Was the activity authorised?

Correlating the events provides a stronger basis for assessment than treating each event as an isolated alert.

5. Investigating IAM Privilege Escalation with CloudTrail

AWS CloudTrail is a key source for investigating IAM changes and subsequent API activity. It records supported AWS API calls and related event metadata, subject to the trail, event configuration, service coverage, and retention available.

For each relevant event, collect:

• eventTime

• eventSource

• eventName

• awsRegion

• sourceIPAddress

• userAgent

• userIdentity

• requestParameters

• responseElements, where available

• errorCode and errorMessage, where present

• requestID and eventID

For assumed-role activity, inspect the available session and identity fields, including role session names, principal identifiers, session issuer information, and source identity when configured.

Example: Searching for IAM policy changes in CloudTrail Lake

The following illustrative SQL query searches a CloudTrail Lake event data store for several high-risk IAM operations. Replace the event data store identifier with the one used in your environment.

SELECT eventTime, eventSource, eventName, awsRegion, sourceIPAddress, userIdentity, requestParameters, responseElements, errorCode FROM YOUR_EVENT_DATA_STORE_ID WHERE eventSource = 'iam.amazonaws.com' AND eventName IN ( 'PutUserPolicy', 'PutRolePolicy', 'AttachUserPolicy', 'AttachRolePolicy', 'CreatePolicyVersion', 'SetDefaultPolicyVersion', 'UpdateAssumeRolePolicy' ) ORDER BY eventTime DESC;

This query is a starting point, not a complete escalation detector. Confirm the query syntax and field availability for the CloudTrail Lake event data store and schema in use. The query identifies relevant operations; it does not determine whether a permission change created an exploitable path.

Investigating role assumptions

Review AssumeRole events and correlate them with subsequent actions performed under the resulting role session.

Questions to investigate include:

• Which principal requested the role session?

• Which role was assumed?

• Was the session duration expected?

• Was the request consistent with the identity's normal behaviour?

• Did the role session access resources outside its usual scope?

• Is there a plausible relationship between a preceding IAM change and the role assumption?

Use available principal and session identifiers rather than relying only on IP addresses or session names, which may be shared, reused, or insufficient for attribution.

6. Detecting Suspicious Permission Changes in a SIEM

A robust detection strategy combines API activity, permission context, identity history, and subsequent behaviour.

Detection 1: High-Risk IAM Changes

Alert when an identity modifies a privileged policy, changes a role trust relationship, or alters permissions outside an approved workflow.

Potential event names include:

• PutRolePolicy

• AttachRolePolicy

• CreatePolicyVersion

• SetDefaultPolicyVersion

• UpdateAssumeRolePolicy

Improve precision by checking the target role, policy content, principal privileges, change-management approvals, and whether the action was performed by an approved automation pipeline.

Detection 2: IAM Change Followed by Privileged Role Use

Conceptual detection logic:

IF an identity performs a high-risk IAM change AND a related identity or session subsequently gains access to a more privileged role AND sensitive API operations follow: correlate the events evaluate the resulting permissions raise an investigation alert

The correlation should account for the time window, session relationships, role chaining, and legitimate administrative workflows.

Detection 3: Unusual Credential Creation

Alert on unexpected access-key or login-profile creation, especially when the target is a privileged identity or the operation is performed outside approved provisioning processes.

Correlate credential creation with subsequent authentication, source IP changes, unusual user agents, and sensitive API operations.

Detection 4: Unexpected Service-Role Use

Monitor service configuration changes and role assignments that allow workloads to perform actions beyond their expected responsibilities.

For Lambda-based workflows, investigate changes to function configuration, role assignment, invocation activity, and subsequent AWS API calls. Other services require service-specific telemetry and correlation.

Detection 5: Changes to Monitoring and Logging

Monitor attempts to weaken security visibility, including changes to CloudTrail configuration, logging destinations, or other monitoring controls.

Where relevant, examine operations such as StopLogging, DeleteTrail, and UpdateTrail, along with any applicable configuration-management and organisation-level audit records.

A logging change is not proof of malicious intent, but an unexpected change followed by privileged activity warrants investigation.

7. A Practical SOC Investigation Workflow

Step 1: Validate the Alert

Identify the triggering API event, the AWS account, region, principal, target resource, and whether the operation succeeded.

Distinguish successful permission changes from denied API attempts. A denied attempt may still be useful evidence of reconnaissance or attempted escalation.

Step 2: Identify the Principal

Determine whether the event originated from:

• An IAM user.

• An assumed IAM role.

• An AWS service role.

• A federated identity.

• An automated deployment pipeline.

• A potentially compromised credential.

Correlate CloudTrail with identity-provider, single sign-on, PAM, endpoint, and workload logs where available.

Step 3: Reconstruct Effective Permissions

Capture the relevant policies, role trust relationship, permissions boundary, and applicable organisational controls.

Determine which permissions were available before the event and which became available afterwards. Consider resource-based policies, session policies, SCPs, and explicit denies.

AWS IAM Access Analyzer and policy simulation tools can help assess policy implications, but simulation results must be interpreted against the actual request context and applicable controls.

Step 4: Identify the Escalation Mechanism

Determine whether the potential escalation involved policy modification, role assumption, credential creation, service-role abuse, or another permission combination.

Do not classify an event as privilege escalation merely because it contains an IAM API call. Establish the specific path by which additional privileges became available.

Step 5: Trace Post-Escalation Activity

Review subsequent API calls for resource discovery, secret access, storage access, compute changes, database operations, or other sensitive actions.

Correlate the activity with the suspected role session or credential, taking into account that some events may not contain enough information for definitive attribution.

Step 6: Determine Impact

Establish whether the identity only changed permissions, successfully used the expanded access, or accessed sensitive resources.

Look for evidence of data retrieval, resource modification, new credentials, persistence, lateral movement between accounts, or attempts to weaken monitoring.

Separate confirmed actions from plausible but unverified possibilities.

Step 7: Contain and Remediate

Depending on the evidence and operational impact:

• Revoke unnecessary permissions.

• Restore approved policy versions.

• Correct unsafe trust relationships.

• Disable or rotate compromised credentials.

• Restrict affected role sessions or identity access.

• Review and terminate suspicious workloads when appropriate.

• Preserve CloudTrail and related evidence.

• Validate that monitoring remains operational.

Containment should be coordinated with cloud owners and incident responders. Avoid deleting resources or credentials before preserving the evidence required to understand the incident, unless immediate containment takes priority.

8. MITRE ATT&CK Mapping

Potential mappings depend on the observed activity and should be verified against the current ATT&CK knowledge base.

TechniqueATT&CK IDWhen it may applyValid AccountsT1078An existing AWS identity or credential is used for unauthorised activityAccount ManipulationT1098Evidence shows that account settings, permissions, or access mechanisms were altered to maintain or expand accessAdditional Cloud CredentialsT1098.001Additional cloud credentials are created or manipulated in a manner that supports persistenceAdditional Cloud RolesT1098.003Additional cloud roles are created or manipulated in a manner that supports persistenceCloud AccountsT1078.004Cloud accounts are used as part of adversarial activity

Not every IAM policy change maps to Account Manipulation, and not every privilege-escalation path creates persistence. Select techniques based on the behaviour demonstrated by the evidence.

Reference: https://attack.mitre.org/

9. Preventing AWS IAM Privilege Escalation

Apply Least Privilege

Grant only the permissions required for each role or workload. Avoid broad permissions such as unrestricted IAM policy modification or unnecessary administrative access.

Review permissions regularly and remove privileges that are no longer required.

Restrict iam:PassRole

Limit role passing to approved role ARNs and required AWS services. Ensure that a user who can configure a service cannot unnecessarily attach or use a more powerful role.

Protect Policy Management

Restrict who can create policy versions, change default versions, attach policies, or modify inline policies. Require review and approval for high-impact changes.

Secure Role Trust Policies

Limit trusted principals, restrict cross-account relationships, and use appropriate trust-policy conditions. Review trust relationships for unintended access paths.

Use Permissions Boundaries and SCPs Appropriately

Permissions boundaries and service control policies can restrict the maximum permissions available to identities within their respective scopes. They do not grant permissions by themselves, and they do not replace careful policy design.

Use Temporary Credentials

Prefer appropriately scoped temporary credentials and federated access over long-lived access keys where practical. Protect credential issuance and review unexpected key creation.

Centralise and Protect Cloud Logging

Enable suitable CloudTrail management-event logging, centralise audit records, restrict modification and deletion, and monitor changes to logging configuration.

Confirm that the relevant events are actually being collected and retained in the accounts and regions that matter to the investigation.

Monitor Effective Permissions, Not Just API Names

An IAM change can be harmless in one context and dangerous in another. Evaluate the target identity, policy contents, resulting permissions, role relationships, and subsequent use.

10. Key Lessons for Cloud Security Analysts

IAM privilege-escalation investigations require an understanding of how AWS permissions combine.

The most important questions are:

• What permissions did the identity have before the event?

• Which policy, trust relationship, credential, or service configuration changed?

• Did the change create a practical path to additional privileges?

• Was the path successfully used?

• Which resources were accessed after the change?

• Is the activity consistent with an approved administrative workflow?

• What evidence supports the incident classification?

A successful investigation explains the escalation mechanism, demonstrates the resulting access where possible, identifies the affected resources, and documents any gaps in attribution or telemetry.

Conclusion

AWS IAM privilege escalation often results from the interaction of legitimate permissions rather than a single software vulnerability. Excessive policy-management permissions, unsafe trust relationships, unrestricted role passing, and weak credential controls can create pathways to broader access.

For SOC teams, CloudTrail provides essential evidence of IAM changes and subsequent API activity. However, detecting a suspicious event is only the first step. Investigators must reconstruct effective permissions, correlate identity and session activity, establish whether additional privileges were used, and determine the impact.

Organisations can reduce the risk through least privilege, tightly scoped role passing, protected policy management, secure trust relationships, centralised logging, and continuous review of effective permissions.

The objective is to identify and close unintended privilege paths before they can be used to access sensitive data or control critical cloud resources.

Further Reading

• AWS IAM — Security Best Practices

• AWS IAM — Policy Evaluation Logic

• AWS CloudTrail User Guide

• AWS IAM Access Analyzer

• MITRE ATT&CK