How do you detect cryptomining malware on servers and cloud accounts?

Cryptomining malware uses your computing power to mine cryptocurrency for an attacker. Signs include sustained high CPU, unexplained cloud bills, unknown processes or containers, and connections to mining pools. Fix it by removing the foothold the attacker used, not only the miner.

What is mining, and why do attackers want your servers?

Bitcoin mining, as described in the original Bitcoin paper, is a proof of work process: miners repeatedly hash block data looking for a result below a target, and the first to find one earns the right to add a block and receive a reward. It costs electricity and hardware. Legitimate miners run specialized machines for it.

Attackers skip the cost by using yours. MITRE ATT&CK calls this resource hijacking, technique T1496, and lists leveraging compute to mine cryptocurrency as one form. The same technique covers selling network bandwidth to proxy networks and abusing messaging services. Victims pay for the electricity or cloud usage, and the miner steals capacity from real workloads.

Which signs should you look for?

1. Sustained CPU or GPU use at or near the maximum, especially off hours.
2. A cloud bill that jumps with new instances in regions you never use, or very large instance types.
3. Unknown processes, often with random names or names copying system tools.
4. Containers running images nobody built, or pods requesting a lot of CPU.
5. Outbound connections to unfamiliar hosts, often held open for a long time.
6. Disabled security tools or modified scheduled tasks and startup entries.

None is conclusive alone. A legitimate batch job can also pin a CPU. The pattern of several together is what matters.

How do miners usually get in?

Common entry points are exposed management interfaces, such as a container API reachable from the internet with no authentication, vulnerable web applications, weak or reused passwords on remote access, and leaked cloud access keys.

A constructed example. A developer commits a cloud access key to a public repository. Within hours someone uses it to launch dozens of large instances in regions the company never uses. The miner is the visible symptom. The leaked key is the cause, and if the team deletes the instances but leaves the key valid, the instances come back.

What do you do when you find one?

1. Capture evidence first: process list, network connections, relevant logs, and a disk or snapshot copy if policy allows.
2. Isolate the host or stop the workload so it cannot keep mining or spread.
3. Find the entry point using logs and fix it: rotate leaked keys, patch the application, close the exposed interface.
4. Remove persistence such as scheduled tasks, startup entries and added accounts.
5. Rebuild from a clean image where possible, instead of trusting a cleaned system.
6. Search the rest of the environment for the same indicators.

How do you prevent it?

Set budget alerts and anomaly alerts on cloud spend, since the bill is often the first signal. Limit regions and instance types to what you use with account level policies. Keep management interfaces off the public internet. Use short-lived credentials and scan code and repositories for secrets. Patch internet-facing software quickly. For containers, run only images from approved registries and set CPU limits.

How to check or apply this

1. Create a cloud budget alert at a level slightly above normal spend.
2. Query your accounts for instances in unused regions.
3. Check for container or management ports reachable from the internet.
4. Add a CPU anomaly alert for servers that are normally idle at night.
5. Scan repositories for access keys, and rotate any found.
6. Write the isolate, investigate, rebuild steps into a runbook.

Quick check

Sources

1. MITRE ATT&CK T1496, Resource Hijacking
2. Bitcoin: A Peer-to-Peer Electronic Cash System

Last reviewed: 18 October 2026.