Exposed IAM Credentials Drive Huge AWS Crypto Mining Operation
A large-scale cryptomining campaign is abusing exposed AWS IAM credentials to deploy persistent mining infrastructure. The operation leverages stealthy techniques to evade detection, inflate cloud costs, and maintain long-term access to compromised environments.
Experts in security have discovered an ongoing and very well-planned crypto mining operation that is aiming at the Amazon Web Service (AWS) ecosystems. The attackers are using the compromised Identity and Access Management (IAM) credentials to quickly set up the mining infrastructure in multiple AWS services.
This whole operation was first detected on the 2nd of November, 2025, by Amazon GuardDuty and internal automated monitoring systems. Amazon has stated that the campaign is remarkable for its application of completely new persistence methods which are meant to postpone detection, hinder response operations, and keep the mining going for a longer time than before.
How the attack unfolds
The operation initiates by using the compromised IAM user credentials that hold expansive, almost administrative, rights. After the initial access, the intruder instantly lists out the resources and permissions open to him.
One of the first actions is to invoke the EC2 RunInstances API with the DryRun parameter switched on. This gives the attacker a chance to check if they have been granted enough permissions to set up instances without actually introducing any resources. In this way, they do not incur any costs and leave a smaller forensic footprint while confirming the environment is suitable for crypto mining.
The attacker moves to the deployment stage just minutes after getting access. Amazon reports that in a lot of instances, cryptocurrency miners were already operational within 10 minutes from the time of the first compromise.
IAM roles and serverless services moreover were extensively abused by attackers
Once permissions were approved, the intruder created new IAM roles using CreateServiceLinkedRole and CreateRole methods. Those roles were designated for the AWS Lambda function and the autoscale group. The next step was to attach the AWSLambdaBasicExecutionRole managed policy to the Lambda role thereby allowing the execution of the malicious serverless workloads.
A massive campaign went on regarding the abuse of Amazon Elastic Container Service. In some cases, the hacker got to the creation of even dozens of ECS clusters, with the number sometimes being higher than 50 within one AWS account. Each cluster was assigned a task definition referring to an already malicious Docker image that was previously hosted on Docker Hub.
Amazon has pointed out that the image, yenik65958/secret:user, was set in such a way that a shell script would be executed immediately upon its deployment. The script was responsible for the launching of a cryptocurrency miner utilizing the RandomVIREL mining algorithm. Despite the removal of the image, it was, nevertheless, the main one to be used during the campaign.
Furthermore, the attacker had Fargate configured for ECS services to keep mining workloads starting automatically as soon as clusters were created.
Scaling abuse and resource exhaustion
The attacker not only went after containers but also created EC2 autoscaling groups with aggressive scaling policies. Some of the groups were set to scale from a minimum of 20 instances to a maximum of 999, in this way, they were deliberately pushing the limits of EC2 service quotas.
The mining operations captured a broad spectrum of EC2 instance types, these included GPU (graphics processing unit) enabled and machine learning instances along with compute-optimized, memory-optimized, and general-purpose instances. This tactic not only consumed all the resources available but also significantly raised the costs for the victims who were affected.
Persistence through termination protection
This campaign stands out in particular for the way it made use of the ModifyInstanceAttribute API to bring about EC2 termination protection (the parameter disableApiTermination was set to True) and the subsequent fiasco that resulted from it.
When termination protection is active, the respective instances will not be able to be terminated via the AWS console, CLI or API until the setting is manually reversed. This causes a delay in incident response and can render automated remediation tools ineffective.
Amazon pointed out that this method showed not only a profound knowledge of the typical security response processes in cloud environments but also a determination to prolong the duration of mining operations.
The potential dangers that come with this API action are already known. In April 2024, the security researcher Harsha Koushik showed how ModifyInstanceAttribute could be abused in a proof of concept to take over EC2 instances, steal instance role credentials, and later on even control an entire AWS account.
Additional malicious activity
The threat actors went beyond just mining. The detection by the investigators of the generation of a Lambda function that could be triggered by any entity, thus practically making it by default open to everyone, was one of the significant indications.
They have also set up a new IAM user with the name user-x1x2x3x4 and connected the AmazonSESFullAccess managed policy. This provides unrestricted access to Amazon Simple Email Service and indicates that the system might be sending or generating unsolicited phishing or spamming emails.
Recommended defensive measures
Amazon has come up with a concise list of AWS security measures for its customers in order to get rid of the risk of going through the same issues. Below are those measures:
-
Establish strict IAM protocols across all the accounts
-
Long-term access keys that have been used for logging in should be replaced with temporary credentials in case of access
-
Every user should have multi-factor authentication
-
Least privilege should be applied to all IAM roles and users
-
Make sure to scan container images for any malicious or questionable content
-
Keep an eye on ECS task definitions for any unusual CPU or resource requests
-
Turn on AWS CloudTrail to monitor and keep the logs of activities in the cloud
-
Make sure Amazon GuardDuty is always on to help with detection and also automating the response when necessary
Amazon stated that the attacker's methodical use of numerous compute services, along with the innovative persistence techniques, has resulted in a significant evolution in cloud-based crypto mining attacks.