Skip to content

IAM Privilege Escalation Tactics

iam:CreateAccessKey

Example vulnerable policy

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
Operations:
    Type: AWS::IAM::Group
    Properties:
      GroupName: Operations
      Policies: 
        - PolicyName: OperationsPolicy
          PolicyDocument: 
            Version: '2012-10-17'
            Statement:
              - Effect: Allow
                Action:
                  - "iam:CreateAccessKey"
                Resource: '*'

Users in this Operations group have access to create access keys for all users in this AWS environment because of Resource: '*', even for administrators.

Example exploit

1
2
3
aws iam create-access-key \
    --user-name <victim-username> \
    --output text | tee creds.txt

This will output the access key and you can always retrieve with:

1
cat creds.txt

For more information, view this free walkthrough from Cybr.

Impact

The potential impact of this attack is anything from getting access to a low-privileged IAM user all the way to gaining admin privileges, depending on which user the threat actor is able to create access keys for.

How to prevent

Prevent the creation of any new keys in all of your AWS environments with SCPs. This can be a drastic solution for some organizations who still rely on long-term access keys, however, it is a good goal to strive towards as outlined here.

For organizations who simply can't yet get rid of long-term access keys, recommendations are to:

  • Limit access key creation to higher privileged users only, or
  • Ensure that users can only create keys for their own users

This issue is primarily a concern when 1 user has iam:CreateAccessKey permissions for another user as well.

iam:CreateLoginProfile

Example vulnerable policy

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
Operations:
    Type: AWS::IAM::Group
    Properties:
      GroupName: Operations
      Policies: 
        - PolicyName: OperationsPolicy
          PolicyDocument: 
            Version: '2012-10-17'
            Statement:
              - Effect: Allow
                Action:
                  - "iam:CreateLoginProfile"
                Resource: 'arn:aws:iam::123456789012:user/*'

