SC 4.0.3 Self-Healing WordPress Malware Removal

Deleting a malicious WordPress plugin may not end an infection if hidden loaders, database records, running processes, or browser code can restore it. This field case study follows an SC 4.0.3 infection that returned within seconds of cleanup across a 24-site shared-hosting account.

• Map how the infection moved through .user.ini, hidden PHP loaders, MU-plugins, WordPress drop-ins, themes, plugins, ZIP archives, and sibling sites.
• Investigate database options, transients, and scheduled tasks used to coordinate or restore malware.
• Examine how running PHP processes and PHP-FPM memory may retain behavior after files are removed.
• Trace a browser service worker that added another persistence layer.
• Decode Base64 and compressed payloads safely, compare recovered samples and hashes, and use read-only SQL to verify database evidence.
• Review related SC 4.5.3 samples and distinguish recurring malware markers from site-specific code.
• Follow a field checklist for evidence preservation, containment, access revocation, coordinated cleanup, and recovery verification.

The case is built from preserved files, database exports, browser evidence, and incident screenshots. Thirteen numbered figures document key parts of the investigation, including hidden loaders, drop-ins, database persistence, service-worker behavior, and scanner results. PHP, SQL, and shell examples explain how to inspect the evidence without running the malware.

This is one detailed multi-site case study, not a general catalog of every SC infection. It separates what the recovered code and artifacts demonstrate from what they cannot establish, such as the original entry point or whether every capability was used.