What to Do If Someone Gets Root Access to Your VPS

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.

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:

• Key-only SSH, no root login, brute-force protection - see how to harden SSH.
• A locked-down firewall and only the services you actually need - see setting up a firewall with ufw.
• Automatic security updates and a real patch routine.
• The full list in how to secure a Linux VPS.

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.