Skip to main content

Escalation Methods

#DescriptionPossible ImpactEscalation ActionsResources
01An attacker with the iam:CreatePolicyVersion permission can create a new version of an IAM policy that they have access to. This allows them to define their own custom permissions. When creating a new policy version, it needs to be set as the default version to take effect, which you would think would require the iam:SetDefaultPolicyVersion permission, but when creating a new policy version, it is possible to include a flag (--set-as-default) that will automatically create it as the new default version. That flag does not require the iam:SetDefaultPolicyVersion permission to use.
This privilege escalation method could allow a user to gain full administrator access of the AWS account.
  • iam:CreatePolicyVersion
02An attacker with the iam:PassRole and ec2:RunInstances permissions can create a new EC2 instance that they will have operating system access to and pass an existing EC2 instance profile/role to it. They can then login to the instance and request the associated AWS keys from the EC2 instance meta data, which gives them access to all the permissions that the associated instance profile/role has.This attack would give an attacker access to the set of permissions that the instance profile/role has, which again could range from no privilege escalation to full administrator access of the AWS account.
  • ec2:RunInstances
  • iam:PassRole
03An attacker with the iam:CreateAccessKey permission on other users can create an access key ID and secret access key belonging to another user in the AWS environment, if they don’t already have two sets associated with them (which best practice says they shouldn’t).This method would give an attacker the same level of permissions as any user they were able to create an access key for, which could range from no privilege escalation to full administrator access to the account.
  • iam:CreateAccessKey
04An attacker with the iam:CreateLoginProfile permission on other users can create a password to use to login to the AWS console on any user that does not already have a login profile setup.This method would give an attacker the same level of permissions as any user they were able to create a login profile for, which could range from no privilege escalation to full administrator access to the account.
  • iam:CreateLoginProfile
05An attacker with the iam:UpdateLoginProfile permission on other users can change the password used to login to the AWS console on any user that already has a login profile setup.This method would give an attacker the same level of permissions as any user they were able to update the login profile for, which could range from no privilege escalation to full administrator access to the account.
  • iam:UpdateLoginProfile
06An attacker with the iam:AttachUserPolicy permission can escalate privileges by attaching a policy to a user that they have access to, adding the permissions of that policy to the attacker.An attacker would be able to use this method to attach the AdministratorAccess AWS managed policy to a user, giving them full administrator access to the AWS environment.
  • iam:AttachUserPolicy
07An attacker with the iam:AttachGroupPolicy permission can escalate privileges by attaching a policy to a group that they are a part of, adding the permissions of that policy to the attacker.An attacker would be able to use this method to attach the AdministratorAccess AWS managed policy to a group, giving them full administrator access to the AWS environment.
  • iam:AttachGroupPolicy
08An attacker with the iam:AttachRolePolicy permission can escalate privileges by attaching a policy to a role that they have access to, adding the permissions of that policy to the attacker.An attacker would be able to use this method to attach the AdministratorAccess AWS managed policy to a role, giving them full administrator access to the AWS environment.
  • iam:AttachRolePolicy
09An attacker with the iam:PutUserPolicy permission can escalate privileges by creating or updating an inline policy for a user that they have access to, adding the permissions of that policy to the attacker.Due to the ability to specify an arbitrary policy document with this method, the attacker could specify a policy that gives permission to perform any action on any resource, ultimately escalating to full administrator privileges in the AWS environment.
  • iam:PutUserPolicy
10An attacker with the iam:PutGroupPolicy permission can escalate privileges by creating or updating an inline policy for a group that they are a part of, adding the permissions of that policy to the attacker.Due to the ability to specify an arbitrary policy document with this method, the attacker could specify a policy that gives permission to perform any action on any resource, ultimately escalating to full administrator privileges in the AWS environment.
  • iam:PutGroupPolicy
11An attacker with the iam:PutRolePolicy permission can escalate privileges by creating or updating an inline policy for a group that they are a part of, adding the permissions of that policy to the attacker.Due to the ability to specify an arbitrary policy document with this method, the attacker could specify a policy that gives permission to perform any action on any resource, ultimately escalating to full administrator privileges in the AWS environment.
  • iam:PutRolePolicy
12An attacker with the iam:AddUserToGroup permission can use it to add themselves to an existing IAM Group in the AWS account.The attacker would be able to gain privileges of any existing group in the account, which could range from no privilege escalation to full administrator access to the account.
  • iam:AddUserToGroup
13An attacker with the iam:UpdateAssumeRolePolicy and sts:AssumeRole permissions would be able to change the assume role policy document of any existing role to allow them to assume that role.This would give the attacker the privileges that are attached to any role in the account, which could range from no privilege escalation to full administrator access to the account.
  • iam:UpdateAssumeRolePolicy
