My VPS was hacked. Recovery, step by step

What this is#

Your VPS is compromised, or you suspect it. This is the recovery procedure: how to confirm it, what to save, why the only reliable way out of a root-level compromise is backing up your data and reinstalling, and how the process works when our monitoring found it before you did.

How compromises announce themselves#

• CPU pinned at 100% around the clock, a cryptominer, the most common payload (the slow-VPS guide covers spotting it).
• Outbound spam, our monitors block SMTP automatically on mass-mail emission, and blocklists start listing your IP.
• A suspension notice from us, our monitoring detected the VPS attacking others or running malware (the process for that is at the bottom).
• Defaced pages, files you didn't change, users you didn't create, an authorized_keys entry you didn't add, processes with random names, or traffic spikes on your Graphs.
• Browsers showing a red "Dangerous site" warning on your website, Google Safe Browsing usually notices injected content before the owner does.

First moves: contain, don't destroy#

1. Secure your VPSDime account first: change its password. Every account already has 2FA on by default (email login codes); if you're on the default, consider switching to an authenticator app, which keeps the second factor working even if your mailbox is part of the breach. An attacker holding your panel access outranks anything you do on the server.
2. Change the root password and remove unknown SSH keys (~/.ssh/authorized_keys for root and every user), attackers plant keys precisely so password changes don't evict them.
3. Don't start deleting things. You'll want the evidence intact for the next step, and half-cleaning a box creates false confidence (see below for why).

Find the door they came through#

This is the step that keeps it from happening again next week. Look for the entry point:

• Web applications first, outdated CMS/plugin/panel versions and upload forms are the majority of real-world entries. Check the web server's access logs around the time trouble started, and look for web shells in upload/cache directories (PHP files where only images should live).
• Login history: last and lastb (successful and failed logins, with source IPs).
• Scheduled persistence: crontab -l for every user, /etc/cron.*, and systemctl list-timers.
• New accounts in /etc/passwd, unfamiliar systemd units in /etc/systemd/system/.

Whatever you find, the lesson feeds the rebuild: the hole gets patched before the site goes back up.

Why you can't just clean it: modern bots don't lose gracefully#

Today's compromises aren't a script you delete. Automated attack kits are built to survive removal, and on a root-level compromise you should assume all of the following, because current bots do all of it:

• They replace system binaries. ps, ls, netstat, ss, even sshd get swapped for trojaned versions that hide the malware and backdoor your logins, so the very tools you'd use to inspect the box lie to you.
• They persist in many places at once: cron entries for several users, systemd units and timers, ld.so.preload hooks that inject into every process, shell profile hooks (.bashrc), PAM backdoors, planted SSH keys, and web shells as a re-entry hatch. Finding four of five means the fifth reinfects you.
• They respawn each other. Watchdog processes run in pairs and restart whichever one you kill; downloader components re-fetch the payload from the internet minutes after you remove it.
• They defend their turf: immutable file attributes (chattr +i), renamed copies of themselves, and sometimes they even patch the vulnerability they used, so other bots can't take their box.

The practical consequence: with a rooted server, in-place cleanup is a game you lose slowly while believing you're winning. If root was compromised, the routine is: back up your data, reinstall, restore. It's faster than the cleanup attempt, and it's the only version with a trustworthy ending.

The backup-and-reinstall routine#

1. Inventory what must survive: databases, uploaded files, and configs (as reference). Code redeploys from your git repository, never copy executables or scripts off the tainted disk, data only.
2. Prefer a backup from before the compromise. Check when it started (logs, Graphs) and note that Nightly Backups keeps three nights, if the breach is older, those images contain the malware too. Your own off-site backups with longer retention are exactly what pays off here. No clean backup? Take fresh data-only dumps off the compromised box (database dumps, uploads) and inspect uploads for planted files.
3. Reinstall the OS, the clean slate.
4. Patch the entry point before restoring anything: updated CMS/plugins, the hardening basics (keys, no password auth), and no services exposed that don't need to be.
5. Redeploy code from source (git, official packages), restore your data, and bring the site up.
6. Rotate every credential that ever lived on that server: database passwords, API keys, everything in .env files, SMTP credentials, application admin accounts, and the one everyone misses, TLS private keys, the attacker had read access to yours, so reissue the certificate (Let's Encrypt makes that free and instant).

Aftermath#

• If the box sent spam, check the blocklists and start delisting, and note the blacklist charge exists precisely because this cleanup lands on you.
• Put monitoring on the fresh install, a miner-shaped CPU graph on day one of a reinfection is how you win the rematch quickly.
• Schedule the backup routine you wished you'd had this morning.

If our monitors found it first: the suspension process#

When our monitoring detects a compromised VPS, attacking other machines, mining, mass-mailing, hosting malware, our staff verifies the detection and then suspends the VPS. That's deliberate and immediate: it stops further damage both to your server and to other computers on the internet, and it protects the network every other customer shares.

From there, the path back is cooperative:

• Contact us when you're ready to handle the cleanup or, for root-level compromises, the backup-and-reinstall routine above, and we'll coordinate access so you can do it.
• Following through is required, not optional. We can't allow malicious software to run on our network, so the service stays suspended until the compromise is actually dealt with, a rebuilt, patched server gets you back online; ignoring it doesn't.

The service is self-managed, so the hands-on work is yours, but we'll point you in the right direction throughout, and this page is most of the map.

Still need help?#

You can open a support ticket. So we can help on the first reply, it's worth mentioning:

• the VPS hostname or IP,
• what you found (miner, spam, defacement) and roughly when it started,
• whether you have a clean backup, and where you are in the backup-and-reinstall routine.

Related questions#

• "My VPS was hacked, what do I do first?"
• "Can I just remove the malware instead of reinstalling?"
• "Why does the miner keep coming back after I kill it?"
• "My VPS was suspended for a compromise, how do I get it back?"
• "What do I need to change after my server was breached?"
• "Are my backups safe to restore after a hack?"