What to do if your VPS is hacked

A calm, step-by-step guide for a stressful day.

Your server is using all its CPU for no reason, your provider has sent an abuse notice, or you found a user account you never created. It may have been hacked. This guide walks you through what to do, in order: confirm it, contain it, keep evidence, change your passwords and keys, copy your data off, find out how the attacker got in, and rebuild on a clean server.

The honest summary: once a server has been broken into, you cannot fully trust it again. Deleting the strange program is rarely enough, because attackers often leave other ways back in. The safe ending is almost always a fresh install with your data restored carefully. This guide assumes a Linux VPS running Ubuntu or Debian. If the server holds other people's personal data or payment details, also get professional and legal advice.

What is in this guide

• Signs your server may be hacked
• A few words you will see
• What not to do
• Before you start
• 1. Confirm what is happening
• 2. Contain it
• 3. Save evidence
• 4. Change passwords and keys from a clean device
• 5. Copy your data off
• 6. Work out how they got in
• 7. Rebuild on a clean install
• 8. Restore your data carefully
• 9. Tell the people who need to know
• 10. Watch closely afterwards
• Quick reference
• How most break-ins happen, and how to prevent them
• Limits
• When to step up

Signs your server may be hacked

None of these prove a break-in on their own. Some have innocent causes. Two or more together are a strong warning.

• An abuse, spam or security notice from RackNerd or another network.
• CPU near 100 percent from a program you do not recognise, often with a random-looking name. Cryptocurrency miners are common.
• Bandwidth use far higher than normal.
• User accounts, SSH keys or scheduled jobs you did not create.
• Your website redirects visitors to spam or shows content you did not add.
• New PHP files in upload folders, or core files changed.
• Your password or SSH key stops working.
• Your domain or IP address appears on spam blocklists.

A few words you will see

Term	What it means
Compromised	Someone else has gained control of all or part of the server.
Persistence	The ways an attacker keeps access, such as a hidden user, key or scheduled job.
Backdoor	A hidden way in, often a small script left in a website's files.
Rootkit	Malware that hides itself, and can make normal commands lie about what is running.
Containment	Stopping the damage from spreading while you work.
Rotate	Replace a password, key or token with a new one and cancel the old one.
Indicator	A clue of a break-in, such as a strange file name or an unknown IP address in the logs.

What not to do

• Do not reinstall in the first five minutes. You lose the evidence that tells you how they got in, and without that, the same hole will be open on the new install.
• Do not just delete the obvious program and carry on. It usually comes back.
• Do not log in to other accounts from the hacked server, or type new passwords into it. Assume anything typed there can be seen.
• Do not restore your old backup without checking it. The break-in may be older than you think, and the backup may contain the backdoor.
• Do not ignore your provider's notice. Reply and say what you are doing. A quick, honest reply usually helps.
• Do not "hack back" or attack the addresses you find in the logs. Report them instead.

Before you start

• A clean device for passwords and accounts: your own computer or phone, not the server.
• Your RackNerd client area login and the VPS control panel login.
• A notepad, paper or a file on your own computer, to write down times and what you find. You will want this timeline later.
• Time. Rushing causes most of the mistakes above.

1. Confirm what is happening

Log in and look, without changing anything yet. These commands show what is running, who is connected and what has changed. If you have no SSH access, use the console in the VPS control panel.

What is using the CPU and memory:

ps aux --sort=-%cpu | head -n 20

To see which programs started which, run ps auxf as well. It shows processes as a tree, which helps spot something hiding under a normal-looking parent.

Network connections, and which programs own them:

sudo ss -tunap

Recent logins:

last -n 20
sudo journalctl -u ssh --since "7 days ago" | grep -i "accepted"

On some systems the SSH service is called sshd instead of ssh, and older systems also keep logins in /var/log/auth.log.

User accounts that can log in, and SSH keys:

