They often treat cryptojacking as a nuisance rather than a sign of broader trust abuse. In practice, a mining payload can indicate trojanised software, persistence mechanisms, or control channels that could support more damaging activity. The resource theft is visible, but the underlying execution path is usually the real problem.
Why This Matters for Security Teams
Cryptojacking on endpoints is often dismissed as a performance problem, but that framing misses the security value of the event. High CPU use, battery drain, and fan noise are symptoms; the real issue is unauthorised execution on a managed device, usually with some form of persistence or remote control. That makes cryptojacking a useful indicator of trust failure, not just a nuisance to clean up.
Security teams also get caught out by treating every case as identical. Some incidents begin with a malicious attachment, others with a trojanised installer, a compromised browser extension, or exploitation of an unpatched endpoint. The response should therefore focus on how code was introduced, what it can access, and whether it can survive reboots or laterally move. NIST control baselines such as NIST SP 800-53 Rev 5 Security and Privacy Controls are relevant here because they tie endpoint hardening, logging, and malware response together rather than treating mining as a standalone event.
In practice, many security teams encounter cryptojacking only after users complain about slow devices or degraded productivity, rather than through intentional detection of suspicious execution.
How It Works in Practice
Endpoint cryptojacking usually depends on four elements: initial execution, persistence, outbound communication, and resource consumption. The payload may be a miner binary, a script running through PowerShell or a browser process, or a containerised workload on developer workstations. Once active, it often tries to blend in by using legitimate system tools, scheduled tasks, registry run keys, startup folders, or injected code inside trusted processes.
Detection should therefore combine behavioural and host-level telemetry, not only antivirus signatures. A useful triage model looks at:
- Process lineage: what launched the miner and whether the parent process is expected.
- Persistence artefacts: scheduled tasks, autoruns, services, browser extensions, or launch agents.
- Network patterns: mining pool destinations, unusual DNS activity, or encrypted outbound channels to rare hosts.
- System impact: sustained CPU spikes, thermal throttling, abnormal battery usage, or fan escalation on idle systems.
From a control perspective, teams should pair application allowlisting, script controls, least privilege, and EDR alerting with stronger software supply chain hygiene. If the miner arrived through a signed but trojanised package, the root problem is not just the executable, but the trust decision that allowed it to run. Guidance from CISA’s ransomware and threat mitigation guidance is relevant because the same endpoint-hardening measures that disrupt ransomware also reduce commodity miner abuse. Logging should preserve enough detail to reconstruct first execution and persistence creation, ideally feeding SIEM and SOAR playbooks. These controls tend to break down when endpoints are unmanaged, locally admin-heavy, or allowed broad script execution because the miner can re-establish itself faster than responders can remove it.
Common Variations and Edge Cases
Tighter endpoint control often increases operational friction, requiring organisations to balance containment against developer productivity and user support overhead.
One common edge case is bring-your-own-device or contractor laptops, where the telemetry and enforcement coverage is weaker than on corporate endpoints. Another is high-performance computing or engineering workstations, where legitimate GPU and CPU usage can resemble mining activity and create alert fatigue. Best practice is evolving on how aggressively to block high-resource processes in these environments, so the answer is usually better attribution rather than blanket suppression.
There is also a meaningful distinction between true cryptojacking and “gray” monetisation cases, such as browser-based mining in consumer contexts or unwanted bundled software that never fully persists. For security teams, the important question is whether the activity signals unauthorised code execution and whether the same foothold could support credential theft, remote access, or data exfiltration. Endpoint teams should also watch for identity and privilege abuse around the installation path, because local administrator rights, weak software governance, or abused service accounts can turn a simple miner into a repeatable access vector. In mixed estates, the right decision is often isolate first, then validate provenance and scope before reimaging. Current guidance suggests treating mining on an enterprise endpoint as evidence of deeper compromise until proven otherwise, especially when the process tree, persistence method, or network destinations are unfamiliar.
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 NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM | Endpoint mining is best caught through continuous monitoring of system behaviour. |
| MITRE ATT&CK | T1059 | Script-based execution is a common way miners land and persist on endpoints. |
Monitor endpoint telemetry for abnormal CPU, persistence, and outbound connections.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
