AWS root takeover: why resetting your IAM admins will not help

The AWS root user is the account’s ultimate authority, sitting above every IAM policy and service control policy. Its recovery depends on the registered email and phone, so an attacker who controls those can reset root and lock the real owner out.

How the attack works

The attacker triggers the root password-reset flow, which sends a reset to the registered email they control, and changes the root password. They then remove the existing root MFA device and register a new one, locking out the legitimate owner, and sign in as root from an unexpected location. With root, they create a new admin IAM user and access key and edit account-level settings to plant persistence that outlives any password fix. CloudTrail records the root password reset, the MFA device change, and the root ConsoleLogin. In ATT&CK terms this is T1098, Account Manipulation, with T1556, Modify Authentication Process.

Why it works

Root was recoverable through an email and phone the attacker could subvert, protected by re-rollable MFA. The recovery channel, not a long password, was the weak point.

How to fix it

Resetting IAM admins is useless, because root sits above IAM and can simply undo your changes, and a service control policy does not fully constrain the management-account root. You must regain root through AWS account recovery, re-establish a root MFA device you control, secure the registered email and phone that enabled the takeover, then enumerate and remove every IAM principal, key, policy, and account change the attacker planted. Afterward, harden root with phishing-resistant hardware MFA, monitor the recovery channels, eliminate routine root use, and alert on any root activity. Treat the entire account as compromised for the window.

Practice it

We built this as a GraphLattice Range scenario so responders regain root the right way and hunt the persistence a root takeover leaves behind.