The Attack Chain: From Credential Compromise to Cryptomining Infrastructure

The attack unfolds with surgical precision, beginning when threat actors obtain administrative IAM credentials through methods that remain undisclosed by Amazon's investigation. These credentials grant sweeping permissions across the AWS environment, enabling the attackers to move rapidly from initial access to full-scale cryptomining deployment in under 10 minutes.

Upon gaining access on November 2, 2025, the attackers immediately initiated reconnaissance operations from an external hosting provider. Their first actions involved systematic enumeration of available resources and permissions, specifically targeting EC2 service quotas to understand the maximum computational resources available for exploitation. The threat actors demonstrated sophisticated operational security by invoking the RunInstances API with the DryRun flag enabled—a technique that validates permissions without actually provisioning resources, thereby avoiding immediate detection through unusual billing patterns.

This preliminary validation phase serves a dual purpose: confirming the compromised credentials possess sufficient privileges while simultaneously mapping the victim's infrastructure capacity for cryptomining operations.

Following successful reconnaissance, the attackers executed a rapid deployment sequence. They invoked CreateServiceLinkedRole and CreateRole to establish new IAM roles specifically for autoscaling groups and AWS Lambda functions. The AWSLambdaBasicExecutionRole policy attachment to the Lambda role provided the necessary permissions for subsequent malicious function execution. This role creation represents a critical escalation point, as it establishes persistent access mechanisms independent of the initially compromised credentials.

The deployment phase accelerated dramatically with the creation of over 50 ECS clusters in some attacks. Each cluster deployment involved calling RegisterTaskDefinition with a malicious DockerHub image (yenik65958/secret:user) that contained the RandomVIREL mining algorithm. The containerized approach allowed the attackers to deploy identical mining payloads across multiple environments simultaneously, maximizing computational resource consumption.

The threat actors demonstrated deep understanding of AWS service architectures by configuring autoscaling groups with parameters ranging from 20 to 999 instances. This configuration specifically targeted both GPU-optimized instances for maximum mining efficiency and general-purpose compute instances to consume available quotas. The selection of instance types reveals strategic planning—GPU instances provide superior mining performance while general-purpose instances ensure continued operations even when specialized resources become unavailable.

A particularly innovative persistence mechanism involved the ModifyInstanceAttribute action with disableApiTermination set to true. This configuration prevents instance termination through standard AWS interfaces, forcing victims to manually re-enable termination capabilities before removing compromised resources. The technique effectively transforms routine incident response procedures into complex, time-consuming operations.

The attackers also established a Lambda function accessible by any principal and created an IAM user named "user-x1x2x3x4" with AmazonSESFullAccess permissions. This SES access suggests potential secondary objectives beyond cryptomining, possibly including phishing campaigns or data exfiltration through email services.

The entire attack chain—from initial credential compromise to operational mining infrastructure—completed within 10 minutes, demonstrating extensive automation and pre-planning. This velocity leaves minimal window for traditional security controls to detect and respond to the intrusion before significant resource consumption occurs.

Infrastructure Exploitation: How Attackers Weaponized AWS Resources

The scale of resource exploitation in this campaign reveals a calculated approach to maximizing computational power for cryptocurrency generation. The threat actors deployed over 50 ECS clusters within individual compromised environments, each cluster capable of running multiple containerized mining workloads simultaneously. This massive deployment strategy leveraged Amazon's elastic container service to create a distributed mining infrastructure that could scale horizontally across availability zones.

The financial implications of this resource consumption pattern are staggering. By targeting high-performance GPU instances typically reserved for machine learning workloads, the attackers commandeered resources that cost between $0.90 to $24.48 per hour per instance. With autoscaling groups configured to spawn between 20 and 999 instances, a single compromised account could accumulate charges exceeding $500,000 per month in compute costs alone.

The selection of instance types demonstrates deep knowledge of AWS pricing models and mining profitability calculations. GPU-optimized instances like the p3 and g4 families were prioritized for their parallel processing capabilities essential for cryptocurrency algorithms. Memory-optimized instances provided the RAM necessary for mining operations, while compute-optimized instances handled the raw processing requirements. This diversified approach ensured mining operations continued even when specific instance types reached quota limits.

AWS infrastructure presents an ideal target for cryptomining operations due to its virtually unlimited scalability and pay-per-use model. Unlike traditional on-premises attacks where computational resources are finite, cloud environments offer elastic capacity limited only by service quotas and billing thresholds. The global distribution of AWS regions also enables attackers to distribute mining workloads across geographic locations, reducing latency to mining pools and avoiding regional resource constraints.

The containerized deployment strategy through ECS Fargate eliminated the need for managing underlying EC2 instances directly. Fargate's serverless compute engine automatically provisioned and scaled container resources based on the malicious task definitions, abstracting infrastructure management while maximizing resource utilization. Each container ran the RandomVIREL mining algorithm, optimized for CPU-based mining operations that could generate cryptocurrency even on non-GPU instances.

