Cryptojacking Guide: Stolen Cloud Credentials, Detection and Cost Control

Cryptojacking is the theft of your compute to mine cryptocurrency, and in the cloud it usually starts with a stolen access key and ends with a bill that dwarfs what the attacker earned. Attackers who obtain cloud credentials, or find an unauthenticated container API or Kubernetes dashboard, can launch hundreds of instances or containers within minutes. Because the payoff is immediate and needs no data theft, mining is often the first thing done with fresh access, and it is frequently a sign of a wider compromise. This guide covers how cloud, container and browser-based cryptojacking work at a concept level, where they show up, how to detect them through security findings and billing anomalies, and how to prevent and contain them. It is written for cloud security, platform and FinOps teams. It is defensive only and contains no attacker procedures.

Key takeaways

• It is an identity problem first. AWS's analysis of a November 2025 campaign found compromised IAM user credentials with admin-like privileges, not a service vulnerability, and miners running within 10 minutes.
• The victim pays far more than the attacker earns. Sysdig estimated victims lose about $53 in cloud costs for every $1 of cryptocurrency mined.
• Exposed services are the other door. Unauthenticated Docker daemons, open Kubernetes dashboards and databases with trust authentication are scanned for continuously.
• Billing is a security signal. Cost anomaly detection and forecast-based budget alerts catch what logging gaps miss, but they lag by hours, so pair them with real-time threat findings.
• Mining is rarely the only goal. The same access is used for persistence, credential theft and phishing infrastructure, so treat every cryptojacking finding as a full incident.

How the attack works

MITRE ATT&CK classifies cryptojacking under T1496 Resource Hijacking, mainly the sub-technique T1496.001 Compute Hijacking. Related sub-techniques cover bandwidth, SMS pumping and T1496.004 Cloud Service Hijacking. The attack has three stages.

1. Getting access

• Stolen or leaked cloud credentials: long-lived access keys found in code, container images, CI logs or developer machines (T1552.001 Credentials In Files), or taken from instance metadata services (T1552.005), then used as T1078.004 Valid Accounts: Cloud Accounts.
• Exposed container APIs: Aqua reported in October 2024 that TeamTNT scanned for unauthenticated Docker daemons on ports 2375, 2376, 4243 and 4244 and enrolled compromised hosts into a Docker Swarm.
• Misconfigured workloads and vulnerable images: Microsoft found Kinsing gaining access through outdated images (PHPUnit, Liferay, WebLogic, WordPress) and PostgreSQL containers set to trust authentication (T1190 Exploit Public-Facing Application).
• Weak passwords: Google's November 2021 Threat Horizons report attributed 48% of compromises of 50 sampled Google Cloud instances to weak or no passwords, with 86% of those instances then used for mining.

2. Deploying capacity

• Cloud APIs: in the AWS-documented campaign the actor checked service quotas, tested permissions with RunInstances DryRun calls, then created dozens of ECS clusters with task definitions requesting 16,384 CPU units and 14 Auto Scaling groups with a maximum of 999 instances each (T1578.002 Create Cloud Instance).
• Containers: miners run as new containers on a compromised host or cluster (T1610 Deploy Container). In the 2020 Kubeflow campaign, Microsoft saw miners deployed through notebook images and a notebook's default service account.
• Images: malicious images pulled from public registries, sometimes from compromised registry accounts (T1525 Implant Internal Image covers backdooring your own images).

3. Staying in

• Enabling instance termination protection (DisableApiTermination) so responders and automated remediation cannot simply delete instances.
• Creating new IAM users, access keys and roles, and public Lambda function URLs with auth type NONE (AWS, December 2025).
• Renting out compromised capacity: Aqua saw TeamTNT list victim infrastructure on Mining Rig Rentals.

Where it shows up

Browser-based cryptojacking peaked with Coinhive, a JavaScript Monero miner that attackers injected into compromised websites and plugins. ESET noted that copycat services appeared after Coinhive shut down, so content security policy and script integrity controls still matter, but the financially significant risk today is in the cloud.

Impact

• Direct cost: compute, GPU and data transfer charges. Sysdig's 2022 analysis of TeamTNT activity put the victims' cost of mining 39 XMR at about $429,000, against roughly $8,120 in wallet value.
• Quota and capacity exhaustion: attackers consume service quotas, so legitimate scaling fails during the incident.
• Wider compromise: the same credentials can read data, create persistence and launch phishing. In the AWS case the actor created an IAM user with SES full access, which AWS assessed as preparation for phishing.
• Response friction: termination protection and hundreds of resources across Regions make clean-up slow and error-prone.

Detection

Security findings and logs

Billing anomaly detection

