Cryptomining malware is one of the most common outcomes of a compromised VPS — attackers use hijacked server resources to mine cryptocurrency, often for extended periods before detection. This guide covers identifying and remediating this specific threat.
Signs of a Cryptomining Infection
- Sustained, unexplained high CPU usage, often near 100% continuously
- Unusual process names, frequently with random or disguised names mimicking system processes
- Unfamiliar outbound network connections, often to mining pool servers
- Server running noticeably slower than usual for no apparent application-level reason
- Increased hosting/electricity costs on providers billing by CPU usage
Step 1 — Identify the Suspicious Process
topLook for a process consuming very high, sustained CPU with an unfamiliar or suspicious name.
Step 2 — Investigate the Process Details
ps -p PID -o pid,ppid,cmd,%cpu,user
sudo ls -la /proc/PID/exeCheck the actual binary location and parent process — cryptominers often run from unusual locations like /tmp or hidden directories.
Step 3 — Check Network Connections from the Process
sudo lsof -p PID | grep -i TCPConnections to unfamiliar IPs, especially on non-standard ports, are a strong signal of a mining pool connection.
Step 4 — Do Not Simply Kill the Process and Move On
Killing the process alone doesn't address how it got there — cryptomining malware frequently includes persistence mechanisms (cron jobs, systemd services, SSH key additions) that will simply restart it, or worse, is just one visible symptom of a broader compromise.
Step 5 — Check for Persistence Mechanisms
crontab -l
sudo cat /etc/crontab
ls /etc/cron.d/
systemctl list-units --type=service | grep -v "^UNIT"Look for unfamiliar entries added recently.
Step 6 — Check for Unauthorized SSH Keys
cat ~/.ssh/authorized_keys
sudo cat /root/.ssh/authorized_keysCompare against keys you actually recognize.
Step 7 — Check for New/Unfamiliar User Accounts
cat /etc/passwdStep 8 — Determine the Entry Point
Common entry points for cryptomining malware:
- Weak or reused SSH credentials
- An unpatched vulnerability in a web application or exposed service
- An exposed, unauthenticated Docker daemon or database
- A vulnerable dependency (see How to Audit and Secure Your Application's Dependencies)
Step 9 — Follow Full Incident Response
Given the difficulty of confirming complete removal on an actively compromised system, the recommended approach is a full rebuild — see How to Recover from Ransomware or a Compromised VPS for the complete process, including rotating all credentials.
Step 10 — Verify the Fix Prevents Recurrence
Address the specific entry point identified in Step 8 before returning to production — follow VPS Security Checklist for Beginners as a baseline, plus any specific fix for the identified vulnerability.
Prevention Going Forward
- SSH key authentication only, strong hardening — see SSH Hardening: Change the Port, Disable Root Login & Use SSH Keys
- Regular security updates and dependency audits
- Monitoring for sustained unusual CPU usage — see How to Set Up Effective Server Alerting
- Never expose Docker daemon or databases directly to the public internet
Continue Reading
- How to Recover from Ransomware or a Compromised VPS
- How to Diagnose and Fix High CPU Usage on a VPS
- How to Detect and Remove Rootkits on a Linux VPS
Browse more articles in Advanced Security & Compliance.