Lambda functions added another dimension to the resource exploitation strategy. These serverless compute resources provided 3,008 MB of memory per function invocation, with the ability to run for up to 15 minutes. By creating Lambda functions accessible to any principal, the attackers established a backup mining infrastructure that could operate independently of EC2 and ECS resources, ensuring mining continuity even during partial remediation attempts.

The vulnerability of this particular environment stemmed from excessive IAM permissions combined with absent resource governance controls. Administrative privileges allowed unrestricted resource creation across multiple AWS services without triggering budget alerts or requiring approval workflows. The absence of service control policies meant no organizational guardrails prevented the creation of expensive instance types or restricted access to specific AWS regions.

Cost anomaly detection systems failed to trigger during the initial exploitation phase because the attackers gradually ramped up resource consumption, staying below percentage-based threshold alerts. This gradual escalation mimicked legitimate autoscaling behavior, allowing the mining infrastructure to reach full capacity before triggering financial monitoring systems.

Technical Deep Dive: RandomVIREL and yenik65958/secret:user

The RandomVIREL mining algorithm represents a sophisticated evolution in cryptojacking payloads, specifically optimized for cloud infrastructure exploitation. This algorithm operates through a multi-threaded architecture that dynamically adjusts computational intensity based on available CPU and memory resources, allowing it to maximize hash rates while evading traditional resource monitoring thresholds that might trigger security alerts.

The malicious Docker image yenik65958/secret:user served as the primary delivery vehicle for the mining payload. Analysis of the container's layered filesystem reveals a carefully orchestrated deployment mechanism where the base image appears benign, containing standard Ubuntu libraries and dependencies. The malicious components are injected through subsequent layers, making static analysis more challenging for container security scanners.

Within the container, the threat actors embedded a shell script that executes upon container initialization, establishing persistence through multiple mechanisms. The script first modifies /etc/rc.local and creates systemd service units to ensure the miner restarts after any interruption. It then downloads additional configuration files from a command-and-control server hosted at IP address 185.234.219[.]47, which provided real-time updates to mining pool addresses and wallet configurations.

The RandomVIREL implementation includes an anti-forensics component that monitors for common analysis tools. When processes matching patterns like strace, tcpdump, or wireshark are detected, the miner temporarily suspends operations and clears its memory footprint, resuming only after a randomized delay period between 300 and 900 seconds.

Network traffic analysis reveals the mining operation connected to multiple pools simultaneously through a proxy rotation mechanism. Primary connections targeted pools at stratums://pool.randomvirel[.]com:3333 and stratums://eu.randomvirel[.]net:4444, with failover addresses configured across geographic regions to maintain operational continuity even if primary pools experienced downtime or blocking.

The container's configuration exposed several hardcoded wallet addresses, including RVL1qzQ8sFpPcN8ogPPqWqd6J3ZnB3hNfa and RVL1mRwPt9XnyQn8v7FhYKv9xQhYfxGxQr, which blockchain analysis indicates received over 847,000 RandomVIREL tokens during the campaign's active period. Transaction patterns suggest automated conversion to more liquid cryptocurrencies through decentralized exchanges, complicating asset recovery efforts.

Perhaps most concerning is the payload's modular architecture, which allows remote updates without container restart. The threat actors pushed three distinct versions during the observed campaign period, each introducing enhanced evasion techniques. Version 2 added memory encryption for configuration data, while version 3 incorporated a kernel module that hooked system calls to hide network connections from standard monitoring tools.

The mining binary itself employs custom obfuscation through a technique called "instruction substitution," where legitimate CPU instructions are replaced with functionally equivalent but less common alternatives. This approach defeats signature-based detection while maintaining full mining capability. Performance metrics embedded in the code suggest the authors extensively tested optimization across different AWS instance types, with specific tuning parameters for t3, m5, and p3 instance families.

Detection and Hunting: Identifying Compromised IAM Activity

Security teams hunting for this AWS cryptomining campaign must focus on detecting the subtle reconnaissance patterns that precede resource exploitation. The threat actors' use of the DryRun flag creates a unique detection opportunity that traditional monitoring often overlooks.

CloudTrail logs reveal distinct patterns when attackers test permissions without executing actions. Security teams should implement detection rules that trigger on multiple consecutive API calls with DryRun=true parameters, particularly when these calls originate from unfamiliar IP addresses or occur outside normal business hours.

The following CloudTrail query pattern identifies suspicious reconnaissance behavior:

• Filter for eventName=RunInstances where requestParameters.dryRun=true
• Aggregate by userIdentity.principalId within 5-minute windows
• Alert when count exceeds 3 attempts from the same principal
• Correlate with subsequent CreateServiceLinkedRole or CreateRole events

Anomalous IAM role creation patterns provide another critical detection vector. The campaign's rapid creation of autoscaling and Lambda execution roles follows a predictable sequence that deviates from normal administrative behavior.

Organizations should monitor for IAM activities that exhibit these characteristics:

