AWS credential theft shows why standing privilege still fails

At a glance

What this is: This is an analysis of an AWS credential-theft campaign in which stolen IAM access was used to provision cryptomining workloads, create roles, and harden persistence.

Why it matters: It matters because cloud IAM rights are often broad enough that one compromised identity can become both the entry point and the control plane for attacker persistence.

Context

AWS credential theft remains dangerous because the attacker does not need to defeat the platform if the stolen identity already carries permission to create roles, launch compute, and modify instance protection. In cloud environments, the boundary between authentication and high-impact action is often thinner than teams assume.

This article focuses on the governance gap created by standing privilege in AWS. The issue is not infrastructure failure; it is that valid credentials can be converted into persistence when identity permissions are broader than the task at hand.

For IAM and cloud security teams, the practical question is how quickly a compromised identity can move from login to workload creation, role creation, and termination resistance. In this incident, that sequence happened fast enough to expose how much damage permissive access can absorb before detection.

Key questions

Q: What breaks when a stolen AWS identity already has role-creation rights?

A: The breach boundary breaks because the attacker no longer needs to escalate outside the account. With role creation, instance modification, and workload launch permissions already present, the compromised identity can manufacture a persistent foothold and keep operating through normal cloud APIs. That is why broad IAM rights are a governance problem, not just a misuse problem.

Q: Why do standing AWS permissions increase the impact of stolen credentials?

A: Standing permissions let an attacker do useful work as soon as credentials are accepted. That can include validating the identity, querying service limits, sending mail, or exploring the environment without needing to escalate first. The more durable the privilege, the more likely the attacker can turn one stolen secret into several stages of abuse.

Q: What are the signs that AWS Systems Manager is being misused for persistence or credential theft?

A: Common warning signs include unusual SSM sessions, unexpected access to hosts that should not be managed, new or altered SSM user accounts, commands that enumerate managed devices, and access patterns that lead to credential harvesting or SSH key extraction. A sudden rise in remote administration activity from accounts that rarely use SSM is also a strong indicator.

Q: Should teams compare Zero Standing Privilege and traditional IAM admin access?

A: Yes, because the difference is whether elevated permissions are always available or only issued for a specific task. In incidents like this, permanent access gives a stolen identity enough time and authority to create roles, launch resources, and harden persistence. JIT issuance reduces that window and makes abuse harder to repeat.

Technical breakdown

How compromised IAM credentials became execution rights

The campaign began with stolen IAM credentials that authenticated successfully into customer environments. Once authenticated, the attacker did not need to exploit a software flaw because the attached permissions already allowed high-impact AWS actions. That is the key cloud identity distinction: authentication proves the actor can enter, but authorization determines whether the actor can provision resources, create roles, or alter instance settings. In this case, the compromised identity effectively functioned as an operational control plane, giving the attacker direct access to EC2, ECS, and IAM workflows through normal APIs.

Practical implication: review which IAM principals can move from login to resource creation without an additional access gate.

Why role creation and termination protection extend attacker control

After initial access, the attackers created new IAM roles and enabled DisableApiTermination on EC2 instances. Role creation matters because it lets an intruder establish a more durable identity foothold inside the account, while termination protection slows cleanup and frustrates automated response. These are not exotic techniques; they are native cloud functions used in a malicious sequence. The security failure is that ordinary administrative capabilities were available to a compromised identity that should not have been able to reshape its own operating context so easily.

Practical implication: separate day-to-day operator access from any ability to create roles or harden instances.

Why rapid provisioning makes cloud persistence hard to catch

The attacker used automation to spin up mining workloads within about 10 minutes of access and attempted to consume as much compute quota as possible. In cloud incidents, speed is itself a control bypass because defenders often rely on review cycles, alert triage, or manual approval to interrupt misuse. If a privileged identity can provision resources faster than the organisation can investigate, the environment becomes a short-duration profit engine. That is why cloud persistence should be analysed as an access governance problem, not only as a detection problem.

Practical implication: align monitoring and approval controls to the speed of automated cloud provisioning, not to human response times.

Threat narrative

Attacker objective: The attacker objective was to monetise stolen cloud access by running unauthorized cryptomining workloads while preserving control long enough to maximize compute use.

1. Entry occurred when attackers authenticated with stolen IAM credentials into AWS customer environments and immediately began using the privileges attached to those identities.
2. Escalation happened when they created new IAM roles and used AWS APIs to provision EC2 and ECS resources for cryptomining.
3. Persistence increased when they set DisableApiTermination=true on EC2 instances, making cleanup harder and slowing defensive removal.
4. Impact was the deployment of cryptomining infrastructure across customer environments with resource exhaustion and operational disruption.