14An attacker with the iam:UpdateAssumeRolePolicy and sts:AssumeRole permissions would be able to change the assume role policy document of any existing role to allow them to assume that role. Additionally, the attacker can attach an existing over-privileged managed policy to that role.This would give the attacker the privileges of the policy newly attached to an existing role, which could range from no privilege escalation to full administrator access to the account.
  • iam:UpdateAssumeRolePolicy
  • iam:AttachRolePolicy
15An attacker with the iam:UpdateAssumeRolePolicy and sts:AssumeRole permissions would be able to change the assume role policy document of any existing role to allow them to assume that role. Additionally, the attacker can put a new over-privileged inline policy to that role.This would give the attacker the privileges of the policy newly attached to an existing role, which could range from no privilege escalation to full administrator access to the account.
  • iam:UpdateAssumeRolePolicy
  • iam:PutRolePolicy
16A user with the iam:PassRole, lambda:CreateFunction, and lambda:InvokeFunction permissions can escalate privileges by passing an existing IAM role to a new Lambda function that includes code to import the relevant AWS library to their programming language of choice, then using it perform actions of their choice. The code could then be run by invoking the function through the AWS API.This would give a user access to the privileges associated with any Lambda service role that exists in the account, which could range from no privilege escalation to full administrator access to the account.
  • lambda:CreateFunction
  • iam:PassRole
  • lambda:InvokeFunction
17A user with the iam:PassRole, lambda:CreateFunction, and lambda:AddPermission permissions can escalate privileges by passing an existing IAM role to a new Lambda function that includes code to import the relevant AWS library to their programming language of choice, then using it perform actions of their choice. The code could then be run by using lambda:AddPermission to allow cross-account invocation, then invoking it cross-account with their own attacker account.This would give a user access to the privileges associated with any Lambda service role that exists in the account, which could range from no privilege escalation to full administrator access to the account.
  • lambda:CreateFunction
  • iam:PassRole
  • lambda:AddPermission
18A user with the iam:PassRole, lambda:CreateFunction, and lambda:CreateEventSourceMapping (and possibly dynamodb:PutItem and dynamodb:CreateTable) permissions, but without the lambda:InvokeFunction permission, can escalate privileges by passing an existing IAM role to a new Lambda function that includes code to import the relevant AWS library to their programming language of choice, then using it perform actions of their choice. They then would need to either create a DynamoDB table or use an existing one, to create an event source mapping for the Lambda function pointing to that DynamoDB table. Then they would need to either put an item into the table or wait for another method to do so that the Lambda function will be invoked.A user with the iam:PassRole, lambda:CreateFunction, and lambda:CreateEventSourceMapping (and possibly dynamodb:PutItem and dynamodb:CreateTable) permissions, but without the lambda:InvokeFunction permission, can escalate privileges by passing an existing IAM role to a new Lambda function that includes code to import the relevant AWS library to their programming language of choice, then using it perform actions of their choice. They then would need to either create a DynamoDB table or use an existing one, to create an event source mapping for the Lambda function pointing to that DynamoDB table. Then they would need to either put an item into the table or wait for another method to do so that the Lambda function will be invoked.
  • lambda:CreateFunction
  • iam:PassRole
  • lambda:CreateEventSourceMapping
19An attacker with the lambda:UpdateFunctionCode permission could update the code in an existing Lambda function with an IAM role attached so that it would import the relevant AWS library in that programming language and use it to perform actions on behalf of that role. They would then need to wait for it to be invoked if they were not able to do so directly, but if it already exists, there is likely some way that it will be invoked.This would give an attacker access to the privileges associated with the Lambda service role that is attached to that function, which could range from no privilege escalation to full administrator access to the account.
  • lambda:UpdateFunctionCode
20An attacker with the iam:PassRole and glue:CreateDevEndpoint permissions could create a new AWS Glue development endpoint and pass an existing service role to it. They then could SSH into the instance and use the AWS CLI to have access of the permissions the role has access to.
An attacker with the iam:PassRole and glue:CreateDevEndpoint permissions could create a new AWS Glue development endpoint and pass an existing service role to it. They then could SSH into the instance and use the AWS CLI to have access of the permissions the role has access to.
  • glue:CreateDevEndpoint
  • iam:PassRole
21An attacker with the glue:UpdateDevEndpoint permission would be able to update the associated SSH public key of an existing Glue development endpoint, to then SSH into it and have access to the permissions the attached role has access to.
An attacker with the glue:UpdateDevEndpoint permission would be able to update the associated SSH public key of an existing Glue development endpoint, to then SSH into it and have access to the permissions the attached role has access to.
  • glue:UpdateDevEndpoint
