What happens when an attacker can move from an AWS IAM user to creating new users and admin access keys?

Once that happens, the attacker can establish a durable foothold that survives a single password reset or session revocation. New users, new long-term keys, and attached administrator policies allow continued access from multiple identities. In practice, this broadens the blast radius, complicates cleanup, and can support additional abuse such as quota increases or resource-intensive workloads.

How Privilege Escalation Becomes a Durable Foothold

The key shift is not just “more access”, it is control over the identity plane itself. Once an attacker can create users and mint new long-term access keys, they are no longer dependent on the original compromised IAM user. That means remediation has to account for newly created identities, attached policies, and hidden persistence paths, not only the first account that was abused.

In AWS, that pattern often turns a single compromise into an access graph problem. The attacker can distribute access across multiple identities, re-establish entry after a password reset, and keep an administrative path alive even if one session is revoked. That is why this kind of escalation usually changes both the cleanup effort and the expected blast radius.

When identity abuse reaches this stage, defenders should treat the environment as compromised until they can confirm there are no newly created principals, access keys, inline policies, or cross-account trust relationships left behind. NHIMG’s Ultimate Guide to NHIs is useful here because the persistence problem is the same class of issue seen when credentials outlive the control that originally created them.

Why the Blast Radius Expands So Quickly in AWS

New users and admin keys let an intruder separate initial access from ongoing access. That matters because revoking the original foothold does not necessarily remove the attacker’s alternate path. If the attacker can attach administrator-level permissions, they can often enumerate the account, create more credentials, increase quotas, deploy compute, access data, or modify logging and monitoring to make response harder.

The operational problem is compounded by speed. A malicious operator can chain identity creation, policy attachment, and key generation in minutes, then use those artefacts to create durable access that looks legitimate from the platform’s point of view. NHI Lifecycle Management Guide provides a strong lifecycle lens for understanding why revocation, rotation, and ownership are the controls that matter most after escalation.

That persistence is also why cleanup often takes longer than teams expect. You are not only hunting for the original compromise, you are tracing what the attacker was able to manufacture from it. In practice, the investigation has to include access keys, IAM policies, role assumptions, and any automation the attacker may have left behind. The 52 NHI Breaches Report is a useful reference point for the kinds of credential-abuse patterns that turn isolated access into sustained abuse.

Risk and Threat Considerations

This scenario is high risk because it creates persistence, privilege amplification, and delayed detection in one move. Even if the original user is disabled, the attacker may already have created fresh identities and long-term keys that outlast the first containment action. That can extend exposure to data theft, compute abuse, service disruption, and further privilege escalation.

Failure mechanism: The attacker uses an overprivileged IAM user to create replacement identities and access keys, then attaches broad policies or administrative permissions so access survives initial remediation. The compromise becomes harder to unwind because each new identity must be found and removed independently.

Impact: Teams can lose trust in the account boundary, spend far longer on containment, and face wider downstream abuse such as resource spawning, quota manipulation, or lateral movement into other cloud assets.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Non-Human Identity Top 10	NHI-01 — Secret and Credential Management	New IAM users and admin keys are the persistence mechanism in this compromise.
	NHI-02 — Identity Lifecycle and Offboarding	Attacker-created users must be discovered and offboarded as part of containment.
	NHI-03 — Least Privilege and Excessive Permissions	Administrator access keys expand blast radius and enable further abuse.
Recommendation — Rotate and revoke exposed access keys and remove any long-lived credentials created by the attacker. Inventory and deprovision every attacker-created principal before restoring trust in the account. Reduce privileges on cloud principals to prevent attacker-created identities from retaining admin reach.
CIS Controls v8	6.3 — Account Management	This is fundamentally an account-creation and privilege-abuse scenario.
	6.4 — Access Permission Management	Attached admin policies are the control failure that enables durable access.
	8.2 — Audit Log Management	Investigation depends on seeing when new users, keys, and policies were created.
Recommendation — Review and remove unauthorized accounts and keys as part of containment and recovery. Reassess permissions granted to each principal and remove any excessive access paths. Preserve and analyze audit logs to reconstruct attacker-created identity changes.
NIST CSF 2.0	PR.AA-01 — Identity Proofing, Authentication and Credential Management	Compromised credentials and newly minted keys are the core access mechanism here.
	PR.AA-04 — Access Permissions and Authorizations	The attacker escalates by gaining and extending authorization to admin-level actions.
	DE.CM-08 — Identity Management, Authentication and Access Monitoring	Detection hinges on spotting unauthorized user and key creation activity.
Recommendation — Strengthen credential and key governance so compromised access cannot be replaced silently. Restrict permissions so no single user can create durable administrative access paths. Monitor identity changes and alert on unexpected principal creation or policy attachment.
MITRE ATT&CK	T1098 — Account Manipulation	Creating users and modifying credentials are classic account-manipulation techniques.
Recommendation — Hunt for attacker-added accounts, keys, and permission changes as indicators of persistence.

Practitioner Guidance

What to verify: Confirm whether any newly created users, access keys, inline policies, or access grants appeared after the initial compromise time. If they did, treat every one of those artefacts as attacker-owned until proven otherwise, even if they appear inactive.

Decision rule: If the attacker could create or modify IAM principals, prioritise full identity inventory and key revocation before assuming password reset or session revocation is sufficient. That is the point where containment becomes a privilege review, not just an account reset.

What good looks like: You can demonstrate that every newly created principal has been removed or fully reassigned, every long-term key has been rotated, and every attached policy and trust path has been reviewed for unexpected privilege.

Practitioner takeaway: Once an attacker can manufacture new AWS identities, the event is no longer a single-user compromise, it is a persistence and governance failure that requires identity eradication, not just access shutdown.