AWS credential theft shows why standing privilege still fails

At a glance

What this is: This analysis of an AWS credential theft campaign shows how valid IAM access was used to create roles, launch mining workloads, and harden persistence inside customer environments.

Why it matters: It matters because IAM, PAM, and NHI teams need to treat standing privilege and role-creation rights as persistence enablers, not just access issues.

By the numbers:

• attackers used automation to deploy workloads within about 10 minutes of initial access

👉 Read Apono's analysis of the AWS credential theft and persistence campaign

Context

In cloud environments, identity is often the shortest path from compromise to control. When an attacker steals a valid IAM credential, the problem is no longer authentication alone. It becomes a question of what that identity can create, modify, and keep alive once it is inside the account.

This AWS campaign shows why non-human identity governance cannot stop at login or secret hygiene. Broad permissions, long-lived keys, and the ability to create roles or alter termination settings give attackers persistence even when they never exploit a software vulnerability.

Key questions

Q: What breaks when compromised IAM credentials still have standing privilege in AWS?

A: Standing privilege lets a stolen identity do more than authenticate. It can create roles, launch compute, and modify instance settings before defenders notice. In AWS, that turns a simple credential theft into persistence and monetisation. The control gap is not only authentication, but the amount of authority attached to the identity after login.

Q: Why do service accounts and IAM users with broad permissions increase persistence risk?

A: Broad permissions let attackers convert one credential into many actions, including role creation and infrastructure changes that outlast the original compromise. That is why non-human identity governance must focus on privilege scope, not just secret rotation. When a credential can mint new authority, the attack path becomes much harder to unwind.

Q: How do security teams know whether cloud identity controls are actually working?

A: Look for evidence that high-impact actions require fresh approval or ephemeral access, and that role-creation and termination-protection changes are visibly monitored. If a compromised credential can provision resources, alter protections, and remain active long enough to mine compute, the controls are not constraining attacker behaviour.

Q: Who is accountable when a stolen credential is used to deploy workloads in cloud environments?

A: Accountability sits with the identity governance model, the cloud platform owners, and the teams that granted the original permissions. The practical test is whether the programme limited what the compromised identity could do after authentication. If not, the incident is a governance failure as much as an attack.

Technical breakdown

Compromised IAM credentials become a trusted entry point

The first failure is not a breach of infrastructure. It is the use of valid credentials that already carry trust inside the AWS account. Once authenticated, the attacker inherits every action allowed by that identity, including API calls that look normal to cloud control planes. In this case, the compromise did not require exploiting EC2 or ECS. It required a credential with enough privilege to provision resources and alter account behaviour. That is why cloud identity must be treated as an attack surface, not just an administrative layer.

Practical implication: review which IAM identities can create roles, launch compute, or alter instance protection without additional checks.

Role creation turns access into persistence

The campaign used AWS permissions to create new IAM roles, including a service-linked role and a Lambda execution role. That matters because role creation is a control-plane privilege that can outlive the original compromise if it is not tightly governed. Attackers use it to blend into normal operations, expand their options, and avoid depending on the stolen credential alone. In practice, this is where standing privilege becomes persistence. If identities can mint new privileges on demand, defenders are already behind the attacker’s decision cycle.

Practical implication: constrain CreateRole and CreateServiceLinkedRole permissions to tightly governed paths with explicit approval and monitoring.

Termination protection and quota abuse delay containment

The attackers also modified instance attributes to set DisableApiTermination to true, which forces responders to reverse the setting before cleanup. Combined with aggressive EC2 and ECS provisioning up to account limits, this creates both persistence and operational noise. The goal is simple: make remediation slower than resource creation. In cloud environments, that means response controls must account for attacker-controlled infrastructure state, not just initial compromise. Otherwise, defenders spend time unwinding configuration changes while the mining workload keeps running.

Practical implication: monitor for termination-protection changes and instance-sprawl behaviour as indicators of active persistence.

Threat narrative

Attacker objective: The attackers wanted to monetise stolen cloud access by running cryptomining workloads while preserving control long enough to evade rapid remediation.

1. Entry began when attackers authenticated with compromised IAM credentials that were already trusted inside the AWS environment.
2. Escalation followed as the attackers used that access to create new roles, provision EC2 and ECS workloads, and modify instance attributes to resist cleanup.
3. Impact came from sustained cryptomining activity across victim environments, with compute resources pushed to quota limits to maximise illicit output.

Breaches seen in the wild

