What should organisations do when they suspect cryptomining activity on on-prem, Kubernetes, or cloud assets?

Treat suspected cryptomining as both a detection and containment event. Investigate the workload source, isolate affected systems, review exposed credentials or vulnerable services, and verify whether the activity spread across virtual machines, pods, or cloud instances. Then patch weaknesses, tighten endpoint and network monitoring, and confirm that resource abuse stops without disrupting legitimate operations.

Why Suspected Cryptomining Needs Immediate Containment

Suspected cryptomining is not just a capacity issue, it is often a sign that an asset has already been abused for unauthorised execution. On-prem servers, Kubernetes clusters, and cloud instances can all be mined through exposed services, stolen credentials, weak images, or overly permissive runtime access. The operational problem is that mining activity usually blends into “normal” high CPU usage until it is tied back to a specific workload or control failure.

For containerised environments, NIST SP 800-190 Container Security is a useful baseline because it frames the image, registry, orchestrator, and runtime layers that often determine whether mining can persist unnoticed. In cloud and platform environments, the first question is not whether CPU is high, but whether the workload still has legitimate authority to run. The fastest value comes from correlating process activity, network destinations, and recent access changes across all affected layers.

In practice, many teams find cryptomining only after the environment has already been used as a foothold for broader abuse, rather than through a purpose-built mining alert.

How It Works in Practice

The response should start with scope, because cryptomining on one asset type often spreads through shared images, reused secrets, or copied deployment patterns. On a bare-metal or virtual server, investigators should determine which process launched the miner, what account executed it, and whether the host also shows signs of lateral movement or persistence. In Kubernetes, that means checking the pod spec, image provenance, service account usage, node placement, and any recent changes to ConfigMaps, Secrets, or admission controls. In cloud, it means checking instance metadata access, security group exposure, IAM permissions, and whether the workload is running under a role that can reach other services.

The containment sequence is usually:

isolate the affected host, pod, node, or instance without deleting evidence first;
collect process, network, and authentication telemetry to identify the entry path;
revoke or rotate any exposed secrets, tokens, API keys, certificates, or cloud credentials;
patch the vulnerable service, image, or control plane weakness that allowed execution;
block known mining pools and related outbound destinations where that does not interfere with normal business traffic;
verify that resource consumption returns to baseline after the suspected workload is removed.

CSA Cloud Controls Matrix is relevant here because cryptomining across cloud estates usually reflects a control gap in logging, IAM, vulnerability management, or workload protection rather than a single isolated host event. If the same activity is visible across multiple virtual machines, pods, or instances, treat that as a sign of shared exposure, not independent coincidence. These controls tend to break down when teams only remediate the miner process and leave the underlying secret, image, or access path intact.

Common Variations and Edge Cases

Tighter containment often increases service disruption, so organisations have to balance evidence preservation and blast-radius reduction against uptime requirements. A miner running inside a Kubernetes pod is usually easier to replace than a miner embedded in a critical legacy VM, but the investigation standard should still be the same: prove where the execution authority came from before restoring service.

Cloud cases also differ from on-prem cases because the attacker may be abusing ephemeral infrastructure rather than a fixed host. A terminated instance does not necessarily end the incident if the same credentials, automation token, or image pipeline can recreate the problem. In container environments, the hardest edge case is a compromised base image or CI/CD path, where the visible miner is only the symptom and the real issue is supply-chain or deployment trust.

The State of Secrets Sprawl 2025 is useful when the suspected miner may have entered through leaked credentials rather than an obvious software flaw. Current guidance suggests treating repeated miner reappearance as a sign that the trust boundary has not actually been fixed, even if the original process has been removed.

Risk and Threat Considerations

Suspected cryptomining indicates exposure beyond wasted compute. It can reflect unauthorised workload execution, stolen credentials, weak runtime controls, or a vulnerable service that gives an attacker durable access to on-prem, Kubernetes, or cloud resources. The same conditions that support mining also support persistence, reconnection, and further abuse.

Failure mechanism: Attackers typically obtain execution through exposed management interfaces, compromised secrets, misconfigured IAM, vulnerable containers, or compromised automation paths, then use the asset’s own compute and network access to sustain mining while remaining low visibility. On Kubernetes and cloud platforms, shared images and reusable credentials can let the same compromise spread quickly.

Impact: Organisations can lose compute capacity, absorb cloud cost spikes, disrupt production workloads, and leave a reusable access path in place after the miner is removed. If the root cause is not closed, the environment may be reinfected or used for broader malicious activity.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS 7 — Continuous Vulnerability Management	Cryptomining commonly exploits unpatched systems and exposed services.
	CIS 8 — Audit Log Management	Investigations depend on process, auth, and network telemetry to scope the compromise.
	CIS 12 — Network Infrastructure Management	Blocking mining pools and constraining egress limits external command-and-control and payouts.
Recommendation — Prioritise patching and exposure reduction for the vulnerable path that enabled mining. Collect and retain logs that show execution, authentication, and outbound mining activity. Restrict outbound paths so mining traffic cannot reach external pool infrastructure.
NIST CSF 2.0	DE.CM — Security Continuous Monitoring	Cryptomining is detected through telemetry on resource, process, and network behaviour.
	RS.MI — Mitigation	Containment requires isolating affected assets and stopping the abusive workload.
	RC.RP — Recovery Plan Execution	Recovery must confirm the workload is clean and the abuse path is removed.
Recommendation — Continuously monitor host, pod, and cloud activity for abnormal compute abuse. Contain the affected asset and remove the abusive workload before restoring service. Restore service only after validating that the miner and its foothold are eliminated.
NIST SP 800-63	IAL/AAL/Authenticator lifecycle — Authenticator and lifecycle assurance	Compromised credentials or tokens often enable the initial mining foothold.
Recommendation — Rotate exposed authenticators and validate the access path before trusting the workload again.
NIST Zero Trust (SP 800-207)	SC and policy enforcement architecture — Policy enforcement and continuous verification	Zero trust limits blast radius when a workload or credential is compromised.
Recommendation — Apply continuous policy enforcement so compromised workloads cannot freely expand access.
MITRE ATT&CK	T1496 — Resource Hijacking	Resource hijacking is the core abuse pattern behind cryptomining activity.
	T1059 — Command and Scripting Interpreter	Many miners are launched through scripts or interpreters after initial access.
Recommendation — Map the activity to resource hijacking and hunt for related persistence and propagation. Look for scripted execution paths that delivered the miner onto the asset.

Practitioner Guidance

What to prioritise: Treat the first objective as proving and closing the access path, not merely killing the process. If the miner disappears but the credential, image, or exposed service remains, assume the incident is unresolved.

What to verify: Confirm the workload’s origin, execution identity, network egress, and any recent changes to deployment artifacts or permissions. In Kubernetes and cloud, verify whether the same image, role, or secret is present elsewhere before declaring containment.

Common mistake: Teams often reset the affected host or delete the pod before collecting enough telemetry to identify the source. That removes evidence and can mask a broader compromise pattern that would otherwise explain why the miner returned.

Practitioner takeaway: A credible cryptomining response is successful only when the environment stops mining and the underlying path to execution, privilege, or deployment is demonstrably closed.