Amazon AWS Crypto-Mining Campaign 2025: How Compromised IAM Credentials Had Miners Running in 10 Minutes

From 2 November 2025, attackers used compromised AWS Identity and Access Management (IAM) credentials to run cryptocurrency miners inside AWS customer accounts. Amazon GuardDuty and AWS's own monitoring spotted the same techniques across multiple customer accounts, and AWS described the campaign on its Security Blog on 16 December 2025. AWS itself was not breached: the company says the actions "don't take advantage of a vulnerability within an AWS service" but rely on valid credentials used by an unauthorised party. With admin-like access keys, the attackers checked their permissions, created roles, launched dozens of Amazon ECS clusters and EC2 auto scaling groups sized up to 999 instances, and had miners running within 10 minutes. They then made instances harder to terminate and left behind a public Lambda endpoint and a new IAM user with full Amazon SES access. The campaign is a clear example of what a single over-privileged, long-lived cloud credential can cost.

At a glance

What happened

In its post of 16 December 2025, AWS says that "Amazon GuardDuty and our automated security monitoring systems identified an ongoing cryptocurrency (crypto) mining campaign beginning on November 2, 2025." It explains that the campaign "was originally identified when GuardDuty security engineers discovered similar attack techniques being used across multiple AWS customer accounts." AWS did not name the affected customers or say how many there were.

The common starting point was a set of compromised IAM credentials with admin-like privileges. GuardDuty's anomaly detection flagged the credentials being used from an unusual network and location. BleepingComputer reported Amazon's position that "the attacker did not leverage a vulnerability but used valid credentials in customer accounts", and neither AWS nor the press coverage explains how the keys were originally stolen.

The attacker started carefully. According to AWS, they called GetServiceQuota to see how many instances they could launch, then called RunInstances several times with the DryRun flag. AWS says this let them "validate their IAM permissions without actually launching instances, avoiding costs and reducing their detection footprint." Next they created a service-linked role for auto scaling and a role for AWS Lambda, attaching the AWSLambdaBasicExecutionRole policy.

The mining itself ran on two fronts. On Amazon ECS, the attacker created dozens of clusters, "sometimes exceeding 50 ECS clusters in a single attack", registered a task definition that requested 16,384 CPU units and 32,768 MB of memory, and started Fargate services with a desired count of 10 tasks. The task pulled the Docker Hub image yenik65958/secret, which AWS says was created on 29 October 2025, had more than 100,000 pulls and contained the SBRMiner-MULTI binary. A script in the image mined using all processor cores against pools at rplant[.]xyz.

On Amazon EC2, the attacker created two launch templates and 14 auto scaling groups, each set to scale from 20 to 999 instances. Spot groups targeted GPU and machine learning families (g4dn, g5, p3, p4d, inf1), while on-demand groups used compute, memory and general-purpose families (c5, c6i, r5, r5n, m5a, m5, m5n). Once auto scaling quotas were used up, they launched further instances directly with RunInstances. AWS reports that "Within 10 minutes of the threat actor gaining initial access, crypto miners were operational."

The attacker then worked on staying in. AWS describes "the use of ModifyInstanceAttribute with disable API termination set to true, forcing victims to re-enable API termination before deleting the impacted resources." They also created a Lambda function, generate-service-a1b2c3d4, exposed it through a function URL with authType set to NONE and granted invoke permission to any principal. Finally, they created an IAM user named user-x1x2x3x4, attached AmazonSESFullAccess, and generated both an access key and a console login profile. AWS reads this as preparation for phishing through Amazon SES.

AWS says the image has since been taken down from Docker Hub, "but threat actors might deploy similar images under different names." The Hacker News noted that the termination protection trick had been described by researcher Harsha Koushik in April 2024.

Timeline

How it happened: the identity attack path

1. A powerful key in the wrong hands. The attacker held IAM credentials with admin-like privileges. AWS's advice to prefer temporary credentials over long-term access keys points to static keys as the weak spot, although the original theft route was not disclosed.
2. Quiet permission testing. GetServiceQuota and RunInstances with DryRun told the attacker what the key could do without creating resources or incurring cost.
3. Creating new machine identities. The stolen key was used to create IAM roles for auto scaling and Lambda, extending the attacker's reach through identities the victim had never approved.
4. Industrial-scale compute. More than 50 ECS clusters in some attacks, 14 auto scaling groups sized up to 999 instances and direct instance launches turned a single credential into a large mining fleet in minutes.
5. Slowing the responders. Termination protection on every instance meant defenders and automated remediation had to reverse the setting before they could delete anything.
6. Backup access paths. A Lambda function URL with no authentication and a new IAM user with an access key and console password gave the attacker ways back in if the original key was revoked.

