You discovered your WordPress site is hacked. Maybe Google flagged it. Maybe your host suspended the account. Maybe a client called to say your site is redirecting to a pharmacy spam page. Maybe your mail domain landed on a blacklist overnight and your emails stopped delivering.
You installed Wordfence. You ran the scan. It found some things, you deleted them, and two days later the same infection was back.
This is the most common pattern in WordPress compromise recovery — and it happens because plugin-based scanners operate at the application layer. The infection you are dealing with is almost certainly operating below that, at the server level, where no WordPress plugin can see it.
This post explains what a root-level cleanup actually involves, why plugins are insufficient for serious infections, and what the difference is between a site that has been cleaned and a site that has been secured.
Why Plugin Scanners Fail on Serious Infections
Modern WordPress attacks rarely rely on a single vulnerability. Instead, attackers chain multiple small weaknesses — reconnaissance to identify plugin versions and server configurations, initial access via an outdated plugin, privilege escalation to find additional weaknesses, persistence through backdoors that survive plugin updates and cleanup attempts, and data extraction including customer data and payment information. InMotion Hosting
That last point is the critical one: backdoors that survive plugin updates and cleanup attempts.
Backdoors enable hackers to reinfect websites almost immediately after cleanup, wiping out all cleaning effort. Just like malware, backdoors can be anywhere — and they frequently use PHP functions that have legitimate use cases, making them harder to identify and easier to miss. IONOS
A plugin scanner running inside WordPress has access to the WordPress file system within its permissions boundary. It cannot inspect server configuration files, other virtual hosts on the same server, cron jobs added at the system level, or PHP files placed outside the web root. A competent attacker knows exactly where those boundaries are.
It is quite common for hackers to drop a full-featured backdoor, use it to accomplish their objective, and then delete the backdoor itself — leaving behind only the payload while removing the entry point that would have identified how they got in. HostAdvice
This is why the same infection keeps coming back after a plugin cleanup: the entry point was never found and removed.
What a Server-Level Compromise Actually Looks Like
Understanding the hack type determines the cleanup strategy — database spam needs SQL surgery while backdoors require file forensics. Contabo Here is what I typically find when I connect to a compromised server via SSH:
PHP webshells in unexpected locations
Files named x.php, image.php, config.old.php placed inside /wp-content/uploads/ subdirectories, inside plugin folders, or — on shared servers — outside the web root entirely in the account’s home directory. These are fully functional remote execution tools. Anyone with the URL can execute arbitrary commands on the server as the web user.
Modified core files
wp-config.php, index.php, wp-load.php with injected code at the top or bottom — often base64-encoded to avoid string matching. Hackers love to hide code in plain sight inside core files, and the safest fix is complete replacement rather than editing, because subtle obfuscation is easily missed. OVHcloud
Malicious .htaccess modifications
Redirect rules that send non-logged-in visitors to spam sites, pharmaceutical pages, or malware distribution URLs — while the site appears completely normal when you are logged into the admin panel. Site redirects that only affect visitors who are not logged in are a classic sign that .htaccess or JavaScript has been injected. LowEndBox
Database injections
Spam links injected into post content, option values, or widget data. Fake administrator accounts created silently. Database cleanup including backdoors that automated scanners may miss requires direct SQL access and manual inspection of the wp_options, wp_users, and wp_posts tables. OVHcloud
System-level persistence
Cron jobs added to the server’s crontab — not WordPress cron, the actual Linux crontab — that re-download and re-execute the infection payload on a schedule. This is why cleaning the files is not enough: the infection re-downloads itself every hour until the cron entry is removed.
Mail server abuse
The compromised server is used as a spam relay. Your mail domain and sending IP land on Spamhaus, SORBS, or Microsoft’s SNDS blacklist. Legitimate mail from your domain stops delivering. This continues even after the malware is removed until the blacklist entry is delisted — a process that requires separate action with each provider.
What Root-Level Cleanup Actually Involves
When I take on a compromised server recovery, this is the actual process — not a plugin workflow:
Step 1 — SSH access and immediate assessment
Connect as root. Check running processes for anything unexpected. Review recently modified files across the entire server, not just the WordPress installation:
bash
find /var/www -name "*.php" -newer /var/www/html/wp-config.php -ls
find /tmp /var/tmp -name "*.php" -ls
grep -r "eval(base64_decode" /var/www --include="*.php" -l
grep -r "system(" /var/www --include="*.php" -lThis surfaces files that a WordPress plugin cannot see and would never scan.
Step 2 — Crontab inspection
bash
crontab -l
cat /etc/cron* 2>/dev/null
ls -la /var/spool/cron/System-level cron entries that re-execute malware are one of the most common reasons a cleaned site re-infects within 24 hours.
Step 3 — Process and network inspection
bash
netstat -tulpn
ps aux | grep -v grepActive outbound connections to command-and-control servers, cryptomining processes running as the web user, SMTP relay scripts sending thousands of spam messages per hour — all visible at this level, none visible from within WordPress.
Step 4 — Full file system audit
Every PHP file in the web root compared against known-clean WordPress core checksums. Plugin files inspected against their published versions. Theme files audited line by line. Upload directories checked for executable PHP — uploads should never execute PHP and the configuration to prevent this is a hardening step, not a default.
Step 5 — Database forensics
Direct MySQL access to inspect option values, user accounts, post content, and comment tables for injected links, hidden redirects, and unauthorised administrator accounts. Data injections are among the most common WordPress security issues — once a hacker gains access they can modify files and tables in the database, adding spam links often buried in the WordPress footer or injected into legitimate content. HostAdvice
Step 6 — Mail blacklist remediation
Check the server’s sending IP against major blacklists. Verify DKIM, SPF, and DMARC records are correctly configured. Submit delisting requests to each blacklist provider with evidence that the source of abuse has been removed. This step is frequently skipped in plugin-based cleanups, leaving the client with a clean site but broken mail delivery for weeks.
Step 7 — Hardening
This is what transforms a cleaned site into a secured one:
- PHP execution disabled in
/wp-content/uploads/at the NGINX config level wp-config.phppermissions set to 400- WordPress core file permissions audited and corrected
- XML-RPC disabled if not in use
- Login URL relocated or protected with rate limiting
- Fail2ban rules updated to block the attack patterns identified during the audit
- WordPress salts and security keys regenerated
- All user passwords force-reset
Step 8 — Written incident report
Every finding documented — what was found, where, what was done to remove it, and what hardening was applied. This is not optional: it is how you know the job was actually completed, and it is your record if the issue recurs.
The Difference Between Cleaned and Secured
After cleanup, stronger protective measures are critical — security plugins, proper file permissions, and limited admin access are vital for lowering the risk of repeat attacks. LowEndBox
But “security plugins” is not the answer I would give. The answer is server configuration.
A WordPress site running on a properly hardened NGINX server with correct file permissions, PHP execution disabled in upload directories, Fail2ban blocking repeated login attempts, and Rspamd handling mail — that site is resistant to the vast majority of automated attacks regardless of which security plugin is or is not installed.
A WordPress site running on a poorly configured shared server with world-writable directories and no server-level rate limiting — that site will be re-compromised regardless of which security plugin you install, because the vulnerability is in the infrastructure, not the application.
The cleanup removes the infection. The hardening changes the environment so the infection cannot take hold again. Both are required. Only one of them requires root access.
When to Call an Engineer Instead of Running a Plugin
If your hourly rate is $50 or above, spending twelve hours on a DIY cleanup costs $600 or more in time alone — not including the risk of incomplete cleanup or extended downtime. Namecheap
The situations that require professional root-level cleanup rather than a plugin run:
- The infection returns within days of a plugin cleanup
- Your mail domain is on a blacklist and deliverability is affected
- Your host has suspended the account for abuse
- Google has flagged the site with a Safe Browsing warning
- You are running an e-commerce site with customer payment data
- The infection has been present for more than a week — persistence mechanisms are likely in place
The Recovery Service
I provide root-level WordPress server compromise recovery for USA businesses. SSH access to your server, full file system and database audit, complete malware removal including backdoors and persistence mechanisms, mail blacklist remediation, hardening, and a written incident report.
Fixed price: from $750. Scoped per complexity after a free initial assessment.
If your server is actively compromised right now, mention it when you contact me. I prioritise urgent situations.
Pieter is an independent Linux infrastructure engineer with 40 years of engineering discipline and ISPConfig experience since 2005. IronPanel provides server migration, compromised server recovery, and managed infrastructure retainer services for USA businesses.