What should organisations do when cryptomining malware is discovered on an endpoint?

When cryptomining malware is discovered, isolate the affected device, remove the malicious payload and any related downloader or persistence mechanism, and review how the infection entered the environment. Then validate browser controls, email filtering, endpoint protection, and patching. Because miners often arrive through phishing or compromised websites, teams should close the initial access path, not just clean the device.

What first response makes sense when a miner is found on a device?

The right first move is containment, not analysis. A cryptominer is still malware, so the endpoint should be isolated quickly to stop compute theft, reduce the chance of lateral movement, and prevent any downloader or persistence component from staying active while you investigate. After containment, treat the host like an infection source and work outward from there.

That sequence matters because miners are often part of a larger compromise chain. The visible process may be only the payload that burns CPU, while the real security issue is the access path that let it in and the additional tools or scripts that may have been dropped alongside it.

Containment also preserves evidence. If the machine is left online while teams try to clean it, the attacker may retain access, the miner may respawn from a scheduled task or service, and logs may be overwritten before the entry point is understood.

What should be removed and validated after isolation?

Removal should cover the full infection chain, not just the mining binary. In practice that means deleting the malicious executable, any downloader, persistence mechanism, and related scheduled jobs, services, registry entries, browser extensions, startup items, or scripts that help it return after reboot. Then confirm the endpoint no longer contacts the infrastructure used by the miner.

Once the host is clean, validate the surrounding controls that should have stopped or limited the infection. Browser hardening, email filtering, endpoint protection, and patching all deserve review because cryptominers commonly enter through phishing, malicious downloads, drive-by websites, or exploitation of unpatched software. If the control failed once, assume the same path may exist elsewhere.

This is also the point to decide whether reimaging is safer than manual cleanup. If the machine was heavily modified, if multiple persistence methods were present, or if you cannot be confident that every artefact has been removed, rebuilding the endpoint is usually the lower-risk option.

Why does the initial access path matter more than the miner itself?

The miner is the symptom, not always the root problem. A machine can mine cryptocurrency and still be a sign of broader compromise, including stolen credentials, additional malware stages, or access ready for reuse. If teams only remove the process and ignore how it arrived, the same weakness can be exploited again within days.

The most useful investigation questions are simple: what user action or vulnerability opened the door, what executed the payload, and what control should have interrupted that chain? Reviewing browser downloads, email-delivered attachments, macro use, exploit alerts, and proxy or DNS logs usually gives a better answer than focusing on the miner string itself.

At the environment level, this is a test of whether basic defensive layers are actually working together. A single missed patch, a permissive browser policy, or weak attachment filtering can be enough to turn a commodity miner into a repeat incident across multiple endpoints.

Risk and Threat Considerations

Cryptomining malware is usually low-friction for attackers, but it is not low-impact for defenders. The main risk is that the visible resource drain distracts from the fact that the endpoint has already been compromised, which can leave persistence, credential theft, or additional tooling in place after the miner is removed.

Failure mechanism: Attackers commonly use phishing, compromised websites, unpatched software, or bundled downloaders to gain execution, then add persistence so the miner returns after reboot or cleanup. If only the active process is removed, the infection can reappear and the original access path remains open.

Impact: Unchecked miners consume CPU, degrade user productivity, increase support load, and can indicate a broader compromise that threatens other hosts, data, or credentials. On shared or high-value endpoints, the operational cost can quickly exceed the value of the endpoint itself.

Standards & Framework Alignment

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

CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-10 — Malware Defenses	Cryptominers are malware and require containment plus defensive control review.
	CIS-7 — Continuous Vulnerability Management	Miner infections often exploit unpatched software or exposed services.
	CIS-9 — Email and Web Browser Protections	Phishing and compromised websites are common miner entry paths.
Recommendation — Strengthen malware defenses and verify they block known miner delivery and execution paths. Prioritize patching and vulnerability remediation on the affected endpoint and adjacent systems. Harden browser and email controls to reduce malicious download and drive-by infection risk.
NIST CSF 2.0	DE.CM-01 — Networks and networks services are monitored to find potential cybersecurity events	Detecting miner traffic and re-infection attempts depends on monitoring endpoints and network activity.
	RS.MA-01 — Response plan is executed during or after an incident	Isolation and cleanup are incident-response actions for discovered malware.
Recommendation — Monitor endpoint and network telemetry for miner behaviour and recurrence after cleanup. Execute containment and eradication steps under the incident response plan.

Practitioner Guidance

What to prioritise: Treat isolation and root-cause review as a single response, not two separate tasks. If the host cannot be trusted, do not let users continue working on it while remediation is still in progress.

What to verify: Confirm the miner, downloader, and persistence layers are all gone, then check for any other suspicious processes, scheduled tasks, services, or startup artefacts that would let the malware survive a reboot. Also verify that the original entry point is addressed across similar endpoints.

Decision rule: If you cannot clearly prove the infection was limited to one process on one device, escalate to a broader hunt and consider reimaging the endpoint rather than spending time on partial cleanup.

Practitioner takeaway: The useful question is not whether the miner is still running, but whether the environment that allowed it to run has been closed well enough to prevent the next compromise.