Multi-Site WordPress Malware Cleanup & Hardening on Shared Hosting

The malware count was 383+ files across the account. HostGator's ClamAV had caught 247 and missed 136. On a re-audit after the first pass I found 87 more that had slipped by: obfuscated PHP, dot-prefix files, PHP sitting inside uploads/. The infection wasn't a one-off either. Planting activity ran continuously from May 2024 through January 2025, about a year of steady reinfection.

The backdoors were creative. Three wp-config.php files had injected include_once payloads calling out to hidden PHP backdoors disguised as .css files (the .0e338114.css one was confirmed actively included). Inside /wp-admin/ there was a border.ico file that was actually PHP with a fake JPEG header, triggered by a cookie, with a dynamic code-execution primitive. WordPress core files were infected too: pluggable.php, http.php, class-wp-theme-json.php, comment-template.php, wp-settings.php, index.php. There was also an SEO spam file dropping pharmaceutical affiliate links.

Attackers had built out their own persistence. I found 8 rogue admin accounts across the 3 active sites (two of them impersonating the cPanel username), a rogue database user with access to nearly every database on the account, 8 fake plugin/theme directories with random names like yvopybyhug, exozybe, and kyzysi, and 5 malicious email accounts the client had already deleted. One entire domain folder was 100% attacker-controlled: 93 PHP files, zero legitimate content. wp-login.php and xmlrpc.php were still taking active brute-force traffic.

Email was fully broken. No DMARC on any of the 4 domains, SPF records missing the mail-server IP, and the DMARC records that did exist were placed at @ instead of _dmarc. The server IP was also on the UCEProtect Level 2 range-based blacklist.

The entry point turned out to be a WordPress 6.5.2 install on an inactive legacy site, carrying known vulnerabilities. Around it were a few operational issues that were blocking the client's day-to-day: a Mod_Security 406 block disrupting the Goodlayers LMS login redirect, the WP 2FA plugin creating a login loop because it was set to all-users with no grace period, and the LiteSpeed-Cloudflare integration was broken because the stored API token was missing Zone:Read scope. Disk was at 90% (1.4TB of 1.5TB used), with a 6.3GB unknown file from Sep 2024 sitting there that looked suspicious.

The first pass was cleanup. I freed 8.5GB of disk space, backed up every wp-config.php, then stripped the injected backdoor code from them and re-locked them to chmod 444. I deleted the 3 hidden CSS backdoors, the entire 93-file attacker-controlled domain folder, and the 247+ standalone malware files the scanner had already flagged. The 8 fake plugin/theme directories and 8 rogue admin accounts went, and I dropped the rogue database user, rotated the database password, and updated every wp-config accordingly.

Then I hardened what was left. The .htaccess got rules to block xmlrpc.php, PHP execution in uploads/, and access to backup/config files. I deleted the old Duplicator 2019 installer and cleaned WP Fastest Cache's rogue user references. Wordfence went on as a monitoring layer, and I pulled backdoor code out of the Goodlayers theme's functions.php. The 3 inactive WordPress sites got removed entirely after exporting their database backups first.

The email side needed a full fix. Using the cPanel API (cpapi2), I repaired the SPF records on all 4 domains by adding the missing mail-server IP, moved the DMARC records from @ to _dmarc where they belonged, and verified DKIM was valid on each domain. I also fixed the 2FA login loop by switching the policy from all-users to admin-only with a 3-day grace period, and resolved the Mod_Security 406 block by patching the Goodlayers-LMS redirect (home_url() to '1').

For ongoing protection, I deployed Cloudflare WAF rules on the 3 active sites covering sensitive file blocking, wp-admin protection, PHP exec blocking, malicious query string filtering, and login challenges. I built a Cloudflare IP allowlist with the client's home IPv4 and IPv6 plus the HostGator server IP, and wrote two PowerShell scripts (Manage-CloudflareAllowlist.ps1 and CF-AutoIP-Manager.ps1) so the client can keep the allowlist up to date themselves. I verified coverage end to end: xmlrpc blocked, wp-config access blocked, uploads PHP blocked, dynamic-exec blocked, UNION SELECT blocked.