Skip to content
OrbixPanel OrbixPanel Tutorials

What to do if your server is compromised

Hardening lowers the odds of a breach; it never makes them zero. The difference between a scare and a disaster is usually whether you have a plan before it happens. This is that plan.

First, breathe. Acting carefully beats acting fast.

Site compromise vs. root compromise

Knowing which one you’re dealing with decides everything that follows.

  • Site compromise — one website/account is affected (defaced pages, injected spam, a planted script). The rest of the server is intact. You can usually clean or restore just that site.
  • Root compromise — the attacker has root/administrator access to the whole server. At that point nothing on the box can be trusted — not files, not config, not credentials, not even the tools you’d use to investigate. The only safe recovery is to rebuild on a fresh server and restore known-good data.

A readable /etc/passwd or a cross-site symlink trick is not by itself a root compromise. But any genuine unauthorized root access should be treated as a total loss.

Step 1 — Contain it

  • Take the affected site offline (disable it, or put it in maintenance) so it can’t keep serving malware or spam.
  • If you suspect root compromise, isolate the whole server — restrict the firewall to your own IP, or take it off the network — and plan to rebuild rather than patch in place.
  • Change passwords from a clean device — your panel login, SSH, database, and email. If your own computer might have malware, changing passwords from it just hands the new ones over too.

Step 2 — Restore from a known-good backup

The fastest clean recovery is almost always a restore to a point before the compromise.

  • Restore the site/account from a backup dated earlier than the first sign of trouble. → Backups & restore
  • Test the restored copy before putting it back online.
  • Restoring without finding the entry point (Step 3) just gets you re-hacked — do both.

No backups? See Rebuild clean below. And set up automated offsite backups today so this is never the situation again.

Step 3 — Find the entry point

Most intrusions come in through a small number of doors. Check them in order:

  1. Outdated CMS plugins, themes, or extensions. This is the #1 vector for WordPress/Joomla/Drupal sites — the core apps are patched quickly, but a stale third-party plugin is an open window. Audit and update everything, remove what you don’t use. → Secure a WordPress site
  2. Stolen credentials. A trojan on your own computer, or a reused/leaked password, hands an attacker a valid login. Rotate credentials and scan your workstation.
  3. Unpatched software. Watch the security advisories feed and apply updates promptly.
  4. Exposed services / weak SSH. Confirm only the ports you need are open and SSH uses keys, not passwords. → Firewall · SSH keys

Step 4 — Hunt for what they left behind

Attackers plant persistence and pursue a goal. Look for both:

  • Backdoors & web shells. Run a malware scan across the site’s files — it flags injected PHP, obfuscated uploads, and known shells. → Scan your sites for malware
  • Unknown cron jobs. A rogue cron re-infects a site after you clean it. Review every scheduled task and delete anything you didn’t create. → Cron jobs
  • Email tampering (spam is a common motive). Check mailboxes, forwarders, and filters for entries you didn’t add — a classic move is to wipe mail passwords and add one account for mass-mailing. → Mailboxes & forwarders
  • New or changed users — panel users, database users, SSH/FTP accounts.
  • Recently modified files. Unexpected changes to app code, .htaccess, or config are a red flag. Your activity log and file timestamps help here.

Motive hints at where to look: spam → email config; data theft → database users, cron, and credentials; malware distribution → injected files and backdoors.

Step 5 — No backups? Rebuild clean

Cleaning a hacked site by hand is real work and easy to get wrong (one missed backdoor and you’re re-infected). If you must:

  • Stand up a fresh install, copy over only content and data you’ve verified (never the old executable code wholesale), reset every password, and update everything before going live.
  • For a root compromise, rebuild on a new server — don’t trust the old one.
  • If it’s beyond you, bring in a professional malware-removal service rather than guess.

Step 6 — Close the door for good

Once you’re clean, make the breach non-repeatable: