AWS Root Account Compromise Playbook: Regain Control of a Hijacked AWS Account

When an attacker holds the root user of an AWS account, they can change the account email, password and MFA, close the account, and run up charges that no IAM policy in that account can block. Root compromise is different from an ordinary access key leak: the identity you would use to fix things may be the one you have lost, and recovery can depend on AWS Support verifying that you own the account. This playbook covers how a root compromise shows up, the triage questions to answer in the first hour, containment in priority order, account recovery through AWS Support, eradication across every Region, evidence to preserve and when notification rules apply. It is written for cloud security teams, incident responders and the owners of standalone AWS accounts and AWS Organizations. Access key leaks in general are covered in the Cloud Credential Compromise Playbook; this page stays on what is specific to the root user.

Key takeaways

• Recover the root identity first. If you still control root, change its password, reset its MFA and check the account email before anything else; if you do not, go straight to AWS Support.
• The email and phone are the real keys. AWS root MFA recovery uses the account email and the primary contact phone number, so an attacker who changed either has moved the recovery path with them.
• Sweep every Region, not just the ones you use. AWS's own compromise guidance says to delete unrecognised resources in all Regions and compare usage with the previous month.
• In an organisation, root is not equal everywhere. Service control policies restrict member account root users but never the management account, which makes management account root the highest-impact identity you own.
• Remove what cannot be stolen again. Centralised root access in AWS Organizations can delete member account root passwords, access keys and MFA, leaving no root credential to compromise.

How the incident shows up

Root compromise is usually noticed through money, lockout or an AWS notification rather than through a detection rule. Know which signals point at root rather than at an IAM principal.

Relevant ATT&CK techniques are T1078.004 Cloud Accounts for the initial use of root, T1098.001 Additional Cloud Credentials and T1098.003 Additional Cloud Roles for persistence, T1531 Account Access Removal when the attacker locks you out, and T1496 Resource Hijacking for the bill.

Triage questions

Answer these in the first hour. They decide which containment branch you take and who must be told.

1. Do we still control the root user? Can someone sign in with the current password and MFA? If not, which factor failed: password, MFA or the email itself?
2. Do we still control the account email inbox and the primary contact phone? These are the factors AWS uses for password reset and MFA recovery.
3. Is this a standalone account, a member account or the management account? A management account root compromise puts every member account in scope.
4. Do we still have a working administrative IAM or IAM Identity Center principal? That principal can contain a lot even when root is lost, and AWS says the primary contact phone should be updated by an IAM administrator rather than root.
5. What did the attacker change? Check CloudTrail for root access key creation, new IAM users, roles and policies, contact detail changes, Region opt-ins, and Organizations calls.
6. What data or workloads could they reach? Root can read every bucket and database in the account unless a resource policy or SCP says otherwise.
7. Is billing still under our control? Payment methods and billing settings include root-only tasks.

Containment priorities

Work top down. Each step closes a path the next would otherwise reopen.

1. Branch A, root still accessible: sign in, change the root password, remove any MFA device you do not recognise and register new ones (AWS allows up to eight MFA devices per root user). Confirm the account email, primary contact and alternate contacts are yours, as AWS's compromise checklist directs. Delete any root access keys; AWS's guidance is to delete root keys you did not create or no longer need.
2. Branch B, password lost but email held: use root password recovery from the sign-in page, then do Branch A.
3. Branch C, MFA lost: on the sign-in page choose Troubleshoot MFA, then Sign in using alternative factors. AWS sends a verification email from [email protected] and then calls the primary contact phone number. After regaining access, change the root password, because AWS notes an attacker may also hold it.
4. Branch D, email or phone lost: contact AWS Support through its account and MFA support form. AWS says you must contact Support if you cannot verify the account email and primary contact phone. Open the case from a separate, known-good AWS account or the support form, record the case number and keep evidence of ownership ready (invoices, payment method details, account ID).
5. Member accounts in an organisation: from the management account or a delegated IAM administrator, use centralised root access. A principal with sts:AssumeRoot can run the IAMAuditRootUserCredentials task to see the member root's password, keys, certificates and MFA status, then IAMDeleteRootUserCredentials to remove them. This does not require signing in as the member root.
6. Cut off IAM persistence: using a trusted admin principal, deactivate IAM users you did not create, deactivate unrecognised access keys (deactivate first, delete after evidence is captured), and revoke active role sessions. Details are in the Cloud Credential Compromise Playbook.
7. Stop the spend: stop or scale to zero unknown compute in every Region, including auto scaling groups and container services that will relaunch tasks. Snapshot volumes you need as evidence before termination. See the Cryptojacking Incident Response Playbook.
8. Protect the organisation: if the compromised account is a member, apply a quarantine SCP to it; SCPs restrict the member root user. If the management account itself is compromised, SCPs cannot help, so recovery of that root is the critical path and every member account must be checked.

