How attackers maintained persistence in AWS after stealing credentials

In the cloud, attackers don’t need to break in. They just need a working set of keys. 

Several AWS customers learned this the hard way when threat actors used compromised IAM credentials to deploy a rapid cryptomining campaign across EC2 and ECS environments. The incident didn’t rely on vulnerabilities or sophisticated exploitation; it simply relied on valid credentials and overly permissive access.

Below is a clear breakdown of what happened, what matters, and how organizations can strengthen their defenses using a Zero Standing Privilege (ZSP) approach.

What happened during the AWS cyberattack

When an attack of this scale occurs, it’s important to understand how attackers gained access and what they did with it. 

How the attackers gained initial access

According to reporting from Dark Reading, as well as AWS’s own analysis, attackers used stolen IAM credentials to authenticate into customer environments and immediately begin provisioning cryptomining workloads. The campaign was active across multiple AWS customers, who were directly notified.

AWS also confirmed this was not the result of a flaw in its infrastructure. The privileges attached to the compromised identity permitted every action the attackers took.

Once inside, the attackers:

• Targeted EC2 and ECS resources to spin up mining infrastructure

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

• Leveraged AWS APIs to create new roles, extending their control

• Enabled persistence by modifying instance attributes to make resources harder to terminate

This combination of legitimate access and rapid provisioning made the campaign highly effective and very difficult to stop in its early stages.

How the attackers stayed in control

After gaining access, the attackers created two new IAM roles using the victim’s own permissions to achieve their goals and persistence:

1. A service-linked role for Auto Scaling groups

2. A Lambda execution role, with AWSLambdaBasicExecutionRole attached

These roles gave them flexibility to deploy and manage resources in ways that blended into normal cloud operations.

They also set DisableApiTermination=true on EC2 instances, which forces defenders to manually re-enable termination before cleanup. This slows incident responders and disrupts automated remediation workflows.

On top of that, the attackers attempted to launch as many EC2 instances and ECS tasks as each victim’s quota allowed. It’s a simple technique: push the environment to its compute limits, maximize mining output, and generate profit before alarms start ringing.

Compromised credentials are still the easiest way in

This attack chain is not surprising to anyone working in cloud security. In many environments:

• IAM permissions are broad

• Long-lived access keys still exist

• Role creation is not guarded

• AI agents and NHIs inherit long-standing privileged credentials

• There is little friction between authentication and high-impact actions

When a compromised identity can create new roles, deploy compute resources, and modify protection settings without additional checks, attackers don’t need zero-days. They just need opportunity.

This is exactly the kind of scenario where a Zero Standing Privileges strategy provides real value.

Why Zero Standing Privileges are the key to preventing credential attack

Zero Standing Privileges (ZSP) reduces the risk of credential misuse by ensuring that no human or non-human identity keeps permanent access to sensitive or high-impact permissions. 

How ZSP removes the risk of long-lived access

If the credentials in the AWS incident had been tied to temporary, tightly scoped permissions instead of broad, standing access to create roles and launch resources, the attackers’ options would have been dramatically limited.

Since the AWS attack, however, the risks of standing access have only increased as AI agents become more common. 

Agents, and the non-human identities (NHIs) they use to interface with systems, are often provisioned with broad, long-lived access to enable them to perform tasks across various systems. All of this creates more unmanaged risk from standing access. In fact, 1Password research found that 73% of technical workers report visibility gaps in which AI agents use credentials at their company, and 86% of respondents reported credential-related issues with NHIs. To manage the risks that led to the AWS breach, teams need to implement ZSP with agentic and NHI access risks in mind.

ZSP manages the risk of standing access by ensuring that:

• Access is Just-in-Time

• Privileges are scoped to the exact task

• Access expires automatically

• Sensitive roles require additional validation or approval

How 1Password Privileged Access helps implement ZSP in AWS

ZSP is a powerful strategy, but difficult to enforce manually. 1Password Privileged Access automates the operational layer, making least privilege practical for real engineering teams.

Just-in-time access flows

1Password Privileged Access ensures that scoped access to cloud environments, K8s, databases, or SaaS platforms is provisioned on request and removed when the session ends.

This means a compromised identity cannot silently elevate itself, create roles, or deploy infrastructure without triggering controls.

Dynamic Guardrails

Instead of relying on static IAM roles, which age poorly and are always available for abuse, 1Password Privileged Access creates Dynamic Guardrails that factor in who's requesting access, what they need, and the risk of that action. Policies adapt as your environment scales.

This accomplishes two important outcomes:

• Attackers cannot rely on pre-existing roles to escalate

• Admin teams no longer need to pre-build and maintain dozens of role variations

Continuous monitoring and anomaly detection

Within 1Password Privileged Access, every request, approval, and access event gets logged automatically. AI-generated session summaries give auditors and compliance teams instant answers. 

Moreover, Autonomous Anomaly Detection would have flagged activity such as:

• High-risk access requests, approvals of previously rejected requests, and sudden requests from inactive users

• Repetitive or suspicious automated actions, to ensure that automation doesn’t become a security vulnerability

AI agent controls

When agents require access to perform a task, 1Password Privileged Access gives each agent a distinct identity and a role scoped for its specific task. It also validates declared intent against actual actions in real time so that if an agent deviates from its stated purpose, access is restricted or revoked before the action executes. 

Regardless, access is deprovisioned when the task is complete, meaning agents can take on work without the access surface expanding alongside them. 

All of this reduces the blast radius of compromised credentials and limits how much damage attackers can do before they’re stopped.

Taking the next step toward smarter access controls

The AWS incident is a reminder of a simple truth: identity is the primary attack surface in cloud environments. Compromised credentials, combined with broad standing privileges, give attackers everything they need to operate inside your infrastructure.

A Zero Standing Privilege approach minimizes this risk by ensuring access is temporary, scoped, and closely governed. 1Password Privileged Access provides the automation needed to make that practical in real-world environments.