Breaches seen in the wild

• Amazon AWS Hacked Accounts Crypto-Mining: Compromised IAM credentials across multiple AWS accounts fuel large-scale crypto-mining campaign.
• Codefinger S3 ransomware 2025: Codefinger used victims' compromised AWS keys to re-encrypt S3 buckets with SSE-C, set 7-day deletion and demanded ransom for the key.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Standing privilege turns AWS credential theft into persistence, not just access. The critical failure is not that credentials were stolen, but that the compromised identity already carried enough authority to create roles, launch compute, and harden instances. In cloud IAM, the attacker often inherits the operational ceiling of the victim account, so privilege scope determines whether a compromise becomes transient or durable. Practitioners should treat every broad IAM grant as a potential persistence pathway, not simply a usability convenience.

Role creation is the point where cloud misuse becomes governance failure. Once an attacker can mint new roles or service-linked roles from a compromised identity, the environment starts producing attacker-owned trust relationships from its own control plane. That is why overpermissive IAM design matters more than isolated detection events. The implication is that account-level policy should limit which identities can create or alter roles at all, because role creation changes who can act, not just what can be done.

Zero Standing Privilege is an access model, but this incident shows the broken premise underneath it. The assumption that access can be reviewed after it is granted was designed for identities whose privileges persist long enough to be audited. That assumption fails when a stolen AWS identity can use broad permissions to create, reshape, and entrench itself within minutes. The implication is that governance must shift from reviewing standing rights to constraining what a compromised identity can do at first use.

Ephemeral access windows: The article surfaces a narrower control concept that matters here: access should exist only for the exact task and should expire before it can be reused for persistence. Standing permissions across EC2, ECS, and IAM allow attackers to convert one compromise into repeated resource creation. For practitioners, the issue is not merely stronger approval, but eliminating the permanent authority that makes cloud abuse operationally trivial.

Cloud persistence should be measured by how much identity power survives compromise. If a stolen principal can create roles, modify termination behaviour, and launch workloads before a human intervenes, the account has already ceded too much governing authority to the identity layer. This is why cloud security posture cannot be judged only by perimeter or workload telemetry. The real test is how much attacker action the identity model permits before containment begins.

What this signals

Ephemeral access windows: AWS identity governance has to move from reviewing who can do what in the abstract to constraining what a compromised identity can do in the first minute after theft. When credentials already carry role creation and compute launch rights, the compromise is no longer just an entry event, it is an operational foothold.

Cloud teams should treat instance termination controls, role creation, and workload provisioning as part of the identity problem, not separate administration tasks. That is the practical lesson for IAM, PAM, and cloud security programmes: standing privilege creates persistence potential even when the attacker never leaves native AWS workflows.

For practitioners

• Audit role-creation rights Identify every IAM principal that can create roles, service-linked roles, or role attachments, then remove those rights from identities that do not need to shape trust relationships.
• Replace standing cloud access with JIT controls Move high-impact permissions such as infrastructure changes and IAM administration behind just-in-time access so a compromised identity cannot reuse them continuously.
• Block termination-protection abuse Alert on ModifyInstanceAttribute calls that set DisableApiTermination and require separate approval for any identity that can change instance removal behaviour.
• Review EC2 and ECS provisioning boundaries Constrain which identities can launch compute, attach execution roles, and consume quota so a stolen account cannot rapidly translate access into mining capacity.
• Investigate CloudTrail for role-creation spikes Search for unusual CreateRole, CreateServiceLinkedRole, and rapid sequence activity that shows an identity turning a compromise into persistence.

Key takeaways

• The core risk is not exotic exploitation but the abuse of valid AWS identity permissions to create persistence and generate compute spend.
• The campaign shows how quickly a compromised account can move from authentication to workload creation, role creation, and termination resistance.
• Removing standing access to role creation and high-impact compute actions is the control that most directly limits the blast radius of this pattern.

Key terms

• Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
• Zero Standing Privilege: A control model in which an identity does not keep persistent access unless it is actively needed. For NHIs, this means credentials and permissions are issued for a narrow task and then removed. It reduces the time window and reuse value of stolen access.
• IAM Role Assumption: IAM role assumption is the act of temporarily taking on a defined set of permissions to perform a task. In practice, a user, service, or workload authenticates and then receives short-lived credentials tied to a role, so access is governed by policy rather than by permanent identity entitlements.
• Termination Protection: A cloud setting that prevents resources from being deleted until the protection is removed. Attackers abuse it to slow containment and force defenders to make extra changes before cleanup, which buys time for malicious workloads to keep running.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.