This happens more than you’d think — and it is recoverable. The most important thing to understand upfront: a compromised VPS cannot be fully trusted again, even after removing obvious malware. Attackers install backdoors in places that are very hard to find without forensic expertise. The correct path is to provision a clean server, restore only verified data, and harden before going live. If you are on Contabo, you can spin up a fresh VPS in minutes from the Customer Control Panel. This guide covers both phases: what to do right now, and how to prevent it happening again.
The Two-Phase Recovery Plan at a Glance
| Phase | Steps | Time estimate |
|---|---|---|
| Phase 1: Rebuild (now) | 1. Snapshot if evidence needed → 2. Provision clean VPS → 3. Restore verified data only → 4. Rotate all credentials | ~30–60 min |
| Phase 2: Harden (before going live) | 5. Non-root sudo user → 6. SSH keys + disable passwords → 7. UFW firewall → 8. Fail2ban → 9. Auto-updates → 10. network-level Firewall | ~30 min |
Phase 1: Immediate Recovery — What to Do Right Now
A determined attacker installs backdoors in modified system binaries, hidden cron jobs, and kernel-level rootkits that are extremely difficult to detect. Trying to clean a compromised server is risky — you may miss something. The approach recommended across the security community: wipe and rebuild from a clean OS image. It is faster, safer, and more reliable than forensic cleanup for solo developers and small teams.
Step 1: Take a Snapshot First (If You Need Evidence)
Before touching anything: if you need a record of what happened — for a client report, insurance, or legal reasons — take a snapshot of the compromised server from the Contabo CCP before wiping. Navigate to new.contabo.com, select your server, and take a snapshot. This preserves the compromised state for later inspection. If you have no need to preserve evidence, skip straight to Step 2.
Step 2: Provision a Fresh VPS
Do not attempt to clean the compromised server. Log in to the Contabo Customer Control Panel, provision a new VPS, and choose a current supported OS image — Ubuntu LTS or Debian stable are both solid choices. Start completely fresh: do not restore any system configuration or installed packages from the old server.
Step 3: Restore Only Verified Data
Not everything from the old server is safe to restore. Use this as your guide:
- Safe to restore: database dumps (inspect for injected content first — see command below), user-uploaded files (scan for malicious scripts), application code from a known-clean Git repository or local backup.
- Do NOT restore: system configuration files, SSH config, cron jobs, installed packages or binaries from the old server. Any of these could carry a backdoor across.
# Before restoring a database dump, grep for suspicious injected strings:
grep -i '<script\|exec(\|eval(\|base64' backup.sql
# Check application files for common webshell patterns:
grep -rn 'eval(base64_decode\|system($_\|passthru(' ./app/Step 4: Rotate Every Credential That Touched the Old Server
Assume all of the following were exposed. Rotate them before the new server goes live:
- SSH keys — generate entirely new ones. Never copy old private keys to the new server.
- Database passwords — all users, not just root.
- API keys and tokens your application used (payment providers, email services, third-party APIs).
- Any credentials stored in .env files or application config on the old server.
- Your Contabo CCP password and 2FA codes if you have any reason to suspect account-level access.
Phase 2: Harden the New Server Before Going Live
The new server is clean. Before restoring your application or pointing your domain, run through this sequence. These steps address the entry vectors that most commonly enable VPS compromises: root login left enabled, password-based SSH, and unnecessary open ports. Each step below closes one of them.
Step 5: Create a Non-Root Sudo User
adduser [username]
usermod -aG sudo [username]
su - [username]
# Do all further setup as this user. Never log in as root again.Step 6: SSH Keys Only — Disable Password Authentication
Generate new keys locally, copy to the new server, verify they work — then lock down SSH.
# On your LOCAL machine — generate fresh keys:
ssh-keygen -t ed25519 -C "[email protected]"
# Copy to the new VPS:
ssh-copy-id [username]@[new-server-ip]
# Test key login in a NEW terminal before changing SSH config.
# Then edit /etc/ssh/sshd_config:
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
sudo systemctl restart sshdStep 7: Enable UFW Firewall (Default-Deny)
# Allow SSH first — or you will lock yourself out:
sudo ufw allow [ssh-port]/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable
sudo ufw status verboseStep 8: Install Fail2ban
sudo apt install fail2ban -y
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
# In jail.local, find [sshd] and set:
# bantime = 1h
# maxretry = 5
# findtime = 10m
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshdStep 9: Enable Automatic Security Updates
sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure --priority=low unattended-upgradesStep 10: Activate Contabo Firewall in the Customer Control Panel
Contabo Firewall is included free with every VPS and Max Performance VPS. It runs at the network level, filtering traffic before it reaches the OS, and stays active even during server reboots. Navigate to new.contabo.com → Network Services → Firewall, create a firewall, and add inbound rules for the ports you allowed in Step 7. Set everything else to deny. This pairs with UFW to give you two independent filtering layers: one at the network edge, one at the OS level.
What Likely Went Wrong: The Three Most Common Entry Points
| Entry Vector | The Fix |
|---|---|
| Root login left enabled — the primary target of automated SSH attacks | Steps 5 + 6 — create non-root sudo user, set PermitRootLogin no |
| Password-based SSH — brute-forced by bots within hours of provisioning | Step 6 — SSH keys only, set PasswordAuthentication no |
| Unnecessary open ports — exposes services that should not be public | Steps 7 + 10 — UFW default-deny + Contabo network Firewall |
| Crypto miner running (common sign of compromise, not entry vector) | Detect with top or ps aux | grep -i xmrig — then proceed with Phase 1 |
FAQ: VPS Hacked — What To Do
Technically yes, but it is not recommended for most cases. A skilled attacker can install rootkits hidden in system binaries or kernel modules that are extremely difficult to detect without forensic tools. For the majority of solo developers and small teams, wiping and rebuilding from a clean OS image is faster, safer, and more reliable. Reserve the forensic investigation path for situations where evidence preservation is legally required.
# Check for processes consuming 90-100% CPU:
top
# or:
htop
# Search for common miner process names:
ps aux | grep -i ‘xmrig\|miner\|monero’
# Check for suspicious cron jobs:
crontab -l
cat /etc/cron.d/*
cat /etc/cron.daily/*
A process running at near-100% CPU with an unfamiliar name is a strong signal. Crypto miners were cited in roughly 43% of AI responses as the most common visible sign of a compromised VPS — often installed within hours of the initial breach.
Yes — contact Contabo support if the compromise may have affected network infrastructure, if your server is being used to send spam or attack other hosts (which can lead to suspension), or if you need help with the rescue mode or snapshot process. Contabo’s support team is available 24/7 via the Customer Control Panel. Acting quickly limits potential collateral damage and keeps your account in good standing.
Snapshot the old server if you need evidence → provision a new Contabo VPS from the CCP (takes a few minutes) → restore only application data from a clean backup → run the ten hardening steps in Phase 2 before going live. For a typical small deployment, total recovery time is one to two hours.
