Discovering your VPS has been compromised is stressful, but a methodical response minimizes damage and gets you back to a trustworthy state. This guide covers the recommended incident response process.
Signs of a Compromise
- Unfamiliar processes consuming high CPU (often cryptomining malware)
- Unexpected outbound network connections
- New user accounts you didn't create
- Modified
authorized_keysfiles with unfamiliar keys - Files encrypted with a ransom note
- Your IP appearing on spam blacklists despite no legitimate bulk sending
Step 1 — Isolate the Server Immediately
Disconnect it from production traffic if possible — through your provider's control panel (disable networking, or take it offline) rather than continuing to investigate while it remains actively compromised and potentially causing further damage or spreading.
Step 2 — Do Not Trust the Compromised System's Own Tools
An attacker with root access can modify system binaries (ps, ls, netstat) to hide their presence. Commands run on the compromised system may lie to you.
Step 3 — Preserve Evidence If Investigation Matters
If you need to understand exactly how the compromise happened (for compliance, legal, or learning purposes), take a snapshot/disk image before making any changes, so evidence isn't lost.
Step 4 — The Safest Remediation: Rebuild from a Clean Backup
Rather than attempting to manually clean an actively compromised system (which risks missing a hidden backdoor), the generally recommended approach is:
- Provision a brand-new VPS
- Install and harden the OS from scratch — see How to Harden a Fresh Linux VPS in 15 Minutes
- Restore application data from a backup taken before the compromise occurred, not the most recent one if that's also potentially compromised
- Change all credentials, API keys, and SSH keys used on the old server — assume everything was potentially exposed
Step 5 — Determine How Far Back to Restore From
If you don't know exactly when the compromise occurred, review logs and Fail2Ban/auth history for the earliest signs of suspicious activity — restore from a backup predating that point, not just the most recent backup.
Step 6 — Rotate Every Credential
- SSH keys
- Database passwords
- API keys used by the application
- Any credentials stored in environment variables or config files on the compromised server
Step 7 — Check for Ransomware Specifically
If files are encrypted with a ransom demand:
- Do not pay the ransom — there's no guarantee of receiving a working decryption key, and it funds further criminal activity
- Check whether a decryption tool exists for the specific ransomware variant, through reputable security research organizations
- Restore from backup rather than relying on decryption
Step 8 — Investigate the Root Cause
Before going back into production, understand how the compromise happened to prevent recurrence:
- Weak or reused SSH credentials?
- An outdated, vulnerable application or plugin?
- A misconfigured firewall exposing something that shouldn't have been public?
Step 9 — Apply Additional Hardening Before Returning to Production
Follow the full VPS Security Checklist for Beginners, and consider additional measures (2FA, stricter firewall rules) if the root cause suggests they'd have prevented this specific incident.
Preventing Future Incidents
- Regular security updates — see How to Enable Automatic Security Updates on Ubuntu & Debian
- Regular rootkit/malware scans — see How to Detect and Remove Rootkits on a Linux VPS
- Tested, clean backups predating any potential compromise window
Related Articles
- How to Detect and Remove Rootkits on a Linux VPS
- How to Harden a Fresh Linux VPS in 15 Minutes
- How to Test and Verify Your Backups Actually Work
