## TL;DR
Crypto miners almost always give themselves away with sustained high CPU on a box that should be quieter, plus a process name that tries to look innocent and outbound connections to mining pools. Start with CPU load, list processes by CPU, then check cron and systemd units for persistence and open connections for pool traffic. If you find one, quarantine the box before you clean it.

```text
how to detect crypto miners on your servers
```

## Use this when
- A server sits at 90-100% CPU and nothing you own should be that busy
- Your cloud bill jumps and the extra spend is all compute
- An alert fires for an unknown binary running as root or as the web user
- You got breached recently and want to check for a miner payload

## Not for
- Removing miners or doing full incident response (this is detection only)
- Detecting miners on other peoples machines (defensive use on your own infra)
- General performance tuning of legit workloads

## Steps
1. Check overall CPU load across the box. On Linux run `uptime` and then `top` (press 1 to see per-core). A healthy app server usually has idle headroom; a miner pegs one or more cores at 100% around the clock, including times of day when your traffic is low.
   Expected output: you see near-100% usage on cores that stay hot even at 3am, and the load average is way above your normal baseline.

2. List processes sorted by CPU to find the culprit. Run `ps aux --sort=-%cpu | head -20`. Miners often hide behind names like `kworker`-lookalikes, random strings, or a copy of a legit tool placed in /tmp or /var/tmp.
   Expected output: one process consuming most of a core. Note its PID, user, and the full command path (check /proc/[pid]/exe if the name looks fake).

3. Look for how it survives reboots. Check `crontab -l` for every user, plus `ls /etc/cron.d/ /etc/cron.daily/` and `systemctl list-timers --all`. Miners commonly add a cron line that re-downloads the binary every few minutes.
   Expected output: a cron entry or timer unit referencing a URL or a binary in a temp directory you did not put there.

4. Check systemd units too. Run `systemctl list-units --type=service --state=running` and eyeball anything you dont recognize, then `systemctl status [unit]` on suspects.
   Expected output: a rogue service with a plausible-sounding name, enabled at boot.

5. Inspect outbound network connections. Run `ss -tupn | less` and look for persistent TCP connections to odd high ports (common pool ports: 3333, 4444, 5555, 7777, 14444). Reverse-resolve the destination IPs.
   Expected output: a steady connection from the suspect process to a host that resolves to a known mining pool domain.

6. Find how it got in. Check `journalctl -u sshd | grep "Failed"` for brute-force noise and `last` for odd logins around the time the process started.
   Expected output: a cluster of failed logins or a login from an IP you dont recognize just before the miner process first appeared.

7. Quarantine before cleanup. Snapshot the disk for forensics, pull the box off the network or put it behind a restrictive security group, then rebuild from a clean image and rotate every credential that box touched.
   Expected output: the miner is gone because the box is fresh, and rotated credentials mean it cant come back the same way.

## Variant phrasings
- "how to find a bitcoin miner running on my linux server"
- "server cpu at 100 percent for no reason, how to check for miner"
- "detect xmrig process on production box"
- "how to tell if my server is part of a mining botnet"

## Edge cases and pitfalls
- Some miners only run at night or when load is low, so check 24-hour CPU graphs in your monitoring, not just right now.
- A miner can inject into a legit process (shared-library hijack), in which case the process name looks real but its network connections dont.
- Cloud metadata endpoint access plus a miner often means stolen IAM credentials; rotate instance roles too.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_zBIWHh2QRTejNTr2Q55E0A