Stolen IAM Keys Fuel Massive AWS Cryptomining Operation

An ongoing AWS-wide cryptomining campaign is abusing stolen IAM credentials to spin up miners within minutes, Amazon reports. First spotted by GuardDuty and automated monitoring on November 2, 2025, the operation uses persistence tactics that slow incident response while maximizing cost to victims. The actor operated from an external hosting provider.

How the intrusion unfolds

• Initial access and recon: Using admin-like IAM user credentials, the actor rapidly enumerates resources and EC2 quotas. They validate permissions by calling RunInstances with the DryRun flag, avoiding costs and minimizing forensic traces while confirming the environment can support miner deployment.
• Role staging and cluster sprawl: The actor creates roles via CreateServiceLinkedRole and CreateRole, attaching AWSLambdaBasicExecutionRole. They then stand up dozens of ECS clusters, in some cases more than 50 in a single environment.
• Miner deployment: RegisterTaskDefinition is used to point to a malicious DockerHub image (yenik65958/secret:user), followed by service creation to launch mining tasks on ECS Fargate. Miners are operational within about 10 minutes. The image ran a shell script that starts mining using the RandomVIREL algorithm.
• Aggressive scaling on EC2: Autoscaling groups are configured to scale from 20 to 999 instances, attempting to exhaust EC2 service quotas and drive up resource consumption. Targets include GPU and ML-optimized instances as well as compute, memory, and general-purpose types.
• Persistence and response evasion: ModifyInstanceAttribute sets disableApiTermination=True, blocking console, CLI, and API termination until protection is manually removed. This disrupts automated remediation and mirrors a 2024 PoC by researcher Harsha Koushik that highlighted the risk.
• Additional abuse: The actor creates a Lambda function invocable by any principal and an IAM user (user-x1x2x3x4) with the AmazonSESFullAccess managed policy, likely enabling SES-powered phishing operations.

AWS perspective
AWS states this is not a vulnerability in AWS; the attacker must already possess valid credentials. GuardDuty proactively detected the activity and AWS alerted affected customers, even though the actions occurred in the customer domain of the shared responsibility model.

Recommended defenses

• Enforce strong identity and access management hygiene and least privilege
• Prefer temporary credentials over long-lived access keys
• Require MFA for all users
• Add container security controls and scan images for suspicious content
• Monitor unusual CPU allocation requests in ECS task definitions
• Enable and review CloudTrail across services
• Ensure GuardDuty is enabled and wire it to automated response workflows

Why it matters
This campaign combines scripted use of multiple compute services with new persistence techniques, marking a notable escalation in cryptomining tactics aimed at prolonging runtime and inflating cloud costs while hindering incident response. Note: The story was updated after publication to emphasize the campaign does not exploit any AWS security flaw.

Source: The Hacker News