What to Do If Your VPS Has Been Hacked

  • Updated 7 October 2026
  • 11 min read
  • ESAGAMES Team

Finding out that someone else has root on your server is a gut-punch - but panicking makes it worse. This is a calm, practical incident-response plan for a hacked VPS: how to contain the damage, work out what happened, recover cleanly, and make sure it does not happen again.

Quick answer

If your VPS has been hacked, isolate it first (firewall it or take it offline) and keep a snapshot as evidence. Do not trust anything on the system: rebuild it from a clean image, restore data from a backup taken before the breach, change every password and SSH key, and patch whatever let the attacker in.

First: how do you know you are compromised?

Common warning signs of a rooted VPS:

  • Unknown processes eating CPU or bandwidth (often crypto-miners or a botnet agent).
  • Logins, SSH keys or user accounts you did not create.
  • Outbound spam, scanning or attack traffic your host warns you about.
  • Changed passwords, disabled security tools, or files you cannot explain.
  • Your server suddenly part of a DDoS - as a source, not a target.

If you are seeing these, assume the worst and act methodically.

Step 1 - contain, do not destroy

Your instinct may be to wipe everything immediately. Resist it for a moment. First contain the incident so it cannot spread or do more harm, while preserving evidence of what happened:

  • Isolate the server from the network (your host's panel can usually cut networking or firewall it off).
  • Do not reboot yet - useful forensic data lives in memory and running processes.
  • If it holds customer data, treat it as a data breach and note the time you discovered it.

Step 2 - assume total compromise

This is the hardest mindset to accept: once an attacker has root, you can no longer trust anything on that machine. Logs can be edited, system binaries can be swapped for trojaned versions (rootkits), and clean-up tools running on the box can be lied to. You cannot reliably disinfect a rooted server - you can only learn from it and rebuild.

Once someone has had root, the only honest assumption is that nothing on that server can be trusted again.

Step 3 - investigate before you rebuild

Learn how they got in, so you do not just recreate the same hole. Look at:

  • Auth logs for the first unexpected login and its source IP.
  • New users, SSH authorized_keys entries and cron jobs - see diagnosing cron jobs if scheduled tasks look unfamiliar.
  • Recently modified files and unfamiliar listening ports.
  • Whether the way in was a weak SSH password, an exposed service, or an unpatched vulnerability.

Where you can, copy the logs and a disk snapshot off the machine first, so analysis happens on a trusted system.

Step 4 - rotate every credential

Anything that touched that server is now suspect. Change it all: SSH keys, root and user passwords, database credentials, API tokens, and any password that was stored or typed on the box. If the same password was reused elsewhere, change it there too.

Step 5 - rebuild clean

Do not "clean" the old install - rebuild from scratch. Provision a fresh OS, harden it before exposing it, restore only data (never binaries or system files) from a backup taken before the compromise, and patch fully before it goes live.

Step 6 - close the door for good

Whatever let them in, fix it on the new server, then harden properly:

How to explain this if you host other people's data or servers

If the compromised VPS hosted a game server, customer data or anyone else's content, be upfront with the people affected as soon as you have the facts - what happened, what data may have been exposed, and what you are doing about it. A quiet, honest disclosure early costs far less trust than a cover-up that comes out later.

The takeaway

A root compromise is recoverable if you stay calm: contain, investigate, rotate, rebuild clean, and harden. The pain is real - which is exactly why prevention, and good recent backups kept off the server, is worth far more than any cleanup. Managed, well-patched infrastructure removes a lot of this risk in the first place.

Less to worry about

Host on managed, patched, protected infrastructure — fewer doors left open, and backups when you need them.

See VPS hosting

Frequently asked questions

How do I know if my VPS has been hacked?

Warning signs include unknown processes eating CPU or bandwidth, logins or SSH keys you did not create, your server sending spam or attack traffic, disabled security tools, and files you cannot explain. If you see these, assume a compromise and act methodically.

Can I clean a hacked server instead of reinstalling?

No — once an attacker has had root, you cannot trust anything on the machine, because logs and binaries can be altered. The safe path is to contain it, investigate how they got in, rotate every credential, and rebuild from a fresh OS, restoring only data.

What should I do first when my server is hacked?

Contain it before you wipe anything: isolate the server from the network but do not reboot yet, because memory holds forensic clues. Then investigate the entry point, rotate all credentials, and rebuild clean.

How do I stop my server being hacked again?

Rebuild fresh and harden before exposing it: key-only SSH with no root login, a default-deny firewall, only the services you need, automatic security updates, and off-server backups. Managed, patched infrastructure removes much of the risk.

Keep reading

More from the blog, starting with Security.