Users in this Operations group have access to create login profiles with whatever password they want (within the AWS account's password policy allowance) for all users in this AWS environment because of Resource: 'arn:aws:iam::123456789012:user/*', even for administrators.

Example exploit

1
2
3
aws iam create-login-profile --user-name <victim-username> \ 
    --password '<arbitrary-password-here>' \
    --no-password-reset-required

Which returns:

1
2
3
4
5
6
7
{
    "LoginProfile": {
        "UserName": "<victim-username>",
        "CreateDate": "2023-11-30T21:46:56+00:00",
        "PasswordResetRequired": false
    }
}

Note that this action will only work if the IAM user does not already have a login profile. Otherwise, you can try to use iam:UpdateLoginProfile.

For more information, view this free walkthrough from Cybr.

Impact

The potential impact of this attack is anything from getting access to a low-privileged IAM user all the way to gaining admin privileges, depending on which user the threat actor is able to create a login profile for.

How to prevent

The best way to prevent this issue is to stop using IAM Users altogether and instead use IAM Identity Center. This can take time to implement, however. As an alternative, if you have to grant this permission, make sure it only gives users the ability to create their own login profile only (unless they're an admin user who's meant to be able to do this).

iam:UpdateLoginProfile

Exactly the same details as the above iam:CreateLoginProfile except the permission is iam:UpdateLoginProfile and the command is different:

1
2
3
aws iam update-login-profile --user-name <victim-username> \
    --password '<arbitrary-password-here>' \
    --no-password-reset-required

For more information, view this free walkthrough from Cybr.

iam:SetDefaultPolicyVersion

Example vulnerable policy

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
DevelopersManagedPolicy:
    Type: AWS::IAM::ManagedPolicy
    Properties:
      ManagedPolicyName: DevelopersPolicy
      PolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Action:
              - "iam:Get*"
              - "iam:List*"
              - "iam:SetDefaultPolicyVersion"
            Resource: 
              - 'arn:aws:iam::123456789012:user/name'
              - 'arn:aws:iam::123456789012:policy/name'

Users with this policy will have access to roll back their policy versions to a prior version. When you make changes to managed policies, by default, AWS will create a new version and keep prior versions ( up to 5). With the iam:SetDefaultPolicyVersion access, a user is able to change the currently active policy version, which can lead to PrivEsc.

For example, let's say that you create a new user and you create a new managed policy for that user (or group of users). To start, you give that managed policy full admin access, and then you go back and modify the permissions to be much more restrictive. That policy will now have a v1 and v2, with v2 granting full admin privileges, but no longer being the active version of that policy. The user realizes this, and they realize they have iam:SetDefaultPolicyVersion access, so they could set v2 as their currently active (default) policy version, which would grant them admin privileges.

Example exploit

1
2
3
aws iam set-default-policy-version \
  --policy-arn arn:aws:iam::123456789012:policy/cg-raynor-policy-iam_privesc_by_rollback_cgidky1t7bwmv8 \
  --version-id v2

For more information, view this free lab from CloudGoat, and re-enactment from Cybr.

Impact

The potential impact of this attack is anything from no change in permissions, minor changes in permissions, or gaining admin privileges, depending on what policy versions the user has access to restore.

How to prevent

The best way to prevent this issue is to stop using IAM Users altogether and instead use IAM Identity Center. This can take time to implement, however. As an alternative, block access to this action for most users except for admin users, and even then, consider the implications.

iam:AddUserToGroup

Example vulnerable policy

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
SeniorDeveloper:
    Type: AWS::IAM::User
    Properties:
      UserName: SeniorDev
      Policies: 
        - PolicyName: senior-manager-policy
          PolicyDocument: 
            Version: '2012-10-17'
            Statement:
              - Effect: Allow
                Action:
                  - "iam:AddUserToGroup"
                Resource: 
                  - 'arn:aws:iam::123456789012:group/division_it/engineering/*'

Developers:
    Type: AWS::IAM::Group
    Properties:
      GroupName: Developers
      Path: '/division_it/engineering/development/'
      Policies: 
        - PolicyName: developers-policy
          PolicyDocument: 
            Version: '2012-10-17'
            Statement:
              - Effect: Allow
                Action:
                  - "whatever-actions-here"
                Resource: '*'

SecretsManagementGroup:
    Type: AWS::IAM::Group
    Properties:
      GroupName: SecretsManagement
      Path: '/division_it/engineering/secrets/'
      Policies:
        - PolicyName: secrets-management-policy
          PolicyDocument: 
            Version: '2012-10-17'
            Statement:
              - Effect: Allow
                Action:
                  - secretsmanager:whatever-actions-here
                Resource: !Sub "arn:aws:secretsmanager:us-east-1:123456789012:secret:some-secret-value-here"
              - Effect: Allow
                Action: secretsmanager:ListSecrets
                Resource: "*"

In this scenario, let's say that the SeniorDev user is part of the Developers group but not the SecretsManagementGroup. However, she has an inline policy granting her access to iam:AddUserToGroup to the resource ARN: arn:aws:iam::123456789012:group/division_it/engineering/*

The Developers group path is '/division_it/engineering/development/'

The SecretsManagementGroup group path is '/division_it/engineering/secrets/'

Because the SeniorDev resource ARN value has a * after the /divion_it/engineering/, that includes the SecretsManagementGroup which is an entirely different team/group that she's not supposed to be able to access. But because she can add users to that group, she can add herself or another user to the SecretsManagementGroup and gain access to the secret value with this ARN: arn:aws:secretsmanager:us-east-1:123456789012:secret:some-secret-value-here.

Example exploit

1
2
3
aws iam add-user-to-group \
  --group-name SecretsManagement \
  --user-name SeniorDev

For more information, view this free walkthrough from Cybr.

Impact

The potential impact of this attack is anything from no change in permissions, minor changes in permissions, or gaining admin privileges, depending on what group(s) the user is able to add themselves or others to.

How to prevent

The best way to prevent this issue is to stop using IAM Users altogether and instead use IAM Identity Center. This can be a big step for some organizations, however. As an alternative, make sure that the resource ARN for which group a user can add users to is very specific! Avoid using * when possible.

iam:AttachUserPolicy

Example vulnerable policy

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
SeniorDeveloper:
    Type: AWS::IAM::User
    Properties:
      UserName: SeniorDev
      Policies: 
        - PolicyName: senior-manager
          PolicyDocument: 
            Version: '2012-10-17'
            Statement:
              - Effect: Allow
                Action:
                  - "iam:AttachUserPolicy"
                Resource: 
                  - 'arn:aws:iam::123456789012:user/*'

In this scenario, the SeniorDev user has iam:AttachUserPolicy privileges, for the resource ARN of 'arn:aws:iam::123456789012:user/*'.

This is a very broad resource set, since it’s essentially granting access to AttachUserPolicy on all users within this AWS account! That includes your own user. However, it could be an even more specific ARN like arn:aws:iam::123456789012:user/seniordev, and this would still apply.

The danger of AttachUserPolicy is that it was designed to attach managed policies, including AWS managed policies. That’s a lot of potential policies, some of which grant admin-level permissions! ( Example). This means our not-so-friendly SeniorDev can grant themselves full admin privileges.

Example exploit

1
2
3
aws iam attach-user-policy \ 
  --user-name SeniorDev \ 
  --policy-arn arn:aws:iam::aws:policy/AdministratorAccess

For more information, view this free walkthrough from Cybr.

Impact

The potential impact of this attack is anything from no change in permissions, minor changes in permissions, or gaining admin privileges, depending on what managed policy they attach to themselves or other users in the account.

How to prevent

Avoid granting this policy unless it's for very specific use cases, in which case you would also want to restrict which managed policies the user is able to attach.

iam:AttachGroupPolicy

Impact

How to prevent

iam:PutUserPolicy

Impact

How to prevent

iam:PutGroupPolicy

Impact

How to prevent

iam:AttachRolePolicy

Impact

How to prevent

iam:PutRolePolicy

Impact

How to prevent

iam:DeactivateMFADevice

Impact

How to prevent

How to detect these PrivEscs in your environments

Coming soon

Additional Resources

  • Learn about most of these PrivEscs hands-on from our sponsor's course: IAM Privilege Escalation Labs[Free&Paid] [Sponsored] (Some of the labs are free and others require a paid membership)