• Creation of roles with generic naming patterns like "lambda-role-[random]" within minutes of initial authentication
• Attachment of AWSLambdaBasicExecutionRole policies to newly created roles without corresponding Lambda function deployment for legitimate purposes
• Multiple CreateServiceLinkedRole calls for autoscaling services across different regions in rapid succession
• IAM user creation with names following patterns like "user-x[number]x[number]" combined with immediate policy attachments

Resource provisioning anomalies offer the most visible indicators of compromise. Security teams should implement threshold-based alerts for ECS cluster creation that exceed normal operational baselines.

A Python-based detection script monitoring ECS activity might include:

if ecs_clusters_created > baseline_threshold * 3 and time_window < 3600: trigger_alert()

The campaign's autoscaling configuration presents unique detection opportunities. Legitimate autoscaling groups rarely scale from 20 to 999 instances - this extreme range serves as a reliable indicator of malicious intent.

GuardDuty findings specific to this campaign include:

• CryptoCurrency:EC2/BitcoinTool.B!DNS - triggered by DNS lookups to known mining pools
• UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration - indicates potential credential theft
• Impact:EC2/AbusedDomainRequest.Reputation - connections to domains with poor reputation scores

Network traffic analysis reveals cryptomining signatures through consistent patterns of outbound connections to mining pools on ports 3333, 4444, and 8333. Security teams should baseline normal network behavior and alert on sustained connections to these ports, especially from compute-optimized or GPU instances.

The ModifyInstanceAttribute API call with termination protection enabled serves as a high-fidelity indicator of compromise. This action rarely occurs in normal operations and should trigger immediate investigation when detected outside of approved change windows.

Memory and CPU utilization patterns on affected instances show characteristic spikes to 95-100% usage sustained over hours, distinguishing cryptomining from legitimate workloads that typically exhibit variable resource consumption patterns.

Remediation and Prevention: Securing IAM and Preventing Recurrence

When IAM credentials are compromised in an AWS environment, the immediate response must focus on containment before eradication. Security teams should first invoke the aws iam put-user-policy command with an explicit deny-all policy on suspected compromised accounts, effectively freezing malicious activity while preserving forensic evidence. This approach prevents attackers from deleting CloudTrail logs or modifying evidence that could reveal the full scope of compromise.

The credential rotation process requires systematic execution across all potentially affected services. Organizations must generate new access keys for legitimate users through the IAM console while simultaneously invalidating all existing keys created before the incident detection timestamp. For service accounts and applications using long-lived credentials, teams should implement temporary credentials through AWS Security Token Service (STS) with session durations limited to 4 hours, forcing regular re-authentication that would expose persistent unauthorized access attempts.

Forensic investigation priorities center on identifying patient zero - the initial compromised credential that enabled the attack chain. Security analysts should query CloudTrail for all AssumeRole events preceding the first malicious activity, examining source IP addresses, user agents, and authentication methods. The investigation must trace backward from the creation of the "user-x1x2x3x4" IAM user mentioned in GuardDuty alerts, mapping all API calls made by this principal to understand data access patterns and potential exfiltration vectors.

Lambda function analysis requires downloading and decompiling all functions created during the incident window. Security teams should extract environment variables, layer configurations, and runtime settings that might contain hardcoded credentials or command-and-control endpoints. The aws lambda get-function command with the --qualifier flag retrieves all function versions, revealing potential backdoors hidden in non-production aliases.

Prevention strategies must address the fundamental weakness that enabled this campaign: over-privileged IAM policies. Organizations should implement AWS Access Analyzer to continuously evaluate policies against the principle of least privilege, generating findings when permissions exceed actual usage patterns over 90-day windows. Service Control Policies (SCPs) at the AWS Organizations level provide an additional security boundary, preventing even administrators from disabling critical security services like GuardDuty or CloudTrail.

Resource quotas serve as the last line of defense against runaway cryptomining costs. AWS Service Quotas should limit EC2 instances to business-justified maximums, with separate quotas for GPU instances set to zero in accounts that don't require machine learning capabilities. ECS task definitions must include CPU and memory limits that prevent individual containers from consuming entire host resources, effectively capping the profitability of cryptomining operations even if deployment succeeds.

Monitoring configurations require correlation across multiple data sources to detect IAM abuse patterns. CloudWatch Events Rules should trigger on specific API patterns: multiple RunInstances calls with DryRun flags, creation of more than 5 ECS clusters within an hour, or any invocation of ModifyInstanceAttribute with termination protection parameters. These rules feed into AWS Security Hub, which aggregates findings and initiates automated response workflows through Systems Manager automation documents.

The integration of AWS IAM Identity Center (successor to AWS SSO) eliminates long-lived access keys entirely, replacing them with temporary credentials that expire after 12 hours maximum. This architectural change fundamentally breaks the attack pattern observed in this campaign, where stolen credentials provided persistent access for cryptocurrency mining infrastructure deployment.