• 230M AWS environment compromise — 230M AWS environments compromised via exposed .env files with cloud credentials.
• Cisco Active Directory credentials breach — Kraken ransomware group leaked Cisco Active Directory credentials.

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 is now a persistence mechanism, not just an access model. This AWS campaign worked because the compromised identity already had enough privilege to create roles, deploy workloads, and alter termination settings. That is a governance failure, not a tooling failure. In OWASP-NHI terms, the issue is over-privilege combined with durable access paths that remain usable after compromise. Practitioners should treat persistent rights as the asset attackers exploit, not merely the permission model they inherit.

Zero Standing Privilege matters because it collapses the attacker’s time to act. The article shows how quickly automation can turn valid access into a mining operation. When no identity retains permanent high-impact permissions, attackers must keep re-authorising themselves or lose the path they are using. That changes the cost of persistence and reduces the room for quiet abuse. For cloud IAM programmes, ZT-NIST-207 and NIST-CSF both point to the same conclusion: standing access is the problem state.

Role creation is the overlooked control boundary in cloud identity governance. Many programmes review who can read data or start instances, but they underweight who can mint new authority inside the account. Once CreateRole or CreateServiceLinkedRole is broadly available, attackers can convert one set of credentials into a more durable operational foothold. The implication is clear: role-creation privilege deserves the same scrutiny as administrative login, because it becomes the attacker’s persistence layer.

Termination-protection abuse is a reminder that identity controls and response controls are linked. The campaign did not just consume compute, it made remediation harder by changing instance state. That means IAM, PAM, and cloud operations cannot be governed as separate silos. When a credential can change the shape of the incident as well as start it, lifecycle and containment controls must be designed together. Practitioners should align access governance with response playbooks, not assume they are independent.

Identity lifecycle failures in cloud are now measured in minutes, not review cycles. The campaign’s speed shows that access review cadences are too slow to catch a credential that can immediately provision and entrench itself. That does not mean access reviews are useless. It means they do not stop session-time abuse, which is where cloud persistence now lives. Teams should shift focus from periodic attestation alone to shorter-lived permissions, tighter role governance, and monitoring for privilege conversion events.

From our research:

• 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts, according to The 2024 Non-Human Identity Security Report.
• Only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities, according to The 2024 Non-Human Identity Security Report.
• For a broader view of why credentials and access scope keep driving compromise, see The 52 NHI breaches Report.

What this signals

Identity blast radius is the right lens for this kind of campaign. Once a stolen credential can create roles, alter termination settings, and launch compute at speed, the practical question is no longer whether the account was compromised. It is how much authority the identity could convert before containment caught up.

With 35.6% of organisations citing consistent access across hybrid and multi-cloud environments as their top NHI security challenge, the operational problem is not hypothetical. Cloud IAM teams should expect attackers to exploit exactly the seams where privilege, automation, and workload control overlap.

Practitioners should align cloud IAM, PAM, and incident response around the same event types. When a role-creation event or termination-protection change matters more than a login alert, the monitoring model has already shifted into attacker territory, and policy needs to follow.

For practitioners

• Restrict role-creation privileges to governed admin paths Audit every identity that can call CreateRole or CreateServiceLinkedRole and remove those rights from ordinary operator accounts. Require approval, logging, and alerting for any workflow that can mint new authority inside AWS.
• Replace standing cloud access with just-in-time permissions Use ephemeral access for high-impact AWS actions such as launching compute, modifying termination settings, or creating IAM roles. Keep the permission window short enough that a stolen credential cannot be reused as a durable foothold.
• Watch for termination-protection and quota-abuse signals Alert on DisableApiTermination changes, unusual instance naming patterns, repeated ECS task launches, and sudden attempts to exhaust compute quotas. These behaviours indicate an attacker trying to slow containment while increasing mining output.
• Map IAM blast radius by identity class Separate workload, operator, and automation credentials, then document which ones can deploy infrastructure, create roles, or modify resource state. Use that mapping to prioritise remediation for the identities that can convert one compromise into persistence.

Key takeaways

• This AWS campaign shows that valid credentials can be enough to create persistence when identity permissions are too broad.
• The evidence point is speed as much as access: attackers used automation to deploy workloads within about 10 minutes of initial access.
• Limiting role-creation rights, removing standing privilege, and monitoring termination-protection changes are the controls most likely to reduce impact.

Key terms

• Standing Privilege: Persistent access rights that remain attached to an identity until someone removes them. In cloud and NHI environments, standing privilege increases the value of stolen credentials because an attacker can immediately use the permissions without waiting for approval or just-in-time provisioning.
• Role Creation Privilege: The ability for an identity to create or attach new roles inside a cloud environment. This is a high-impact control point because it lets an attacker convert one compromised account into a more durable foothold with broader or cleaner-looking authority.
• 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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Apono covering an AWS credential theft campaign: How Attackers Maintained Persistence in AWS After Stealing Credentials. Read the original.