Impact

• Compute abuse: ECS Fargate tasks and EC2 fleets, including GPU and machine learning instances, ran miners for the attacker. AWS did not publish cost figures or a count of affected accounts.
• Persistence: termination-protected instances, a public Lambda endpoint and a rogue IAM user had to be found and removed in each account.
• Onward risk: the IAM user with full SES access could have been used to send phishing email from the victim's account, according to AWS's reading of the attacker's intent.
• Supply of tooling: the mining image had more than 100,000 pulls on Docker Hub before it was removed, according to AWS.

What this means for NHI governance

This campaign contains no exploit. Every step used a documented AWS API, called with a valid credential. That is the essence of a non-human identity breach: the cloud platform did exactly what an authorised principal asked it to do. AWS makes the same point, noting that the activity sits "in the customer domain of the shared responsibility model."

The credential's privilege determined the damage. A key limited to the tasks its workload actually needs could not have created IAM roles, IAM users, Lambda function URLs, ECS clusters and auto scaling groups. Admin-like access keys are common because they are convenient, and they often outlive the project or person that created them. Once stolen, they let an attacker not only use the account but mint new identities inside it, so revoking the original key is no longer enough.

The persistence choices are also identity choices. A new IAM user with its own access key and console password is a fresh non-human identity that nobody owns. A Lambda function URL with no authentication is an anonymous entry point. Responders who rotate only the leaked key and stop the miners can easily miss both. The same pattern of stolen AWS keys turned into compute or email abuse appears in TruffleNet and in LLMjacking, where the resource being stolen is model access rather than CPU.

Recommendations

• Retire long-term access keys. AWS recommends temporary credentials instead of long-term access keys. Move workloads to roles and federation, and find and remove old user keys. The Cloud Workload Identity Guide covers the options.
• Cut privilege to what each identity needs. No workload key should be able to create IAM users, roles and access keys. Use least privilege and review effective permissions with cloud entitlement tooling, as described in the Cloud PAM and CIEM Guide.
• Block risky actions with guardrails. AWS suggests service control policies that deny Lambda function URLs with authType set to NONE. Consider similar guardrails for IAM user creation in accounts that should never need it.
• Enforce MFA for all users, as AWS recommends, so that any console login profile created or reused by an attacker is harder to exploit.
• Detect the pattern early. Enable GuardDuty with Runtime Monitoring and Extended Threat Detection, watch CloudTrail for DryRun calls, unusual CPU requests in ECS task definitions and sudden auto scaling groups, and scan container images.
• Prepare the clean-up. Write runbooks that handle instances with API termination disabled, and after any key compromise hunt for new IAM users, roles, access keys and Lambda URLs before closing the incident. Challenges of Rotating NHIs explains why rotation alone is rarely enough.

Frequently asked questions

Was AWS hacked in the 2025 crypto-mining campaign?

No. AWS says the attacker did not exploit any vulnerability in an AWS service. The attacker used valid, compromised IAM credentials to create resources inside customer accounts, which falls on the customer side of the shared responsibility model.

How did the attackers stop victims from shutting down the mining instances?

They called ModifyInstanceAttribute to set disableApiTermination to true on every EC2 instance they launched, so victims had to re-enable termination before deleting the instances. This can also break automated remediation.

How can I tell if my AWS account was affected?

AWS lists indicators including the Docker image yenik65958/secret:user, mining domains under rplant[.]xyz and auto scaling groups named SPOT-us-east-1-G or OD-us-east-1-G followed by a number. GuardDuty findings such as AttackSequence:EC2/CompromisedInstanceGroup and Impact:Runtime/CryptoMinerExecuted also point to this activity.

Related NHI Mgmt Group resources

TruffleNet stolen AWS credentials campaign · 230 million AWS cloud environments compromised · Capital One breach 2019 · AI LLM hijack breach · Secrets Management Guide

How NHI Mgmt Group can help

Cloud access keys, IAM roles and the users attackers create from them are non-human identities that need owners, tight permissions and short lifetimes. Our NHI Foundation Level Training Course shows teams how to discover, govern and protect them before a leaked key becomes someone else's mining fleet.

References

• AWS Security Blog: Cryptomining campaign targeting Amazon EC2 and Amazon ECS (16 December 2025)
• BleepingComputer: Amazon: Ongoing cryptomining campaign uses hacked AWS accounts (17 December 2025)
• The Hacker News: Compromised IAM Credentials Power a Large AWS Crypto Mining Campaign (16 December 2025)
• Dark Reading: Attackers Use Stolen AWS Credentials in Cryptomining Campaign (17 December 2025)
• TechRadar: AWS systems targeted by crypto mining scam using hijacked IAM credentials (17 December 2025)