Eradication

• CloudTrail review: list every event with a root identity and every IAM write call (CreateUser, CreateAccessKey, CreateLoginProfile, AttachUserPolicy, CreateRole, UpdateAssumeRolePolicy) since the earliest suspicious time. AWS's checklist says to compare event times with the irregular activity and delete what is unsanctioned.
• All Regions: enumerate resources in every enabled Region, including ones you never use, and compare usage with the previous month as AWS recommends. Pay attention to compute, Lambda functions with public function URLs, new key pairs, and email sending services.
• Persistence that resists deletion: termination protection on instances, auto scaling groups that recreate capacity, and scheduled tasks. The Amazon AWS Crypto-Mining Campaign used termination protection and a new IAM user with console access to survive clean-up.
• Trust and sharing: role trust policies naming unknown external accounts, resource policies granting cross-account access, and shared snapshots or AMIs (ATT&CK T1537 Transfer Data to Cloud Account).
• Logging and detection: re-enable any trail, GuardDuty detector or Config recorder the attacker disabled, and confirm logs flow to a separate log archive account.
• Quarantine policy: AWS's checklist asks you to confirm whether AWSCompromisedKeyQuarantineV2 is attached to affected IAM users; leave it until keys are rotated, then review.

Recovery

1. Restore data from backups taken before the earliest malicious event, ideally from a backup vault in a separate account.
2. Rebuild admin access through IAM Identity Center or federated roles, not root. AWS's root user guidance is to use root only for tasks that require it.
3. Reduce root to nothing in member accounts. Enable centralised root access so new member accounts are created without root credentials, and delete existing member root credentials. When a root-only task is unavoidable, use the scoped task policies or the Allow password recovery task, then delete the credentials again as AWS recommends.
4. Harden what must remain: for the management account and standalone accounts, register at least two phishing-resistant MFA devices, use a group mailbox for the root email on a domain you control, and keep the primary contact phone current.
5. Close the AWS case: reply to the AWS notification in Support Center confirming the actions taken, as AWS's guidance requests, and ask about billing adjustments for fraudulent usage.
6. Watch closely for 30 days: alert on any root sign-in and on Policy:IAMUser/RootCredentialUsage, and track spend daily.

Evidence to preserve

Notification triggers

• Personal data: if root access exposed personal data, GDPR Article 33 requires notifying the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware, unless the breach is unlikely to result in a risk to individuals. A processor must tell the controller without undue delay. See the Breach Notification Laws by Country Guide.
• US listed companies: a material cybersecurity incident triggers a Form 8-K Item 1.05 filing, generally due four business days after the company determines the incident is material.
• Customers and contracts: if the account hosts a service for others, check contractual notice periods in customer agreements.
• AWS: AWS asks you to respond to its notification in Support Center; that is not a regulatory notice.

Lessons from incidents

• Attackers automate spend fast. In the Amazon AWS Crypto-Mining Campaign, miners were running within 10 minutes using stolen IAM keys with admin-like rights. Root grants more than that, so budget alerts and GuardDuty must page someone, not just email a shared inbox.
• Storage can be held to ransom with native features. The Codefinger S3 Ransomware case used SSE-C and lifecycle rules to make data unrecoverable without the attacker's key. Check lifecycle rules and encryption settings on critical buckets during eradication.
• The recovery path is part of the attack surface. A root email on a personal mailbox or a phone number held by a former employee turns a recoverable incident into a long Support case.

Practitioner checklist

• Record who controls each account's root email inbox and primary contact phone, and test recovery once a year.
• Enable centralised root access and delete root credentials from every member account.
• Register at least two MFA devices on every remaining root user.
• Alert on Policy:IAMUser/RootCredentialUsage and on any CloudTrail event with a root identity.
• Keep CloudTrail in a separate log archive account with object lock.
• Set budgets and Cost Anomaly Detection on every account, including Regions you do not use.
• Restrict unused Regions with an SCP in member accounts.
• Pre-write the AWS Support case text and ownership evidence pack so it is ready during lockout.
• Rehearse this playbook against the management account scenario, where SCPs do not apply.

Standards and references

• AWS re:Post Knowledge Center: What do I do if I notice unauthorised activity in my AWS account?
• AWS IAM User Guide: Recover an MFA protected identity
• AWS IAM User Guide: AWS account root user
• AWS IAM User Guide: Perform a privileged task on an AWS Organizations member account
• AWS Organizations User Guide: Service control policies
• Amazon GuardDuty User Guide: IAM finding types
• NIST: SP 800-61 Rev. 3 Incident Response Recommendations and Considerations
• GDPR: Article 33 Notification of a personal data breach to the supervisory authority

Related NHI Mgmt Group resources: Cloud Credential Compromise Playbook · AWS Organizations and SCPs Guide · AWS CloudTrail Guide · Cryptojacking Incident Response Playbook · AWS Security Guide