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. For full details, you can read the AWS security blog here. 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: A service-linked role for Auto Scaling groups 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-

Excerpt shown under the publisher's RSS terms · 81 words · full text and figures are on the publisher's site