22An attacker with the iam:PassRole and cloudformation:CreateStack permissions would be able to escalate privileges by creating a CloudFormation template that will perform actions and create resources using the permissions of the role that was passed when creating a CloudFormation stack.An attacker with the iam:PassRole and cloudformation:CreateStack permissions would be able to escalate privileges by creating a CloudFormation template that will perform actions and create resources using the permissions of the role that was passed when creating a CloudFormation stack.
  • cloudformation:CreateStack
  • iam:PassRole
23An attacker with the iam:PassRole, datapipeline:CreatePipeline, and datapipeline:PutPipelineDefinition permissions would be able to escalate privileges by creating a pipeline and updating it to run an arbitrary AWS CLI command or create other resources, either once or on an interval with the permissions of the role that was passed in.
An attacker with the iam:PassRole, datapipeline:CreatePipeline, and datapipeline:PutPipelineDefinition permissions would be able to escalate privileges by creating a pipeline and updating it to run an arbitrary AWS CLI command or create other resources, either once or on an interval with the permissions of the role that was passed in.
  • datapipeline:CreatePipeline
  • datapipeline:PutPipelineDefinition
  • iam:PassRole
24An attacker with the codestar:CreateProjectFromTemplate permission can leverage an undocumented CodeStar API to escalate privileges by creating a new CodeStar project from a built-in template. This method also allows arbitrary CloudFormation resource creation under a different set of privileges.
An attacker with the codestar:CreateProjectFromTemplate permission can leverage an undocumented CodeStar API to escalate privileges by creating a new CodeStar project from a built-in template. This method also allows arbitrary CloudFormation resource creation under a different set of privileges.
  • codestar:CreateProject
  • iam:PassRole
25An attacker with the lambda:UpdateFunctionConfiguration permission can escalate permissions by attaching a Lambda layer to an existing function to override a library that is in use by the function, where their malicious code could utilize the function's IAM role for AWS API calls.An attacker with the lambda:UpdateFunctionConfiguration permission can escalate permissions by attaching a Lambda layer to an existing function to override a library that is in use by the function, where their malicious code could utilize the function's IAM role for AWS API calls.
  • lambda:UpdateFunctionConfiguration
26An attacker with the lambda:UpdateFunctionConfiguration permission can escalate permissions by attaching a Lambda layer to an existing function to override a library that is in use by the function, where their malicious code could utilize the function's IAM role for AWS API calls. In combination with iam:PassRole, the operation also allows attaching a different role to the lambda which can lead to privilege escalation.An attacker with the lambda:UpdateFunctionConfiguration permission can escalate permissions by attaching a Lambda layer to an existing function to override a library that is in use by the function, where their malicious code could utilize the function's IAM role for AWS API calls. In combination with iam:PassRole, the operation also allows attaching a different role to the lambda which can lead to privilege escalation.
  • lambda:UpdateFunctionConfiguration
  • iam:PassRole
27An attacker with the sagemaker:CreateNotebookInstance, sagemaker:CreatePresignedNotebookInstanceUrl, and iam:PassRole permissions can escalate privileges by passing a role to a new SageMaker Jupyter notebook. Then, through the Jupyter UI, they can access the credentials belonging to the notebook for further exploitation.An attacker with the sagemaker:CreateNotebookInstance, sagemaker:CreatePresignedNotebookInstanceUrl, and iam:PassRole permissions can escalate privileges by passing a role to a new SageMaker Jupyter notebook. Then, through the Jupyter UI, they can access the credentials belonging to the notebook for further exploitation.
  • sagemaker:CreateNotebookInstance
  • iam:PassRole
  • sagemaker:CreatePresignedNotebookInstanceUrl
28An attacker with the sagemaker:CreatePresignedNotebookInstanceUrl permission can escalate privileges by creating a signed URL For an existing SageMaker Jupyter notebook. Then, through the Jupyter UI, they can access the credentials belonging to the notebook for further exploitation.An attacker with the sagemaker:CreatePresignedNotebookInstanceUrl permission can escalate privileges by creating a signed URL For an existing SageMaker Jupyter notebook. Then, through the Jupyter UI, they can access the credentials belonging to the notebook for further exploitation.
  • sagemaker:CreatePresignedNotebookInstanceUrl
29An attacker with iam:CreateRole and iam:AttachRolePolicy permission can escalate privileges by attaching a policy to a newly created role which allows the attacking user to assume it, adding the permissions of that policy to the attacker.An attacker would be able to use this method to attach the AdministratorAccess AWS managed policy to a new role, and assume it, giving them full administrator access to the AWS environment.
  • iam:CreateRole
  • iam:AttachRolePolicy
30An attacker with iam:CreateRole and iam:PutRolePolicy permission can escalate privileges by adding a new inline-policy to a newly created role which allows the attacking user to assume it, adding the permissions of that policy to the attacker.An attacker would be able to use this method to attach a AdministratorAccess-like AWS inline policy (allowing access to all actions/resources) to a new role, and assume it, giving them full administrator access to the AWS environment.
  • iam:CreateRole
  • iam:PutRolePolicy