awk -F: '$3 >= 1000 || $3 == 0 {print $1, $3, $7}' /etc/passwd
sudo cat /root/.ssh/authorized_keys
cat ~/.ssh/authorized_keys

Scheduled jobs and services that start automatically:

sudo ls -la /etc/cron.d /var/spool/cron/crontabs
sudo crontab -l
systemctl list-timers
systemctl list-unit-files --state=enabled

Files changed in the last week in system and web folders, and anything in the temporary folders:

sudo find /etc /usr/bin /usr/sbin /usr/local -type f -mtime -7
sudo find /var/www /home -name "*.php" -mtime -7
ls -la /tmp /var/tmp /dev/shm

Change /var/www to wherever your sites live. Write down anything unexpected: names, paths, IP addresses and times.

One warning. A skilled attacker can make these commands lie, by replacing them or hiding processes with a rootkit. If you find nothing but the signs are strong, such as an abuse notice about traffic from your server, treat it as hacked anyway.

2. Contain it

How you contain it depends on whether your server is harming others.

Situation	What to do
Your server is attacking others, sending spam or the provider has asked you to stop it	Shut it down now from the control panel. Stopping the harm matters more than evidence. Reply to the notice.
It is mining, or you are unsure, and it is not harming others	Lock down access, as below, then carry on with steps 3 to 5 before shutting it down.
Your provider has already suspended it	Contact support. Ask for temporary access to copy data off, and explain your plan to rebuild.

To lock down access, allow SSH only from your own IP address and close everything else. Keep your current session open while you do this, and have the control panel console ready in case you lock yourself out:

sudo ufw default deny incoming
sudo ufw allow from YOUR_IP to any port 22 proto tcp
sudo ufw enable
sudo ufw status

Replace YOUR_IP with your own public IP address. This takes your website offline, which is usually right while you investigate. An attacker with full control can undo firewall changes, so treat this as a short-term measure.

If the server runs Docker, be aware that published container ports can bypass UFW rules. Stop the containers with docker stop rather than relying on the firewall.

3. Save evidence

Before anything is wiped, save the clues. You need them to find the way in, and you may need them for your provider, your users or the authorities.

