Launch offer: 30% off your first year with code LAUNCH30 · first 50 customers Urgent security advisory · PHP CVE-2026-109618 and CVE-2026-109619 (remote code execution) Read more
FounderMode
← Blog · October 29, 2026 · 4 min read
Antivirus & malware
How to detect and remove a cryptominer on a Linux server
FounderMode Security ResearchGUIDE

How to detect and remove a cryptominer on a Linux server

A cryptominer is the most common thing attackers install on a compromised Linux server. It is quiet, it does not encrypt your data, and it earns them money every hour, paid for by your CPU, your cloud bill and your users' slow page loads.

Here is how to confirm it, remove it, and make sure it does not come back.

The typical symptoms

  • CPU usage stuck between 90 and 100%, day and night, with no traffic spike to explain it;
  • the server or the website is suddenly slow;
  • a cloud bill or a "high CPU" alert from your hosting provider;
  • the fan or the load average climbing on a machine that should be idle.

Any one of these is worth checking. Together, they are almost always a miner.

Step 1: Find the process

top -o %CPU
ps aux --sort=-%cpu | head

Miners often use names that look like kernel or system processes: kworkerds, kdevtmpfsi, kthreaddi, [kswapd0], systemd-service. Real kernel threads appear in brackets and use no measurable CPU over time; a "kernel thread" using 300% CPU is not one.

Check where it really runs from:

ls -l /proc/<PID>/exe
ls -l /proc/<PID>/cwd

Paths in /tmp, /var/tmp, /dev/shm, a hidden folder (/root/.x, /var/www/.cache) or a (deleted) marker confirm it.

Step 2: Confirm with the network

Miners connect to a mining pool:

ss -tnp | grep <PID>

Outbound connections to ports such as 3333, 4444, 5555, 7777, 14433 or 14444, or to domains containing "pool", "xmr" or "mine", leave no doubt.

Step 3: Find the persistence before killing anything

If you kill the process first, it will usually restart within a minute. Miners reinstall themselves through:

# cron jobs for all users
for u in $(cut -d: -f1 /etc/passwd); do crontab -l -u "$u" 2>/dev/null | sed "s/^/$u: /"; done
cat /etc/crontab; ls -la /etc/cron.d

# systemd services and timers
systemctl list-units --type=service --state=running
systemctl list-timers --all

# startup scripts and shell profiles
grep -rE "curl|wget|base64" /etc/rc.local /etc/profile.d ~/.bashrc /root/.bashrc 2>/dev/null

# SSH keys added by the attacker
cat /root/.ssh/authorized_keys

Write down everything suspicious: a cron line that downloads a script every few minutes, a service with a random name, an SSH key nobody owns.

Step 4: Remove it in the right order

  1. Block the persistence: remove the cron lines, disable and delete the rogue services (systemctl disable --now name), remove unknown SSH keys.
  2. Kill the process: kill -9 <PID>.
  3. Delete the files: the binary, its configuration and its folder. Some miners set the immutable flag; remove it with chattr -i file before deleting.
  4. Watch for 30 minutes: run top again. If the miner comes back, a persistence mechanism was missed.

Step 5: Find how it got in

Removing the miner without closing the door means seeing it again next week. The usual entry points are:

Entry pointHow to check
Weak or reused SSH passwordgrep "Accepted password" /var/log/auth.log
Exposed Docker API (port 2375)ss -tlnp shows port 2375 open to all
Exposed Redis without a passwordss -tlnp shows port 6379 open to all
Outdated web app or plugincheck versions against known CVEs
Leaked cloud or API credentialsreview your provider's access logs

Fix the cause, then rotate every password and key that was on the server.

When to rebuild instead of clean

Clean the server if you found the miner, its persistence and its entry point, and nothing else looks touched. Rebuild from a clean image if system binaries were modified, a kernel module was loaded, or you cannot explain how the attacker got in. A rebuild is faster than a second incident.

How to catch the next one in minutes, not weeks

Miners are designed to go unnoticed, and many servers run one for months. Three simple signals catch them early:

  • an alert when CPU stays above 80% for more than 15 minutes;
  • an alert on new processes running from /tmp or /dev/shm;
  • an alert on new cron jobs, services or SSH keys.

Frequently asked questions

Is high CPU always a cryptominer?

No. A traffic spike, a stuck job or a runaway query can do the same. The difference: a legitimate process has a known name, a known path and stops when the work is done. A miner runs from a strange location, connects to a pool and never stops.

Can a cryptominer steal my data?

The miner itself only uses your CPU. But the attacker who installed it had access to your server, so assume anything on it, including database passwords and API keys, may have been read.

Why does the miner come back after I delete it?

Because a cron job, a systemd service or a script in a startup file reinstalls it. Remove the persistence first, then the process, then the files.

FounderMode flags abnormal CPU, unknown processes, new cron jobs and new SSH keys on your servers, and sums it all up every day in Slack. Start the free trial.

Protect your server in 2 minutes

Antivirus, intrusions, vulnerable versions and a daily AI report in Slack. 14 days free.

Start the free trial

Read next