• AWS Cost Anomaly Detection: machine learning monitors per service, account, cost allocation tag or cost category, runs about three times a day, and ranks root causes by service, account, Region and usage type. Data can lag up to 24 hours and a new service needs 10 days of history.
• Google Cloud budgets: default alert thresholds are 50%, 90% and 100% of actual spend; forecasted thresholds alert earlier; Pub/Sub notifications enable automation. Alert-only budgets do not cap spending; spend cap budgets can pause supported services.
• Practice: route cost alerts to the security on-call channel, not only to finance, and alert on spend in Regions and instance families you never use.

D3FEND's Resource Access Pattern Analysis describes the defensive idea behind these anomaly checks.

Metrics

• Percentage of accounts and Regions with threat detection and runtime monitoring enabled.
• Number of long-lived human IAM access keys, trending to zero.
• Mean time from first mining finding to credential revocation.
• Percentage of accounts with cost anomaly monitors routed to security.
• Count of internet-exposed container APIs, dashboards and databases found by external scanning.

Prevention and hardening

Phased approach

1. Remove long-lived keys: move people to federated SSO with temporary credentials and MFA, and workloads to roles and workload identity. Scan code, images and CI for secrets. See the Secrets Management Guide.
2. Apply least privilege: few identities should be able to create compute at scale (SP 800-53 AC-6, CSF PR.AA-05). See the AWS IAM Policies and Roles Guide.
3. Set guardrails: use organisation policies such as AWS SCPs to deny unused Regions and instance families and block Lambda function URLs with auth type NONE. Test new policies on a sandbox organisational unit before applying widely, and keep the previous policy version for rollback.
4. Close exposed services: never expose the Docker daemon without TLS client authentication, keep Kubernetes dashboards and ML consoles behind authentication, and remove database trust authentication (CM-7). See the Container Security Guide.
5. Constrain clusters: namespace ResourceQuota limits on CPU and GPU, admission control that allows only trusted registries and signed images, and restricted service account permissions. See the Kubernetes Admission Control Guide and Kubernetes RBAC Guide.
6. Enable detection everywhere: threat detection in all accounts and Regions, runtime monitoring, centralised audit logs and cost anomaly monitors (SI-4, AU-6, CSF DE.CM-09).
7. Prepare response: a runbook that revokes keys and sessions, disables termination protection before deleting resources, sweeps every Region, and hunts for new IAM users, keys and function URLs (IR-4). See the Cloud Incident Response Guide.

Decision guidance

• Preventive guardrails or detection: Region and instance-type denies are cheap and stop most opportunistic mining; organisations that genuinely use GPUs or many Regions must rely more on detection and quota limits.
• Spend caps: hard caps suit sandboxes and student or test projects; production usually needs alerts with automated containment rather than a cap that can take services offline.
• Small teams: start with no human access keys, an SCP for unused Regions, cost anomaly alerts and native threat detection. Large estates add runtime security, image signing and automated containment through event rules.

Where identity fits

Cloud cryptojacking is overwhelmingly a non-human identity problem: access keys, service accounts and workload tokens with permission to launch compute. Inventory these identities, remove unused ones, rotate what remains and alert when a key is used from a new network or location. See the Kubernetes Service Account Token Guide.

Framework mapping

Lessons from incidents

• Minutes, not days: in the Amazon AWS crypto-mining campaign, compromised IAM credentials had miners running in about 10 minutes, so detection that relies only on next-day billing is too slow.
• Keys leak through images: the Docker Hub secrets leak showed cloud keys baked into thousands of public container images, exactly the kind of credential cryptojackers harvest.
• Convenience changes create exposure: Kubeflow users who switched the Istio ingress to a public load balancer exposed a dashboard that could deploy containers.
• Clean-up is booby-trapped: termination protection and public function URLs keep access alive if responders delete only the obvious instances.

Practitioner checklist

• Eliminate long-lived human access keys and enforce MFA on all console access.
• Scan repositories, images and CI logs for cloud keys, and rotate anything found.
• Deny unused Regions and instance families with organisation-level policy.
• Enable threat detection and runtime monitoring in every account and Region.
• Alert on DryRun calls, quota checks and bulk instance or cluster creation.
• Route cost anomaly and forecast budget alerts to the security on-call channel.
• Remove unauthenticated Docker APIs, dashboards and database trust authentication from the internet.
• Apply ResourceQuota limits and trusted-registry admission policies in Kubernetes.
• Keep a runbook covering termination protection, all Regions and new IAM artefacts.

Standards and references

• MITRE ATT&CK: Resource Hijacking
• AWS Security Blog: Cryptomining campaign targeting Amazon EC2 and Amazon ECS
• AWS: GuardDuty EC2 finding types
• AWS: Detecting unusual spend with AWS Cost Anomaly Detection
• Google Cloud: Create, edit, or delete budgets and budget alerts
• Microsoft Security Blog: Misconfigured Kubeflow workloads are a security risk
• NIST: SP 800-53 Rev. 5
• The Hacker News: TeamTNT launches new cloud attacks for crypto mining

Related NHI Mgmt Group resources: Cloud Security Guide · Kubernetes Security Guide · Container Image Security Guide · Top 10 Cloud Security Risks