SC Malware Found on WordPress, Embedding Itself Across Multiple Locations and Rebuilding Backdoors After Removal

Researchers from Sucuri discovered malware on WordPress websites designated as SC, which employs multiple persistence mechanisms to restore deleted backdoor components following administrator file removal. At least eight malware components were identified across WordPress files, the database, and shared memory, each capable of facilitating the restoration of other removed components. The malware embeds itself in numerous locations including .user.ini, db.php, advanced-cache.php, theme functions.php files, regular plugins, and Must-Use plugins. Payload copies are stored in the database and shared memory. The malware hides itself from plugin management interfaces, creates hidden administrator accounts, executes PHP code, downloads additional payloads, injects JavaScript, and utilizes Ethereum infrastructure and smart contracts for command-and-control communication.

The existence of malware capable of self-restoration across diverse layers—filesystem, database, memory, and plugin structures—suggests a systemic challenge to traditional remediation efforts where simple file or plugin removal is insufficient. The mechanism relies on distributed persistence, meaning attackers intentionally seed multiple locations, creating redundancy that resists standard cleanup protocols. This shifts the security paradigm from reactive clean-up to proactive systemic identification of all potential persistence vectors. The use of advanced techniques like embedding within shared memory and leveraging blockchain infrastructure for C2 communication indicates an evolution in attacker sophistication, moving beyond simple file-based threats toward integrated, resilient control systems. The instruction for administrators to sweep for database entries, cron hooks, triggers, and hidden accounts underscores that the vulnerability is not just in code execution but in the operational integrity of the entire system architecture. This implies a pattern where persistence is designed to outmaneuver detection; therefore, security strategies must focus on immutable state verification rather than singular point remediation. What structural assumptions about WordPress's integrity are being challenged by this level of multi-layered persistence? How does the necessity of checking esoteric locations like .user.ini and shared memory alter the definition of a successful security audit?