sudo mkdir -p /root/evidence
ps auxf | sudo tee /root/evidence/processes.txt > /dev/null
sudo ss -tunap | sudo tee /root/evidence/connections.txt > /dev/null
last | sudo tee /root/evidence/logins.txt > /dev/null
sudo journalctl --since "30 days ago" | sudo tee /root/evidence/journal.txt > /dev/null
sudo tar czf /root/evidence.tar.gz /root/evidence /var/log /etc/passwd /etc/group /etc/cron.d /var/spool/cron /root/.ssh /home/*/.ssh

If tar warns that a path does not exist, such as /var/spool/cron on some systems, that is fine. It still saves everything else. The archive is in root's folder, so move a copy to your own user before downloading it:

sudo cp /root/evidence.tar.gz ~/
sudo chown "$USER" ~/evidence.tar.gz

Then copy it to your own computer with scp, run from your computer. Store it as data: do not open or run any scripts inside it. If your site's web logs are somewhere else, such as /var/log/apache2 or /var/log/nginx, the archive already includes them. If your app keeps its own logs, add them.

Keep your notes from step 1 with it. A timeline of what you saw and when is often the most useful evidence of all.

4. Change passwords and keys from a clean device

Assume every password, key and token that was on the server, or typed into it, is now known to the attacker. From your own computer, not the server, change:

• Your RackNerd client area password, and turn on two-factor login if offered.
• The VPS control panel password.
• Your SSH keys. Create a new key pair on your computer. You will use it on the rebuilt server. Remove the old public key from anywhere else you used it.
• Database passwords for every app.
• API keys and tokens in env files and config files, such as payment, email, cloud storage and AI services. Revoke the old ones in each service's dashboard and create new ones.
• Admin logins for your website or apps.
• Your email and domain registrar, if their passwords were ever stored on or typed into the server. Whoever controls your domain controls your site.
• Anything that reused one of these passwords. Change it everywhere it was used.

Do the email and registrar accounts first if there is any chance they were affected. They are the keys to resetting everything else.

5. Copy your data off

Copy off what you cannot recreate: databases, uploaded files and your own content. Do not copy programs, scripts or the operating system. You will reinstall those from clean sources.

Export databases rather than copying their files. For MySQL or MariaDB:

sudo mysqldump --single-transaction --databases mysite > ~/mysite.sql

Replace mysite with your database name. Copy the dump and your uploads folders to your own computer, or to a separate backup server. Keep this copy apart from your clean backups, and label it as copied from a hacked server.

Also check your older backups. Find the newest one from before the break-in started, using the dates in your evidence. That one is likely to be clean. Using a storage VPS for backups covers keeping backups in a way an attacker on the server cannot delete.

Once your data and evidence are safe, shut the server down from the control panel.

6. Work out how they got in

If you do not find the way in, it will still be open after you rebuild. Look through your evidence for the earliest sign of the attacker, then work backwards. The common ways in, and what to look for:

Way in	What to look for
Guessed SSH password	Many failed logins, then an "Accepted password" line from an unknown IP address in the SSH log
Outdated web app, plugin or theme	Strange requests in the web access log just before new PHP files appeared. Check version numbers against the project's security notices
A service open with no password	Databases, caches, admin panels or the Docker API listening on all addresses. Check the connections list from step 1
Leaked key or password	A login with the right key or password from an unknown place, with no failed attempts first
Weak or default admin login on an app	App logs showing an admin login from an unknown IP address
Something you installed	A script, container image or installer from an untrusted source, run shortly before the problems began

Useful searches in the saved logs, run on your own computer after unpacking the archive:

grep -i "accepted" journal.txt
grep -E "POST .*\.php" var/log/nginx/access.log* var/log/apache2/access.log*

If you cannot find the way in, that is common. Rebuild anyway, and fix every item in the table above on the new server, so whichever one it was is closed.

7. Rebuild on a clean install

You have two options:

• Reinstall the same VPS from the control panel. Simple, and keeps the same IP address. Make sure the evidence and data are safely copied first, because a reinstall erases everything.
• Build on a new VPS and keep the old one shut down for a while. You can look at the old server again if you need to, and you get a fresh IP address, which helps if the old one is on blocklists.

On the clean install, before restoring anything:

1. Update the system, create a user and add only your new SSH key. Turn off password login and root login. Your first hour on a new RackNerd VPS walks through it.
2. Turn on the firewall and open only the ports you need.
3. Turn on automatic security updates.
4. Install your software fresh, from your package manager or each project's official source. Do not copy programs or scripts from the old server.
5. Bind databases and internal tools to 127.0.0.1. Reach them over an SSH tunnel or a VPN, never openly.

Securing your VPS and setting up SSH keys cover these in more depth.

8. Restore your data carefully

Restore only data, and check it on the way in.

• Websites: reinstall the code, restore the content. For WordPress and similar apps, download fresh copies of the core, themes and plugins from their official sources. Then restore only the database, uploads and your own config, with new passwords.
• Check uploads for code. Upload folders should hold images and documents, not scripts. Look for anything that does not belong:

  find ./uploads -type f \( -name "*.php" -o -name "*.phtml" -o -name "*.sh" \)

  Run it on the copied folder, and delete anything it finds unless you are sure it is yours.
• Check the database for new admins. Look at the app's users table for admin accounts you do not recognise, and remove them.
• Look for injected content. Search the database dump for script tags or links you did not add. A quick check is grep -c "<script" mysite.sql, then look at what it finds.
• Update everything before going live. Apply all updates to the app, themes and plugins, and remove any you do not use.

When you are confident, point your domain at the rebuilt server if its IP address changed, and bring the site back online.

9. Tell the people who need to know

• Your provider. Reply to any notice with what happened and what you have done. If they suspended the server, tell them it has been rebuilt.
• Your users or customers, if their personal data may have been exposed. Many countries have laws that require you to tell affected people, and sometimes a regulator, within a set time. The rules vary, so get advice for your country.
• Payment providers, if card or payment data could have been involved. They have their own processes.
• Your clients, if you host sites for others, so they can change their own passwords.
• Blocklists. If your IP address or domain was listed for spam, most lists have a removal request process once the problem is fixed.

10. Watch closely afterwards

Attackers sometimes return to see whether their way in still works. For the next few weeks:

• Check logins and running processes every day or two, using the commands in step 1.
• Watch CPU and bandwidth use in the control panel.
• Set up an outside uptime check, so you hear if the site goes down or changes. What you can do with a 512 MB VPS includes a simple way.
• Keep the evidence archive and your timeline for a few months.

Quick reference

What you found	Likely meaning	First action
Abuse notice about spam or attacks from your IP	The server is being used against others	Shut it down from the control panel, reply to the notice
Unknown process using all the CPU	Often a cryptocurrency miner	Note its name and path, lock down access, save evidence
Unknown user or SSH key	Persistence added by an attacker	Save evidence, do not just delete it and carry on
Strange cron job or service	Persistence, often restarting the malware	Save evidence, plan a rebuild
PHP files in upload folders	A web backdoor through the app	Take the site offline, check app and plugin versions
Website redirects to spam	Injected code in files or the database	Take the site offline, save the files and dump
Your login no longer works	Password or key changed by the attacker	Use the control panel console, contact support if needed

How most break-ins happen, and how to prevent them

Most small servers are not targeted by name. They are found by automated scans looking for easy openings. Closing the easy openings stops almost all of them.

• SSH keys only. Turn off password login. This alone stops a huge share of break-ins.
• Updates, always. Turn on automatic security updates, and keep web apps, themes and plugins current.
• Nothing open without a login. Bind databases, caches and dashboards to 127.0.0.1, and reach them through an SSH tunnel or a VPN. Turn off open sign-up on apps.
• Fewer things running. Remove apps, plugins and test sites you no longer use. An abandoned app is an open door.
• Secrets kept private. API keys in env files readable only by their app, never in Git and never pasted into chats or AI tools.
• Trusted sources only. Install software from your package manager, official images or the project's documentation. Avoid running install scripts piped straight from the internet.
• Backups the server cannot delete. Pulled by another server, or kept in an append-only store, and tested by restoring.
• A record of changes. Notes of what you install and change make it far easier to spot what does not belong.

Limits

• This is a guide for small servers. It is not a forensic investigation. If the stakes are high, such as personal data of many people, payment data or a business that depends on the server, hire a professional incident response service.
• Commands can be fooled. A rootkit can hide from every check in step 1. That is why rebuilding matters more than finding everything.
• Legal duties vary. This guide cannot tell you what the law requires where you live. Get proper advice if personal data was involved.
• Providers have rules. RackNerd's acceptable use policy applies even when the abuse was not your doing. Reply to notices promptly and work with support.
• No guarantee. Following every step greatly reduces the risk of a repeat, but cannot remove it entirely.

When to step up

A break-in is often a sign that a server is doing more than one person can look after. Three changes worth considering when you rebuild:

• Split jobs across servers. Keep your website on one VPS and experiments or tools on another, so one problem cannot reach everything.
• Keep backups on a separate server that pulls copies, so an attacker on your main server cannot delete them.
• Hand off what you cannot maintain. If you do not have time to keep a server updated, shared hosting, where the provider looks after the server, may be safer for a simple website. See shared hosting or a VPS.

For other server problems, see My VPS is slow or down: what to check. To compare what is available now, start with the cheapest RackNerd VPS guide and check the sales page.