Crypto Mining Response Quickstart
Time-boxed response path for unauthorized cryptocurrency mining. Treats the miner as a foothold signal, not a resource-theft event. Focuses on identifying miner family, closing the entry vector, and confirming whether secondary attacker tooling is also present.
First 15 Minutes
Validate Mining Activity
CriticalConfirm the alert is genuine mining: sustained off-hours CPU/GPU load, connection to stratum ports (3333, 4444, 14444), DNS to known mining-pool domains (pool.supportxmr.com, xmr.minergate.com, many others). Mining CPU bursts look like legitimate workloads if you only look at CPU graphs; confirm with process name, command-line, and outbound stratum connection together.
Identify Miner Family and Wallet
CriticalIdentify the miner binary (XMRig is the most common; CoinMiner, LemonDuck, PGMiner, Sysrv-hello, Kinsing, H2Miner are also frequent). Extract the wallet address and pool URL from the config or command line. Wallet addresses pivot to campaign-level IoCs and can link this incident to others across months.
Preserve Evidence Before Killing
CriticalBefore killing the miner, copy the binary, its config file, cron entries or scheduled task definitions, and any dropped scripts to an evidence store (with hashes). Process kill destroys volatile state; preserve first. For containerized workloads, preserve the container filesystem and the image digest.
First 60 Minutes
Kill Miner and Remove Persistence
CriticalKill the mining process and its parent/worker tree. Remove persistence: cron entries, systemd units, /etc/rc.local modifications, Windows scheduled tasks, services, Run keys. Miner families like Kinsing and Sysrv-hello install multiple persistence mechanisms; remove, confirm no re-spawn after 1-4 hours, then sweep again.
Block Mining Pool Infrastructure
CriticalBlock known mining-pool domains and stratum ports (3333, 4444, 7777, 14444) at firewall, DNS, and proxy layers. Add hashes and pool domains to EDR custom IoC feeds and subscribe to community mining-pool blocklists (e.g., no-coin) for broader coverage.
Identify the Entry Vector
CriticalDetermine how the attacker got in: exposed Docker socket (2375/2376), exposed Redis with no auth, Jenkins with unauthenticated job submission, exploitable web CVE (Log4Shell, Confluence, Spring), SSH with default/stolen credentials. If CVE-based, determine whether the patch is applied environment-wide or only on the detected host.
First 4 Hours
Hunt for Co-Installed Tooling
CriticalMining is frequently the tail end of an access sale. Hunt for other attacker tooling: scanners (masscan, zmap, nmap), credential dumpers (Mimikatz or equivalent), webshells in web-server roots, reverse shells in /tmp or /dev/shm, SSH propagation scripts. Check for new binaries created during the compromise window. Do not close the incident until secondary tooling is positively ruled out.
Close Entry Vector Environment-Wide
CriticalPatch the exploitable CVE, restrict exposed management endpoints (Docker socket, Redis, Jenkins, Kubernetes API) to internal networks only, rotate credentials that were brute-forced or exposed. Ensure the fix is applied environment-wide, not only on the detected host -- miners re-appear within hours on environments where the vector is not closed broadly.
Credential and IAM Review
For cloud-resident miners, review IAM role usage and API activity during the compromise window; miners in cloud often leverage over-permissioned long-lived credentials. Rotate any credentials that may have been exposed or that show unusual activity. Document over-permissions for follow-up hardening.
Verification and 72-Hour Monitoring
After containment, verify no miner re-appearance on the detected host and adjacent hosts over 72 hours. Add detection rules for the miner family and the entry vector. Cloud billing review during the compromise window can surface unexpected charges that may be recoverable from the provider.
DFIR Assist — Crypto Mining Response Quickstart Quickstart | Printed 4/19/2026