Process table
Processes owned by hosting accounts that are not PHP-FPM, web workers or known jobs — recorded with binary path, parent and start time before anything is stopped.
Linux server malware removal
Server Malware Removal for Hacked cPanel, WHM and Linux VPS Hosts
When the backdoor sits on the server rather than inside one WordPress site, a per-site cleanup removes the symptom and leaves the mechanism. This is incident response for hacked cPanel/WHM, Plesk, DirectAdmin and Linux VPS hosts: root-level triage, containment, credential rotation, per-account cleanup, and a rebuild decision made on evidence. Every inquiry receives a reply within 24 hours; incidents are prioritized.
Never send credentials, private keys, backup archives, or confidential source code through this website.
- Best for
- cPanel/WHM, Plesk, DirectAdmin and VPS hosts with a confirmed or suspected server-level compromise
- Vantage point
- Root or sudo on the host, not a plugin inside one site
- Priority
- Preserve evidence and contain before anything is deleted
- Output
- Incident record, persistence removed, per-account status, and a verification pass
- Typical fee
- Scoped per server after triage; the written proposal states the fixed fee
Server or site?
Server malware removal vs WordPress malware removal vs server audit
Three services touch a hacked server. Picking the wrong one is how the same host gets flagged again next month.
Unsure? Start here: triage establishes whether the problem is one account or the host, and any per-site cleanup is scoped from that answer.
| Compare | WordPress malware removal | Server malware removal | Linux server audit |
|---|---|---|---|
| When it fits | One site is infected and you do not administer the server, or the server has been ruled out | Several accounts are affected, or there is unknown cron, processes, SSH keys or outbound traffic | Nothing is known to be wrong and you want the host measured and hardened |
| Main output | Cleanup record for the site | Incident record for the server, with a status for every account | Prioritized findings with ownership and retest results |
| Fee | $120–$500 per site | Scoped per server after triage | $300–$750 per server |
| Details | WordPress malware removal | This page | Linux and cPanel server audit |
Engagement scope
What root-level triage checks on a hacked Linux server
Triage reads before it changes anything, in the places WordPress scanners and account-level scans never reach.
Cron and systemd timers
Every user crontab, /etc/cron.d, at jobs and systemd timers, read as text for entries that download, decode or run from /tmp and hidden paths.
Account home sweep
Hidden dot-directories, executables and recently changed files outside public_html in every account home — not only the one that was flagged.
SSH keys and API tokens
authorized_keys for root and every user, plus WHM and cPanel API tokens: access that survives every password change until it is explicitly removed.
Outbound sessions
Established connections per process. Tunnels, relays and miners connect out, which an inbound-only firewall never sees.
Panel logins
WHM root and reseller logins and cPanel sessions, compared against when your own staff actually logged in.
Isolation
Whether CageFS, PHP handler separation and file permissions actually stop one compromised account from reading or writing its neighbours.
Temp and mail paths
/tmp, /dev/shm and other world-writable staging paths, and outbound spam traced to an account or script.
Cleanup and recovery
How a hacked cPanel or VPS server is cleaned: accounts, credentials, rebuild
Per-account cleanup
WordPress core, plugins and themes replaced from trusted sources rather than hand-edited; databases checked for injected content and rogue users; .user.ini and other PHP startup directives reviewed.
Credential rotation
Root, WHM, reseller and cPanel passwords, SSH keys, API tokens, FTP and database users, WordPress administrators, and secrets in wp-config.php and .env files — rotated from a clean device.
Server backdoor removal
Binaries, cron entries, timers, keys and tokens found in triage are removed only after they have been copied, hashed and recorded.
Rebuild decisions
Whether each account can be cleaned in place or must be restored or moved — and whether the host can still be trusted. Where root is in doubt, the answer is a fresh host.
Incident sequence
Hacked server response: the first 24 hours, in order
The order does not change. How much fits into the first day depends on access, server size and the host; rebuild and final verification usually run beyond it.
- 01
Preserve
Take a provider snapshot if available, then copy suspicious files, crontabs, the process list (ps auxf), connections (ss -tnp) and logs off the server, with path, owner, timestamps and SHA-256 for each artifact. These commands only read.
- 02
Contain
Suspend affected accounts or block their outbound traffic, disable their cron, and stop recorded processes. What stays online is agreed with you.
- 03
Rotate
Change the credentials an intruder is likely to hold, starting with root, WHM and shell access, and remove SSH keys and API tokens nobody can account for.
- 04
Sweep
Every account home, every crontab (crontab -l -u USER, ls -la /var/spool/cron, systemctl list-timers --all), temp paths, root’s keys and panel logs — checked against the preserved timeline.
- 05
Rebuild
Replace what cannot be trusted: application files on affected accounts from verified sources, and the whole server onto a fresh host where root compromise cannot be ruled out.
- 06
Verify
Re-check processes, cron, outbound connections, file changes and the mail queue (exim -bpc on cPanel) once normal traffic resumes, and again over the following days.
Documented engagement
Server backdoor removal case: gsocket on a 261-account WHM server
A WooCommerce shop on a WHM server carrying 261 cPanel accounts was listed as malicious on VirusTotal. Wordfence flagged 283 infected files, ImunifyAV returned a comparable file-level picture, and a full database export was clean. None of them found the mechanism.
A root SSH filesystem review did: a packed x86-64 ELF binary at ~/.config/htop/defunct in the account home, outside public_html, assessed as a gsocket remote-access backdoor. The engagement then moved from site cleanup to server incident response. The report documents the sequence used from there — preserve, contain, rotate, rebuild, verify — and states plainly what the evidence could not establish, including how the account was first reached.
Deliverable
What you receive after server malware removal
- An incident record: timeline, evidence preserved, actions taken and who authorized them
- A list of the persistence removed — binaries, cron entries, timers, keys and tokens — with paths and hashes
- The likely entry condition, stated with the confidence the evidence supports
- A per-account status: affected, cleaned, rebuilt, or checked and clear
- The hardening applied to close the entry condition, and the items that belong to the host
- A verification pass after cleanup, with what was re-checked and when
Panels and distributions
cPanel/WHM, Plesk, DirectAdmin and VPS servers reviewed
Log locations and tools differ by panel and version; paths below are the usual defaults — verify them against your own installation.
| Platform | What is reviewed |
|---|---|
| cPanel/WHM | Root and reseller logins (/usr/local/cpanel/logs/login_log, access_log), per-user crontabs, WHM and cPanel API tokens, account homes, Exim queue and /var/log/exim_mainlog |
| Plesk | Subscriptions under /var/www/vhosts, Plesk users and /var/log/plesk/panel.log, scheduled tasks per subscription |
| DirectAdmin | User and reseller accounts, per-user cron, account homes, and DirectAdmin’s own logs under /var/log/directadmin/ |
| CloudLinux / CageFS | Whether CageFS is enabled for every account (cagefsctl --list-enabled), PHP selector and handler isolation |
| Ubuntu / Debian VPS | /var/log/auth.log and the journal, /var/spool/cron/crontabs, systemd timers, package changes in /var/log/apt/history.log |
| AlmaLinux / Rocky VPS | /var/log/secure, /var/spool/cron, systemd timers, dnf history, and package file integrity with rpm -Va |
Boundaries
What server malware removal cannot promise
Logs may not prove how the intruder got in. Retention on shared and reseller hosting is often too short, and an intruder with enough access can edit what remains. The report states the likely entry condition and the evidence behind it; it does not claim an entry vector the logs cannot support.
A root-level compromise may not be cleanable in place. Once system binaries, root keys or logs may have been altered, tools on that host cannot be trusted to report on it — rpm -Va and debsums compare files against a package database the intruder could also have edited. The verifiable outcome is a fresh host, with accounts restored from verified-clean sources rather than from backups taken after the compromise.
Common questions
Questions about server malware removal
Is this different from WordPress malware removal?
Yes. WordPress malware removal works on one site: its files, database, users and hosting account. Server malware removal starts at root — processes, cron, every account home, keys, tokens and outbound connections — and includes the per-site cleanups triage shows are needed. If the server is ruled out, the per-site service is the right one.
Do I need to rebuild the server?
Not always. A compromise contained to one account, with root controls intact and isolation enforced, can usually be cleaned in place. If root access is suspected, isolation was never configured, or the account count makes a reliable sweep impractical, a rebuild onto a fresh host is safer.
Can you work on a server where I only have reseller access?
Partly. The accounts you own can be reviewed and cleaned at account level: files, cron, SSH keys and tokens. The process table, system cron, root keys, temp paths and server logs need root, so those checks become a written request to the host rather than being skipped.
What do you need from my hosting provider?
On a managed or reseller server: logs for the incident window, the isolation settings in force, a snapshot before changes, and anything the host already quarantined or removed. On an unmanaged VPS the provider usually supplies only snapshots and console access.
How is the fee set?
After scoping triage. The number of accounts, whether root may be compromised, the access available, how many sites need cleanup, and whether a rebuild is needed all move it. The written proposal states the fixed fee before any access is exchanged.
ImunifyAV or Imunify360 already cleaned the files. Is the server clean?
It is clean of what the scanner detected. A file scanner does not read the process table, crontabs, SSH keys, API tokens or outbound sessions, and files reappearing after quarantine mean something is recreating them.
Should I delete the malware before you start?
No — preserve first. Copy files, crontabs and logs off the server and record hashes and timestamps. Blocking outbound traffic or suspending an account is fine; deleting the artifact destroys the evidence of how far the compromise reached.