SC WordPress Backdoor Uses Eight Persistence Components
Security firm Sucuri has analysed a WordPress backdoor dubbed SC that can maintain itself through at least eight locations spanning site files, the WordPress database and System V shared memory. The malware is designed so that removing a plugin, drop-in or other individual component does not end the compromise: a surviving copy can recreate the missing elements on a subsequent request.
The name SC comes from “SC_” markers in injected content. Sucuri researcher Gabriel Barbosa described the arrangement as a self-healing mesh, with copies able to restore one another rather than relying on one removable persistence point. Sucuri also said the malware uses a decoder and substitution cipher instead of readable function names.
A persistence chain across WordPress and the server
One component is a .user.ini file that sets auto_prepend_file, causing a loader to run before every PHP request in the relevant directory tree. That loader points to a hidden dot-prefixed file under wp-content. The hidden loader can locate a fake plugin and rebuild its must-use version from an existing plugin copy, an encoded cache stub or a ZIP restore bundle with a random hexadecimal name.
Other copies sit in wp-content/db.php, advanced-cache.php and the active theme’s functions.php. The db.php drop-in stores the complete payload in compressed, Base64-encoded form and redeploys the plugin when it is absent or too small. When caching is enabled, advanced-cache.php loads before ordinary plugins, can rebuild the malware from five sources and includes it through a plugins_loaded hook.
The payload also exists as hyper-engine-kit.php in both the must-use plugins directory and the standard plugins directory. On servers with System V shared memory, it writes PHP into a segment identified by a fixed numeric key. Sucuri noted that this RAM-resident segment can survive file deletion and database cleanup and, in shared hosting environments, may be owned by a different account.
What the operator can do
SC hides itself from the WordPress plugin administration screen and update checks, fingerprints the compromised site, retrieves further payloads and communicates with its command-and-control infrastructure through the Ethereum blockchain. It can create a concealed administrator account, run arbitrary PHP, fetch JavaScript for injection into visitors’ browsers and deactivate or delete selected plugins.
The toolkit also registers WordPress cron hooks, including randomized names and a known fetch hook. System cron invokes the WordPress cron file independently of visitor traffic, allowing scheduled redeployment. The delivery route is not known. Sucuri listed known WordPress, plugin and theme flaws, weak credentials, supply-chain attacks and insecure upload features among typical initial-access routes.
The risk is especially relevant alongside flaws such as a WordPress Comment2Shell code-execution path, which can turn an anonymous comment XSS condition into code execution through an administrator session. SC demonstrates that once an attacker establishes persistence, deleting a suspicious plugin alone may leave the underlying recovery paths intact.
Incident response needs a wider scope
For affected organisations, the investigation must include WordPress drop-ins, must-use and regular plugin directories, theme files, database content, cache artefacts, cron configuration and supported shared-memory segments. Administrators should also look for unexpected privileged accounts and review server-level PHP configuration that could invoke a loader before normal WordPress execution.
A practical business implication is that recovery should be treated as a full environment remediation: isolate the site, identify every persistence layer, restore trusted components, rotate credentials and validate the rebuilt service before returning it to operation.