If you suspect your VPS has been hacked, the first thing to do is isolate it from the internet immediately and do not reboot it — rebooting destroys critical evidence in RAM that you'll need to understand how they got in and prevent it from happening again.
This guide walks you through every stage of incident response: from the moment you detect the problem to returning your server to production with hardened security.
Signs Your VPS May Be Compromised
Before panicking, confirm there's actually a breach. The most common indicators are:
- CPU or RAM spiking for no apparent reason (cryptocurrency mining is the most frequent culprit).
- Unusual outbound traffic during low-activity hours.
- Unknown users or processes in
w,who, orps aux. - Recently modified files in web directories (
find /var/www -newer /etc/passwd -type f). - Provider alerts about outbound spam or abusive traffic.
- SSH passwords that no longer work.
If you find two or more of these indicators simultaneously, treat the server as compromised and act immediately.
Step 1 — Isolate the Server Without Powering It Off
The goal is to cut the attacker's access without destroying the forensic evidence that lives in RAM and log files.
From your VPS provider's panel, activate emergency firewall rules blocking all inbound and outbound traffic except your own IP. Equivalent alternatives:
- Block everything with
iptables -I INPUT 1 -j DROP; iptables -I OUTPUT 1 -j DROPexcept your active SSH connection. - Switch the server to private network mode from the provider's panel (available on most cloud platforms).
Do NOT do this:
- Don't reboot the server — you'll lose in-memory processes that reveal the attack.
- Don't delete suspicious files yet — they're evidence.
- Don't change passwords from the compromised server — the attacker's keylogger would capture them.
Step 2 — Collect Forensic Evidence
With the server isolated but running, document the current state. Save all output to a file on your local machine — not on the compromised server.
# Active processes
ps auxf > processes.txt
# Open network connections
ss -tulpn > connections.txt
# Active user sessions
w > sessions.txt
# Cron jobs for all users
for u in $(cut -f1 -d: /etc/passwd); do crontab -u $u -l 2>/dev/null; done > crontabs.txt
# Files modified in the last 24 hours
find / -not -path /proc -not -path /sys -newer /proc/1 -type f 2>/dev/null > modified.txt
# Authentication logs
cp /var/log/auth.log auth.log
cp /var/log/secure secure.log
This data lets you identify the entry vector and understand the scope of the damage.
Step 3 — Identify the Attack Vector
Knowing how they got in is essential to avoid repeating the same mistake on the clean server. The most common vectors on VPS instances are:
| Vector | How to detect it |
|---|---|
| Weak SSH password (brute force) | Thousands of failed attempts in auth.log followed by a successful login |
| Outdated plugin or CMS | PHP web shells in uploads or plugin directories |
| Compromised SSH key | Successful login from unknown IP using a public key |
| Unpatched server software | Exploit against a vulnerable version of Apache/Nginx/PHP visible in logs |
| Exposed database credentials | MySQL access from external IPs in the general MySQL log |
Search specifically for web shells with grep -r "eval(base64" /var/www and grep -r "system($_" /var/www.
Step 4 — Critical Decision: Clean or Rebuild?
In most cases, the right answer is to rebuild from a clean image, not to clean the compromised server. The reasons are technical:
- A skilled attacker installs rootkits that hide processes and files — you can never be certain you've removed everything.
- Backdoors can live in unexpected places:
cron, kernel modules,.bashrc, init scripts. - Cleaning takes longer than rebuilding if your data is in backups.
When to clean instead of rebuild: if the attack was shallow (a web shell in a plugin), is clearly contained, and you're certain of its scope. Even then, validate with a scanner like ClamAV or rkhunter before declaring the server clean.
If you don't have recent backups, consult elenlace.com about recovery options before making irreversible decisions.
Step 5 — Rebuild and Harden Security
Once you have a clean OS image and have restored your data from the last verified backup, apply these measures before returning the server to production:
SSH
- Disable password authentication:
PasswordAuthentication noinsshd_config. - Change the SSH port from 22 to a non-standard one (reduces bot noise, not a real security measure on its own).
- Generate a new SSH key pair — the previous ones may be compromised.
- Enable
fail2banwith a 5-attempt threshold and a 1-hour ban.
Firewall
- Default DROP policy on INPUT; open only the ports you need.
- Restrict SSH connections to known IP ranges when possible.
Updates
- Update the entire OS before installing anything else.
- Enable automatic security updates (
unattended-upgradeson Debian/Ubuntu,dnf-automaticon RHEL). - Update all CMS platforms, plugins, and application dependencies.
Post-Recovery Monitoring
Install a file integrity monitor like AIDE or Tripwire to detect unauthorized changes in the future. Find more security resources in our VPS servers section.
Key Takeaways
- Isolate the server immediately but don't reboot it — RAM holds vital forensic evidence.
- Document everything before changing anything: processes, connections, recent files, logs.
- Identify the entry vector before rebuilding to avoid repeating the same mistake.
- In most cases, rebuilding from a clean image is safer and faster than cleaning.
- Harden SSH, firewall, and automatic updates before returning to production.
- Regular backups are the difference between hours of recovery and days of data loss.
Was your server compromised and you don't know where to start? The team at elenlace.com offers incident response assistance — reach out and we'll help you regain control.
FAQ
Do I need to notify my users if my VPS was hacked?
If the server stored users' personal data (names, emails, passwords, payment data), yes. Depending on your jurisdiction, data breach notification laws may require you to inform affected users promptly. Consult a legal professional if you're unsure about the specific obligations that apply to you.
How long does VPS recovery take after a breach?
With recent backups and an OS image available, 2–6 hours for a typical server. Without backups, the process can take days and some data may not be fully recoverable.
Is it worth installing antivirus on the clean VPS?
ClamAV is useful on web servers for scanning user-uploaded files. However, it doesn't replace structural measures: key-based SSH, restrictive firewall, automatic updates, and file integrity monitoring.
Can my VPS provider help if I've been hacked?
Most providers can offer an out-of-band console (KVM/IPMI access) when SSH is unresponsive, and some have automatic snapshots you can restore from. However, forensic investigation and security hardening remain the VPS administrator's responsibility.
Further reading
Other providers and guides worth comparing:
