What to do if your server has been compromised

Cut off network access before you do anything else

The first priority is stopping further damage, whether that's ongoing data exfiltration, the server being used to attack other systems, or the attacker simply noticing you're onto them and covering their tracks. Cut the server off from the network before you start digging into what happened.

How you do that depends on what you're running. On any server you still have access to, block all inbound and outbound traffic at the operating system firewall, and stop the services the attacker is using. On a Flexible VPS you can add an emergency deny rule in Firewall in Portal, which takes effect in front of the machine rather than on it. On a dedicated or bare-metal server, out-of-band management on the Remote Access tab keeps you on the console after you've closed off the network. If you can't reach the server at all, open a support ticket and describe what you're seeing.

Resist the urge to just reboot the server at this point. A reboot can clear the very things you need to see, running processes, open network connections, in-memory evidence, that tell you how the attacker got in.

Copy off what will otherwise disappear

Logs rotate and get overwritten, so copy relevant log files off the server before that happens. If you still have access to a live shell before deciding to isolate fully, take note of running processes and current network connections, they're often the clearest signal of what's actually happening on a compromised box, and they're gone the moment the system restarts.

Work out how the attacker got in

Check authentication logs for the initial point of access, an unexpected login, a brute-forced or reused credential, an exploited service. Look for anything added after the fact: new user accounts you didn't create, unexpected cron jobs, entries appended to authorized_keys that you don't recognise, and processes running that have no obvious reason to exist. Knowing how the attacker got in matters as much as cleaning up after them, without it you risk walking straight back into the same hole once the server is back online.

Rebuild rather than clean in place

Once an attacker has had access, you can no longer fully trust anything on that system, including tools you'd normally use to inspect it. The safest path is almost always reinstalling from a known-clean image, or restoring from a backup taken before the compromise, rather than trying to manually hunt down and remove every trace of the intrusion. Manual cleanup on a system you can't fully trust risks missing something, a backdoor, a modified binary, that lets the attacker straight back in.

Assume everything the server touched is exposed

Rotate SSH keys, passwords, and API keys, everything that could plausibly have been read or copied while the attacker had access, not just the specific credential you think was actually used. If the server held credentials for other systems, database passwords, third-party API keys, those need rotating too. Treat "might have been exposed" as "was exposed" here, it's a far safer assumption than the alternative.

Close the door you now know was open

Before bringing the rebuilt server back into production, patch whatever let the attacker in, re-check your firewall rules, and make sure monitoring is actually watching this time. This is also a reasonable point to work through the standard hardening steps if you haven't already, see Hardening a fresh VPS and How to improve your SSH security, plus keeping a regular patching cadence going forward, see Patch management: building an update strategy for your server.