IAM Permissions on Other Users

• CreateAccessKey
  An attacker with the iam:CreateAccessKey permission on another IAM user can generate a new access key ID and secret access key for that user, provided they do not already have two active access key pairs (which is a security best practice to avoid). This would allow the attacker to gain access to the user’s resources.

• CreateLoginProfile
  An attacker with the iam:CreateLoginProfile permission can create a login profile (password) for an IAM user who does not yet have one, enabling the attacker to authenticate and access the AWS Management Console as that user.

• UpdateLoginProfile
  With the iam:UpdateLoginProfile permission, an attacker can alter the password of an existing login profile for an IAM user, potentially locking out the legitimate user and gaining unauthorized console access.

• AddUserToGroup
  An attacker with the iam:AddUserToGroup permission can add themselves to an IAM group with elevated privileges, such as an “Admin” group, thereby gaining additional access rights in the AWS environment.

Permissions on Policies

• CreateNewPolicyVersion
  The iam:CreatePolicyVersion permission allows an attacker to create a new version of an IAM policy they have access to. This could enable the attacker to modify the policy’s permissions, effectively granting themselves additional privileges.

• SetExistingDefaultPolicyVersion
  With the iam:SetDefaultPolicyVersion permission, an attacker could change the default version of a policy to a previously created but inactive version that contains more permissive settings, potentially escalating their access.

• AttachUserPolicy
  An attacker with the iam:AttachUserPolicy permission can attach a higher-privileged policy to an IAM user they have access to, thus elevating their own permissions or those of the compromised user.

• AttachGroupPolicy
  The iam:AttachGroupPolicy permission enables an attacker to attach a more permissive policy to a group they belong to, thereby escalating privileges for all group members, including themselves.

• AttachRolePolicy
  With the iam:AttachRolePolicy permission, an attacker can attach a policy to a role they have access to, granting themselves or others additional permissions associated with that role.

• PutUserPolicy
  The iam:PutUserPolicy permission allows an attacker to create or update an inline policy for a user, effectively granting additional permissions directly to that user.

• PutGroupPolicy
  Similarly, the iam:PutGroupPolicy permission enables an attacker to create or update an inline policy for an IAM group, thereby extending the group’s permissions and, by extension, the attacker’s own privileges.

• PutRolePolicy
  An attacker with the iam:PutRolePolicy permission can create or modify an inline policy for a role, granting the attacker or other users elevated privileges through the role.

Updating an AssumeRole Policy

• UpdateAssumeRolePolicy
  The iam:UpdateAssumeRolePolicy permission allows an attacker to modify the AssumeRolePolicyDocument of a role, potentially enabling them to assume that role if they gain the sts:AssumeRole permission.

• iam:PassRole
  The iam:PassRole permission enables an attacker to pass a role to an AWS service on behalf of a user or resource, thereby allowing privilege escalation by leveraging the permissions attached to that role.

Escalation via AWS Services

• CreateEC2WithExistingIP
  An attacker with the iam:PassRole and ec2:RunInstances permissions can create a new EC2 instance and attach an existing IAM role to it, gaining operating system-level access and using the permissions associated with that role.

• PassExistingRoleToNewLambdaThenInvoke
  An attacker with the iam:PassRole, lambda:CreateFunction, and lambda:InvokeFunction permissions can pass a role to a new Lambda function, which could then execute arbitrary code under the privileges of that role.

• PassExistingRoleToNewLambdaThenTriggerWithNewDynamo
  An attacker with the iam:PassRole, lambda:CreateFunction, and lambda:CreateEventSourceMapping (along with optional dynamodb:PutItem or dynamodb:CreateTable permissions) can escalate privileges by passing a role to a new Lambda function and triggering it with a DynamoDB event source.

• PassExistingRoleToNewLambdaThenTriggerWithExistingDynamo
  Similar to the previous scenario, this attack allows privilege escalation by passing a role to a new Lambda function, which can be triggered by an existing DynamoDB event source, using the role’s permissions to perform unauthorized actions.

• EditExistingLambdaFunctionWithRole
  With the lambda:UpdateFunctionCode permission, an attacker can modify the code of an existing Lambda function that has a role attached, enabling them to execute arbitrary actions under the privileges of that role.

• PassExistingRoleToNewGlueDevEndpoint
  An attacker with the iam:PassRole and glue:CreateDevEndpoint permissions can create a new AWS Glue development endpoint and pass an existing IAM role to it, potentially gaining elevated privileges through that role.

• PassExistingRoleToCloudFormation
  With the iam:PassRole and cloudformation:CreateStack permissions, an attacker could create a CloudFormation stack that executes actions or provisions resources using the permissions of the passed role, effectively escalating their privileges.

• PassExistingRoleToNewDataPipeline
  An attacker with the iam:PassRole, datapipeline:CreatePipeline, and datapipeline:PutPipelineDefinition permissions can escalate privileges by passing a role to a new Data Pipeline, running arbitrary commands or creating additional resources under the role’s permissions.

Privilege Escalation Using AWS Services

• UpdateExistingGlueDevEndpoint
  An attacker with the glue:UpdateDevEndpoint permission could modify the SSH public key of an existing Glue development endpoint, enabling SSH access to the endpoint with the privileges granted by the associated IAM role.

For further details, refer to the CloudSpanning documentation.