How Attackers Maintained Persistence in AWS After Stealing Credentials

What the recent AWS campaign reveals about credential misuse, persistence techniques, and the need for Zero Standing Privilege

Last week’s disclosure from AWS is another reminder that 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 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

According to reporting from Dark Reading and 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.

Importantly, AWS confirmed this was not the result of a flaw in AWS infrastructure. Every action the attackers took was permitted by the privileges attached to the compromised identity.

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 both effective and difficult to stop in its early stages.

For full details, you can read the AWS security blog here: https://aws.amazon.com/blogs/security/cryptomining-campaign-targeting-amazon-ec2-and-amazon-ecs/ 

A Closer Look at How They 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.

What Security Teams Should Check Right Now

AWS published several indicators of compromise tied to this campaign. Teams should search across logs, CloudTrail, GuardDuty findings, and container registries for the following:

Suspicious container image

• yenik65958/secret (now removed, but variants may exist)
  

Mining pool domains

• asia.rplant.xyz
  
• eu.rplant.xyz
  
• na.rplant.xyz
  

Unusual instance naming patterns

• SPOT-us-east-1-G*-*
  
• OD-us-east-1-G*-*
  

IAM activity

• Unexpected CreateRole or CreateServiceLinkedRole events
  
• ModifyInstanceAttribute calls setting DisableApiTermination to true
  

If any of these appear in your logs, treat it as a high-priority investigation.

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
  
• There is no 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 Matter

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

• Access is Just-in-Time
  
• Privileges are scoped to the exact task
  
• Access expires automatically
  
• Sensitive roles require additional validation or approval
  

If the credentials in this 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.

How Apono Helps Implement ZSP in AWS

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

Here’s how Apono would have helped in a situation like this:

Risk-tiered Access Flows

Apono allows organizations to define access policies that match the sensitivity of each system:

• Low-risk resources — Baseline access or long-term auto-approved JIT access for authenticated users
  
• Medium-risk resources — Short-term JIT access with clear time limits and MFA
  
• High-risk environments (production, regulated data, IAM changes) — Require manager or admin approval before ephemeral, time-bound access is granted
  

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

Breakglass with Context

For urgent incidents, engineers can request temporary elevation tied to an IRM like PagerDuty, Splunk OnCall, Opsgenie, Grafana IRM, or other service incident ticket, ensuring access is fast but still governed and auditable.

Dynamic, Ephemeral Role Creation

Instead of relying on static IAM roles, which age poorly and are always available for abuse. Apono creates scoped roles on the fly when access is approved.

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

Apono 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, ensuring that automation doesn’t become a security vulnerability

And before the attack even happened, Apono’s privilege discovery and remediation would have identified:

• Overprivileged IAM accounts
  
• Role-creation permissions assigned to users who shouldn’t have them or don’t need them based on business logic context
  

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. Apono provides the automation needed to make that practical in real-world environments.

Get the Checklist

you want to quickly assess where standing privileges may already exist in your environment, start with our Zero Standing Privilege Checklist — a simple way to benchmark your current exposure. 

And when you’re ready to compare Cloud PAM approaches that operationalize ZSP, our Privileged Access Buyer Guide + RFP Checklist breaks down the capabilities that matter most and the questions that separate cloud-native solutions from legacy ones.