Detect Miner-C by identifying unauthorised cryptomining indicators such as sustained high CPU or GPU use, unusual outbound mining traffic, and processes launched from unexpected paths. Inspect for persistence, altered scheduled jobs, and downloaded miners or scripts. The fastest clue is often resource exhaustion on systems that should have predictable workload patterns.
How Miner-C detection usually starts
Miner-C is best detected by looking for behaviour that does not fit the host’s normal role. In practice, that means sustained compute spikes, unusual GPU use, mining pool connections, and processes that appear from odd directories or temporary locations. The signal is strongest when resource use changes without a matching business workload or maintenance window.
A useful way to think about detection is to separate load from legitimacy. Cryptomining is noisy, persistent, and economically motivated, so it often leaves a trail in process trees, network destinations, and job scheduling rather than trying to hide perfectly. That gives analysts several places to confirm the same activity pattern.
What artefacts point to Miner-C on an endpoint or server?
Start with process and file evidence. Suspicious miners are often launched through scripts, renamed binaries, or living-off-the-land execution from paths that are not part of normal software deployment. Check whether the process lineage makes sense, whether command-line arguments point to wallet or pool configuration, and whether the binary sits in user-writable or recently created locations.
Then look for persistence and re-execution. Cryptominers commonly survive reboots through scheduled tasks, startup entries, cron jobs, service changes, or altered shell profiles. If a host keeps returning to the same high-usage pattern after restart, the persistence mechanism is usually as important as the miner itself.
Network telemetry can confirm the picture. Unusual outbound connections to mining pools, Stratum-like traffic patterns, or long-lived connections to unfamiliar external hosts are strong indicators when they align with local compute abuse. A host that should be idle or lightly loaded but is repeatedly generating regular outbound traffic deserves immediate triage.
How to separate cryptomining from normal high-CPU activity
Context is critical. Batch jobs, builds, analytics pipelines, media processing, and scientific workloads can also produce high utilisation, so the question is not simply whether CPU is high, but whether the timing, duration, destination traffic, and process ancestry match expected operations. The most reliable detections combine host telemetry with workload knowledge from the owning team.
When possible, compare against baselines for the same asset class. A database server, VDI pool, and developer workstation should not all present the same performance profile, and a miner often stands out by flattening the normal pattern into a sustained, flat load. On shared systems, watch for one user context or container that consumes a disproportionate share of resources without an approved reason.
For broader malware context and family-level hunting patterns, Malware Guide is useful because it covers loaders, cryptominers, evasion techniques, and detection methods that help explain how a miner lands and persists.
Risk and Threat Considerations
Cryptomining is not only a performance problem, it is often an intrusion indicator. The same foothold used to deploy a miner can expose credentials, scripts, scheduled tasks, or remote execution paths that may support further abuse. A miner that persists across restarts may also indicate that the attacker has enough access to survive routine cleanup.
Failure mechanism: Attackers abuse execution paths, persistence mechanisms, and outbound connectivity to keep the miner running while blending it into ordinary host activity. If defenders only look for known miner binaries and miss the process lineage or scheduled execution, the compromise can remain active long after the original payload is removed.
Impact: The immediate impact is resource exhaustion, degraded service performance, and higher cloud or power cost. The wider impact is that the same access path may be reused for additional malware, lateral movement, or renewed monetisation if the underlying compromise is not closed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1496 — Resource Hijacking | Miner-C is a classic resource hijacking pattern that burns CPU or GPU for attacker gain. |
| Recommendation — Map mining telemetry to resource hijacking and hunt for persistence, execution, and network indicators. | ||
| CIS Controls v8 | CIS-10 — Malware Defenses | Cryptominers are malware, and this question is about detecting and containing them. |
| Recommendation — Use malware defenses to detect suspicious execution, persistence, and unauthorized binaries. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks and network services are monitored to find anomalies, indicators of compromise, and other potentially adverse events | Miner-C detection depends on spotting anomalous traffic and host behaviour through continuous monitoring. |
| DE.CM-07 — Monitoring for unauthorized personnel, connections, devices, software, and services is performed | Miner-C often appears as unauthorized software or services running on a system. | |
| DE.CM-09 — Computing hardware, software, and firmware are monitored to find anomalies, indicators of compromise, and other potentially adverse events | The question centers on anomalous compute consumption and suspicious miner artefacts on endpoints or servers. | |
| Recommendation — Monitor host and network telemetry for sustained abnormal compute use and suspicious outbound connections. Detect unauthorized miners by monitoring for unexpected software, services, and processes. Correlate abnormal CPU or GPU use with process, file, and persistence anomalies. | ||
Practitioner Guidance
What to verify: Confirm whether the affected host should ever show sustained compute saturation, then check process ancestry, scheduled execution, and outbound destinations before treating the alert as routine load. If the pattern is persistent, assume a real compromise until proven otherwise.
Decision rule: If the process runs from an unexpected path, reconnects after reboot, or talks to mining infrastructure, prioritise containment and artefact preservation over tuning the alert. If the workload is legitimate, document the approved job pattern so future detections can use it as a baseline.
Practitioner takeaway: Miner-C detection works best when teams correlate host resource abuse with execution, persistence, and network evidence, because the miner is usually only the visible part of a broader compromise.
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 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org