Discovering (or suspecting) your VPS has been compromised is stressful — this guide covers a systematic approach to confirming a compromise and responding effectively.
Common Signs of a Possible Compromise
- Unexpected outbound network connections or unusually high bandwidth usage
- Unfamiliar processes consuming significant CPU (often cryptomining malware)
- New, unfamiliar user accounts or SSH keys
- Modified system files that shouldn't have changed
- Unexpected outbound emails (spam relay abuse)
- Your server flagged by a blacklist or reported by your hosting provider
Step 1 — Don't Panic, But Act Deliberately
Avoid making hasty changes that could destroy evidence needed to understand what happened — take a breath and work through a systematic process rather than randomly deleting things.
Step 2 — Isolate If Actively Exploited
If you suspect active, ongoing exploitation (not just historical evidence), consider disconnecting the server from the network (via your provider's console/firewall) to stop further damage while you investigate — balance this against needing some access to actually investigate.
Step 3 — Check for Unfamiliar Processes
ps aux --sort=-%cpu | head -20Look for unfamiliar process names, especially ones consuming significant CPU (a common sign of cryptomining malware).
Step 4 — Check for Unfamiliar Network Connections
sudo ss -tulnpsudo netstat -tuplnLook for unexpected listening ports or established connections to unfamiliar remote IPs.
Step 5 — Check for Unfamiliar User Accounts and SSH Keys
cat /etc/passwd
cat ~/.ssh/authorized_keys
cat /root/.ssh/authorized_keysStep 6 — Check Auth Logs for Suspicious Activity
See How to Monitor Auth Logs and Detect Intrusion Attempts on a Linux VPS — review for unexpected successful logins, especially from unfamiliar IPs.
Step 7 — Check for Rootkits
See How to Detect and Remove Rootkits on a Linux VPS — run rkhunter/chkrootkit scans as part of your investigation.
Step 8 — Check for Unauthorized Cron Jobs
crontab -l
sudo crontab -l -u root
ls /etc/cron.d/Step 9 — Determine the Likely Entry Point
Review what was recently exposed/changed — an outdated application, a weak password, an unpatched vulnerability — understanding how the attacker got in prevents immediate recurrence after cleanup.
The Honest Recommendation: Rebuild, Don't Just Clean
Once genuinely compromised, you can never be 100% certain every trace of unauthorized access has been removed — the safest approach is rebuilding the server from scratch (fresh OS install, restore application data from a known-good backup predating the compromise) rather than trying to fully clean an actively compromised system.
Step 10 — Rotate All Credentials
Change every password, API key, and SSH key associated with the compromised server, since you can't be certain what was exposed.
Step 11 — Notify Affected Parties If Applicable
If customer/user data may have been exposed, see How to Handle a Data Breach: An Incident Response Framework for the broader notification and legal considerations.
Step 12 — Conduct a Post-Incident Review
See How to Write an Effective Incident Postmortem — understand and document what happened and how to prevent recurrence.
Continue Reading
- How to Detect and Remove Rootkits on a Linux VPS
- How to Monitor Auth Logs and Detect Intrusion Attempts on a Linux VPS
- How to Handle a Data Breach: An Incident Response Framework
Browse more articles in Server Security & Hardening.
