Attackers Use Stolen AWS Credentials in Cryptomining Campaign

Why It Matters

Credential theft in cloud environments can instantly turn legitimate resources into costly, hidden mining farms, exposing organizations to financial loss and operational disruption. The incident underscores the shared‑responsibility model, where weak identity hygiene directly endangers business continuity.

Key Takeaways

• Stolen IAM keys enabled admin access across customers
• Miners deployed on EC2/ECS within ten minutes
• Attackers used dry‑run API checks to avoid detection
• Persistence via disabling instance termination protection
• MFA and temporary credentials recommended to mitigate risk

Pulse Analysis

The rise of credential‑based attacks on public cloud platforms reflects a shift from exploiting software bugs to hijacking trusted identities. In the AWS case, threat actors obtained long‑lived access keys, allowing them to enumerate service quotas, perform dry‑run instance launches, and create privileged roles without incurring immediate costs. This approach lets attackers move quickly, establishing cryptomining containers and Lambda functions while staying under the radar of traditional cost‑monitoring tools.

Technically, the campaign combined several sophisticated tactics. By calling GetServiceQuota and RunInstances with the DryRun flag, the actors verified permissions without provisioning resources. They then used CreateServiceLinkedRole and CreateRole to embed malicious code in auto‑scaling groups and Lambda, attaching the AWSLambdaBasicExecutionRole policy for execution. A novel persistence layer involved the ModifyInstanceAttribute API to disable API‑based termination, forcing responders to manually re‑enable termination before they could shut down the infected instances—an extra hurdle that can delay remediation and increase billable usage.

Mitigation hinges on robust identity hygiene and continuous monitoring. Organizations should replace static access keys with temporary credentials, enforce multi‑factor authentication for all IAM users, and apply the principle of least privilege to limit role capabilities. Enabling GuardDuty, CloudTrail, and custom anomaly detection can surface dry‑run patterns, unusual role creations, and the specific IoCs listed by AWS, such as the malicious Docker image and rplant.xyz domains. By tightening IAM policies and automating response playbooks, enterprises can reduce the attack surface and protect both their cloud spend and security posture.