AWS: IAM UpdateLoginProfile Abuse

by

Author: Raj Chandel (published on Hacking Articles)
Published: January 16, 2026
Source: https://www.hackingarticles.in/aws-iam-updateloginprofile-abuse/

Summary

This Hacking Articles tutorial demonstrates an AWS IAM privilege-escalation technique based on the iam:UpdateLoginProfile permission: a low-privileged IAM user who is allowed to call UpdateLoginProfile against a higher-privileged user can reset that user’s AWS Console password and then sign in as them. It is a hands-on lab and general technique explainer rather than a specific vulnerability disclosure — there is no CVE. Like the other posts in this series (CreateAccessKey, AssumeRole), it illustrates how a narrowly useful-looking IAM permission becomes an administrative takeover path when scoped to other users.

Technical Details

The AWS API action UpdateLoginProfile changes the console password for an IAM user that already has a login profile (it is the counterpart to CreateLoginProfile, which sets an initial password for a user who has no console access yet). If an IAM policy allows a principal to call UpdateLoginProfile on other users, that principal can overwrite the target’s console password with one of their choosing and authenticate as the target. The article’s lab configures a low-privileged user (igt_sanjeet) with an inline policy granting iam:UpdateLoginProfile scoped to a high-privileged user (igt_admin, holding AdministratorAccess). The escalation uses a single documented CLI call followed by an ordinary console login:

  • Reset the target’s password, e.g. aws iam update-login-profile --user-name <target-admin> --password '<new-password>' --no-password-reset-required (the no-reset flag prevents the target being prompted to change it at next login).
  • Sign in to the AWS Console at the account’s sign-in URL as the target user with the new password, obtaining that user’s (administrator) privileges.

No exploit or software vulnerability is involved — the abuse is a legitimate IAM API call permitted by an over-permissive policy. A practical caveat: resetting the password only yields access if the target console account is not additionally protected by MFA (and the attacker must know the account sign-in alias and target username, both readily discoverable); MFA on the target account blocks the console login.

Impact

Successful abuse gives the attacker interactive console access as the targeted user — in the lab, full AdministratorAccess and therefore complete account compromise (reading, modifying, deleting, or exfiltrating data across services such as S3). Overwriting an admin’s password is also disruptive and noticeable: it changes the legitimate user’s credential, which can lock them out and serves as an audit signal. This is one of a family of IAM permissions (with iam:CreateLoginProfile, iam:CreateAccessKey, iam:AssumeRole, and policy-attachment actions) that become escalation primitives when granted against other principals.

Mitigation

Because this is a configuration weakness, the defenses are policy hygiene and monitoring, several of which the article recommends:

  • Deny or tightly limit iam:UpdateLoginProfile and iam:CreateLoginProfile so only a small set of trusted admin/service principals can set other users’ passwords; never grant these against privileged users.
  • Enforce MFA on all privileged (and ideally all) accounts, so a password reset alone cannot yield console access.
  • Use IAM permission boundaries to cap what delegated principals can do, and apply least privilege throughout.
  • Prefer automated secret management and role-based, short-lived credentials over manual console-password resets.
  • Monitor AWS CloudTrail for UpdateLoginProfile/CreateLoginProfile events and alert on console logins that follow a password-reset, especially where the acting principal differs from the target user.

References

Leave a Comment