How do attackers use cryptomining in the cloud?

How cryptomining abuse works in cloud environments

Cloud cryptomining is usually a resource-hijacking problem, not a malware-only problem. Attackers gain footholds through weak access control, exposed secrets, vulnerable workloads, or misconfigured cloud services, then turn your infrastructure into a revenue stream. The cloud makes that attractive because miners can scale quickly, hide in legitimate-looking compute, and blend into normal usage until costs or performance reveal them.

The key pattern is persistence through legitimate mechanisms. Once inside, attackers often create new identities, service principals, instances, containers, scheduled jobs, or startup scripts so the mining workload survives reboots and cleanup attempts. That is why cloud mining abuse often looks like ordinary admin activity at first, especially if logging, inventory, and approval workflows are weak.

For cloud-specific guardrails, start with the Cloud Security Guide, which frames the shared-responsibility and logging controls that make this abuse visible in the first place.

Why attackers prefer cloud resources for cryptomining

Cloud resources give attackers on-demand scale, geographic flexibility, and someone else’s bill. They can spin up CPU-heavy or GPU-capable capacity, disperse workloads across accounts or regions, and rapidly replace terminated instances. The abuse is profitable when defenders miss the early signals, especially cost anomalies, inventory drift, and new access paths that were not part of the intended architecture.

Attackers also like cloud because the environment already expects automation. A miner deployed through an abused identity can look like a normal workload deployment, autoscaling event, or infrastructure change. When organisations lack strong separation between dev, test, and production, or when keys and tokens are reused across environments, the attacker can move from a minor foothold to broad resource consumption very quickly.

The broader breach pattern is well documented in The State of NHI & AI Agent Breach Report 2026, which shows how exposed keys, stolen tokens, and compromised service accounts often become the first step in abuse chains.

What defenders should watch and contain first

Cloud cryptomining is easiest to stop when you treat it as an identity and resource-control incident, not just a malware cleanup. The first question is whether the attacker still has a way to create or restart compute. If the answer is yes, removing one container or VM will not end the problem. You need to find the access path, the persistence mechanism, and the billing footprint together.

Useful indicators include unexplained spend, bursty CPU or GPU use, unfamiliar regions, new autoscaling groups, and identities created without a normal approval trail. Also check for secret material that was added recently, because mining campaigns often rely on newly minted access rather than long-term compromise. For incident handling, the fastest path is to revoke the abused credentials, isolate the affected workloads, and review cloud audit logs for resource-creation events that match the first cost spike.

Attack paths and cleanup lessons are covered in Storm-1283 OAuth apps abuse 2023, where attacker-controlled application credentials were used to launch cryptomining at cloud scale.

Risk and Threat Considerations

Cloud cryptomining is often the visible symptom of a broader compromise. The immediate loss is compute cost, but the deeper risk is that the same access used for mining can also be used for data access, lateral movement, or additional persistence. In practice, mining can be a holding pattern that keeps the attacker embedded while they test what else the environment will allow.

Failure mechanism: Attackers abuse over-permissive identities, exposed keys, or vulnerable workloads to create durable compute resources, then keep rotating through new instances or jobs when defenders remove the obvious one.

Impact: Organisations can see runaway cloud spend, service degradation, hidden persistence, and delayed detection of a wider compromise, especially when mining activity is mistaken for an isolated capacity issue.

Practitioner Guidance

What to prioritise: Prioritise the access path that enabled resource creation before you focus on the miner payload itself. If an identity can provision compute, attach storage, or create new secrets, that identity has to be treated as part of the incident scope.

What to verify: Confirm whether the suspicious workload was created through an approved pipeline, an autoscaling event, or an interactive action. If it was not, check who or what created the role, token, key, or service principal that made the action possible.

Decision rule: If the mining activity can still be recreated from a surviving credential or automation path, rotate or revoke that access first, then rebuild the affected workload from known-good templates rather than trying to preserve the compromised instance.

Practitioner takeaway: Cloud mining abuse is rarely just a cost anomaly, it is usually evidence that someone found a durable way to turn your cloud control plane into their compute platform.

Related resources from NHI Mgmt Group

• How do overprivileged NHIs increase breach impact in cloud environments?
• How do attackers turn a supply-chain incident into wider NHI compromise?
• How do attackers operationalise stolen OAuth tokens at scale?
• Why do attackers often check model availability before trying to generate content?