31An attacker with the iam:PassRole and appstream:CreateImageBuilder permissions can create a new AppStream image builder that they will have operating system access to and pass an existing AppStream execution role to it. After creation, the image builder is automatically started and the attacker can login to it and request the associated AWS keys from the builder meta data, which gives them access to all the permissions that the associated role has.This attack would give an attacker access to the set of permissions that the execution role has, which again could range from no privilege escalation to full administrator access of the AWS account.
  • appstream:CreateImageBuilder
  • iam:PassRole
    32An attacker with the ec2-instance-connect:SendSSHPublicKey permission can set a new public SSH key to an existing instance. The attacker can then use his known SSH private key to login and get access to the instance's terminal, which gives them access to all the permissions that the associated role has. The instance needs to be reachable through an attacker owned network.This attack would give an attacker access to the set of permissions that the execution role has, which again could range from no privilege escalation to full administrator access of the AWS account.
    • ec2-instance-connect:SendSSHPublicKey
    33An attacker with the ssm:StartSession permission can start a maintenance session to an existing EC2 instance. The attacker thereby gains terminal access to the instance, which effectively gives them access to all the permissions that the associated role has. The instance needs to have ssm enabled.This attack would give an attacker access to the set of permissions that the execution role has, which again could range from no privilege escalation to full administrator access of the AWS account.
    • ssm:StartSession
    34An attacker with the ssm:SendCommand permission can run arbitrary commands on an existing EC2 instance. The attacker thereby gains terminal access to the instance, which effectively gives them access to all the permissions that the associated role has and potential for network traversal. The instance needs to have ssm enabled.This attack would give an attacker access to the set of permissions that the execution role has, which again could range from no privilege escalation to full administrator access of the AWS account.
    • ssm:SendCommand
    35An attacker with the iam:PassRole, codebuild:UpdateProject, and codebuild:StartBuild permissions would be able to escalate privileges by updating an existing CodeBuild project to spawn a build server with a reverse shell, and attaching an arbitrary role to it. The attacker thereby gains terminal access to the build instance, which effectively gives them access to all the permissions that the associated role has and potential for network traversal.
    		An attacker with the iam:PassRole, codebuild:UpdateProject, and codebuild:StartBuild permissions would be able to escalate privileges by updating an existing CodeBuild project to spawn a build server with a reverse shell, and attaching an arbitrary role to it. The attacker thereby gains terminal access to the build instance, which effectively gives them access to all the permissions that the associated role has and potential for network traversal.
    • codebuild:UpdateProject
    • codebuild:StartBuild
    • iam:PassRole
    36An attacker with the iam:PassRole, codebuild:CreateProject, and codebuild:StartBuild permissions would be able to escalate privileges by creating a CodeBuild project that spawns a build server with a reverse shell, and attaching an arbitrary role to it. The attacker thereby gains terminal access to the build instance, which effectively gives them access to all the permissions that the associated role has and potential for network traversal.
    		An attacker with the iam:PassRole, codebuild:CreateProject, and codebuild:StartBuild permissions would be able to escalate privileges by creating a CodeBuild project that spawns a build server with a reverse shell, and attaching an arbitrary role to it. The attacker thereby gains terminal access to the build instance, which effectively gives them access to all the permissions that the associated role has and potential for network traversal.
    • codebuild:CreateProject
    • codebuild:StartBuild
    • iam:PassRole
    37An attacker with the iam:PassRole, codebuild:CreateProject, and codebuild:StartBuildBatch permissions would be able to escalate privileges by creating a CodeBuild project that spawns a build server with a reverse shell, and attaching an arbitrary role to it. The attacker thereby gains terminal access to the build instance, which effectively gives them access to all the permissions that the associated role has and potential for network traversal.
    		An attacker with the iam:PassRole, codebuild:CreateProject, and codebuild:StartBuildBatch permissions would be able to escalate privileges by creating a CodeBuild project that spawns a build server with a reverse shell, and attaching an arbitrary role to it. The attacker thereby gains terminal access to the build instance, which effectively gives them access to all the permissions that the associated role has and potential for network traversal.
    • codebuild:CreateProject
    • codebuild:StartBuildBatch
    • iam:PassRole

    At CodeShield, we are continuously performing research to keep the set of privilege escalation up-to-date. We use public as well non-public sources to extend the set. For public reference, we state the source in the table. Most of the current scenarios are copyright (C) 2018 Rhino Security Labs, Inc. licensed under the BSD 3-Clause https://github.com/RhinoSecurityLabs/AWS-IAM-Privilege-Escalation

    Special thanks goes to Rodrigo Montoro for sharing his AppStream escalation method with us.