Teams should compare CPU, GPU, and billing patterns against approved workload behavior and look for mining-like persistence, idle-time execution, or new container deployments without business justification. The key is whether the resource use matches a known service or appears as unplanned, sustained compute demand.
How to distinguish cryptojacking from a legitimate workload surge
The practical difference is not just volume, it is pattern. A real spike usually aligns with release activity, autoscaling triggers, batch windows, or a known business event. Cryptojacking tends to look like sustained, unexplained compute demand that persists outside expected usage patterns, often with no matching change record, deployment rationale, or customer-facing workload.
A strong way to separate them is to compare the spike against normal CPU, GPU, and billing baselines for that service. If the resource growth tracks an approved workload, it is more likely to be benign; if it appears in idle periods, spreads across unexpected containers, or continues after the business driver should have ended, it deserves investigation.
Security teams should also check whether the activity is confined to a single expected service or appears as new compute demand across a host, cluster, or account that was not supposed to change. That distinction matters because cryptojacking often survives by blending into ordinary elasticity, while legitimate demand usually has a traceable owner and purpose.
What workload signals usually separate abuse from business demand?
Normal spikes are usually explainable by one or more of three things: a known release, a scheduled job, or a predictable customer or data-processing event. They also tend to correlate with other operational signals such as deployment events, autoscaler decisions, queue depth, or higher request volume. Cryptojacking does not need those signals, so the compute increase can be disconnected from business traffic.
Another useful indicator is persistence. A healthy workload surge usually rises and falls with the event that caused it. Mining activity is more likely to stay steady, repeat at odd hours, or reappear after a restart. If the spike does not behave like the rest of the service, the team should treat that as a signal mismatch, not just a capacity issue.
It also helps to look for adjacent technical changes. Unexpected container starts, new images, altered startup commands, or extra outbound connections can indicate that the compute increase is being driven by something other than demand from users or downstream jobs.
Why cryptojacking often looks like performance noise
Cryptojacking is attractive because it can hide inside a cloud or container platform as “normal” resource pressure. If defenders only watch for high CPU, they may miss the real clue: the absence of a business reason. Mining also often prefers low-visibility windows, such as idle periods or non-peak times, which can make it look like efficient autoscaling instead of abuse.
That is why teams should interpret the signal in context, not as a single threshold event. A workload that burns CPU for a valid batch job is a capacity question. The same pattern on an unknown container, a newly deployed image, or an account with no approved change history is an access and integrity question as well as a performance question.
For workload identity and runtime attribution, teams can use a SPIFFE workload identity specification style of thinking: tie compute behaviour to a known workload identity, not just to a node or cluster. When that mapping is missing, the spike is harder to trust.
Risk and Threat Considerations
Cryptojacking is not only a cost issue. It can be a sign that an attacker already has usable execution on a host, container, or orchestration platform, and is now turning stolen capacity into persistent profit. That makes it an early warning indicator for broader compromise, especially when the activity is paired with new containers, unusual images, or unexplained outbound traffic.
Failure mechanism: The attacker abuses legitimate compute resources by blending mining activity into normal scaling behaviour, idle-time processing, or unattended container deployments, so the abuse looks like ordinary workload growth.
Impact: Organisations absorb higher cloud cost, degraded performance, and possible lateral movement risk if the same foothold is used for additional payloads, credential theft, or follow-on persistence.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1496 — Resource Hijacking | Cryptojacking is resource hijacking, so this technique directly fits the abuse pattern. |
| Recommendation — Map sustained unexplained compute use to T1496 and hunt for persistence, miner processes, and evasive execution. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | Unexpected miners often exploit exposed, weak, or misconfigured workloads that need continuous exposure management. |
| CIS-8 — Audit Log Management | Distinguishing abuse from a real workload spike depends on deployment, process, and runtime audit trails. | |
| Recommendation — Scan containers and hosts continuously, and remediate exposed services that enable cryptojacking footholds. Centralise and review workload and container audit logs to separate approved demand from suspicious execution. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks and systems are monitored to detect potential cybersecurity events | Detecting cryptojacking depends on monitoring abnormal compute and workload behaviour over time. |
| PR.AA-05 — Identity and access rights for human and nonhuman users are managed | Unauthorized workload deployments and miner persistence are easier to spot when workload access is tightly governed. | |
| Recommendation — Baseline compute behaviour and alert on sustained deviations that lack a business trigger. Restrict workload deployment rights and review who can create or modify compute-running identities. | ||
| OWASP ASVS | V16 — Security Logging and Error Handling | Runtime logging is needed to prove whether a spike came from a known service or unexpected code path. |
| Recommendation — Log deployment, execution, and runtime events so suspicious compute use can be attributed quickly. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Abuse often becomes visible when a workload or service identity can create or run compute beyond its need. |
| Recommendation — Limit workload privileges so a compromised identity cannot spawn miners or expand execution scope. | ||
Practitioner Guidance
What to verify: Confirm whether the spike has a change record, deployment owner, or scheduled job behind it before accepting it as legitimate. If those artefacts are missing, treat the event as suspicious even if the platform is technically within capacity.
Decision rule: If the compute increase is sustained but the business driver is absent, prioritise containment, image and process review, and billing-impact analysis before you focus on optimization tuning. If the spike is explainable and time-bound, treat it as workload engineering instead of incident response.
What good looks like: The team can tie every material CPU or GPU surge back to a known service, expected time window, and accountable owner. Anything that cannot be explained that way should be investigated as potential abuse, not normalized as “just autoscaling.”
Practitioner takeaway: The most reliable test is attribution, not volume, legitimate spikes have a story, a trigger, and an owner; cryptojacking usually has compute without a credible operational reason.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org