How do attackers use Miner-C?

How attackers abuse Miner-C in practice

Miner-C is used as a cryptomining payload, so the attacker’s objective is simple: convert someone else’s compute into persistent profit. In a real intrusion, the miner is usually not the first action. It arrives after initial access, then tries to stay quiet, consume spare cycles, and avoid drawing attention while it keeps generating coins.

That is why defenders should think about it as both malware and an operational persistence problem. The miner may be dropped manually, delivered by another loader, or hidden inside a broader compromise chain. NHIMG’s Malware Guide is a useful broader reference for understanding how miners fit into common malware tradecraft and how they differ from other payload types.

What the attacker needs for Miner-C to work

Cryptominers need CPU, GPU, memory, and outbound connectivity, so attackers favour hosts that are powerful, exposed, and lightly monitored. A miner often becomes noticeable only after it creates a sustained resource pattern, such as long-running high utilisation, noisy fan activity, sluggish services, or traffic to mining pools that do not belong in the environment.

Attackers also benefit when the host has weak local controls. If they can write to startup locations, create scheduled tasks, register services, or run with elevated permissions, the miner survives reboot and reappears after cleanup attempts. That persistence makes the host look “still infected” even when the visible process was briefly removed.

For a broader view of how attackers chain access, payloads, and persistence after compromise, the State of NHI & AI Agent Breach Report 2026 is relevant because it shows the post-compromise pattern defenders should expect when an attacker has already established a foothold.

How to spot Miner-C before it costs you more

The most reliable clues are behavioural, not just signature-based. Watch for a process that stays active far longer than its business role requires, unexpected spikes in GPU or CPU use on servers that should be idle, and outbound connections to mining infrastructure or unknown pools. Changes to startup artefacts matter just as much, because they often explain why the same workload keeps reappearing after a restart.

It is also worth looking for surrounding compromise indicators that make the miner possible in the first place. If an endpoint suddenly has new administrative activity, unauthorised binaries, or a new service account or scheduled task tied to the miner, the issue is no longer just unwanted compute usage, it is an intrusion that still has a foothold.

Risk and Threat Considerations

Cryptomining abuse is often treated as a low-severity nuisance, but the security impact can be broader. A miner can hide inside a larger intrusion, consume resources that production workloads need, and indicate that an attacker already has execution on the host. If the same compromise also exposed credentials or management access, the mining activity may be only one symptom of a wider breach.

Failure mechanism: The attacker relies on sustained execution, persistence artefacts, and outbound connectivity to keep the miner running while blending into normal system load. If the environment does not distinguish legitimate performance spikes from unauthorised long-lived compute use, the miner can remain active for days or weeks.

Impact: The immediate effect is wasted compute and degraded service performance, but the larger risk is missed containment. A host running Miner-C may also be a staging point for additional malware, credential theft, or lateral movement, so the visible mining process should be treated as an indicator of deeper compromise until proven otherwise.

Practitioner Guidance

What to prioritise: Start with any host showing sustained resource abuse plus unfamiliar outbound traffic. That combination is a better triage signal than CPU usage alone, because legitimate spikes usually do not also talk to a mining pool or create new persistence artefacts.

What to verify: Check whether the miner is user-launched, service-launched, or task-launched, then confirm which account created it and whether that account should have been able to do so. If the process survives reboot, treat that as evidence of persistence, not just a temporary workload anomaly.

Common mistake: Teams often kill the process and stop there. That removes the symptom, not the access path. If the original entry point remains open, or if local admin rights are too broad, the miner or a different payload will usually come back.

Practitioner takeaway: Miner-C should be handled as a compromise signal first and a performance issue second. The key judgement is whether the host is merely busy, or whether an attacker has already converted compute access into persistent control.

Related resources from NHI Mgmt Group

• How do attackers turn a supply-chain incident into wider NHI compromise?
• How do attackers operationalise stolen OAuth tokens at scale?
• Why do attackers often check model availability before trying to generate content?
• How do attackers turn stolen npm secrets into broader compromise?