Self-Healing WordPress Malware Uses Blockchain Backdoor

A self-healing WordPress malware family named SC can rebuild itself from eight separate hiding places, according to a September 30, 2026 report by Sucuri researcher Gabriel Barbosa. The family takes its name from the SC_ markers found in the injected code. During a cleanup, the same backdoor kept returning within seconds of every removal, no matter how carefully the visible files were deleted. The payload lives in at least eight places at once, spread across files, the database, and shared memory, and every one of those places can rebuild all the others. Delete the plugin and a drop-in rewrites it. Delete the drop-in and the theme rewrites it. Clean every file on disk, and the next page load restores the whole set from the database or from a shared-memory segment. The result is a circular system with no single point that can be removed to stop it.

The recovered components use a common obfuscation scheme: no eval, no readable function names, and no markers on the newest pieces. Each file carries a table of scrambled strings and a small decoder that resolves a numeric index into a real function name through a positional substitution cipher. A .user.ini file sets auto_prepend_file, a PHP directive that runs a specified file before every request in that directory tree. The directive points at a plainly named shim file, commonly in wp-content. The shim includes a hidden dot-prefixed loader if it exists and silently does nothing if removed, which keeps the site functional while another component recreates the hidden file. That hidden loader rebuilds a fake must-use plugin from three sources tried in order: an existing plugin copy, an encoded stub in the cache directory, and a ZIP restore bundle with a random hex name. It writes through a temporary file, sets permissions to 0644, and calls opcache_invalidate so the new file executes immediately. A db.php drop-in, which WordPress loads early during startup, carries the entire backdoor as a gzip and base64 blob and rewrites the plugin whenever it is missing or too small. An advanced-cache.php drop-in, loaded even earlier when caching is enabled, can rebuild the plugin from five sources: an existing must-use plugin, an existing plugin copy, a System V shared-memory segment holding PHP, a ZIP bundle searched across several folders, and finally the database itself through a direct connection using the site's own credential constants. A block appended to the active theme's functions.php, fenced by begin and end markers, acts as a theme-resident twin of db.php and rewrites the plugin when it goes missing. The actual malware payload is installed as both a must-use plugin and a normal plugin, with identical copies, a convincing settings page, a shortcode, and an activation hook.

The backdoor hides itself by filtering the plugin list, the update transient, and the site and network plugin views, and it injects admin JavaScript to scrub itself from the plugin table as a fallback. For command and control, it does not use one hardcoded server. Instead, it carries a list of roughly twenty public Ethereum RPC gateways and a set of smart-contract method selectors. These legitimate third-party gateways act as transport, so blocking only the one seen in traffic leaves the others available. The payload fingerprints the site by collecting the site URL and host, WordPress and plugin versions, path hashes, active themes, the must-use plugin list, and current administrator session tokens. It encrypts that bundle and posts it to the resolved endpoint. The reply can contain front-end JavaScript to inject, which on an online store enables checkout skimming, new PHP to install, and lists of security plugins to deactivate and delete. When told to remove a security plugin, it can deactivate it, wipe its directory, and reassign or elevate another account first. It also creates a hidden administrator by adopting an existing hidden admin or generating a new one, writing the account directly into the users and usermeta tables when the normal API is unavailable. It stores capabilities under the default capabilities meta key, hides the account from user lists, counts, and role views, and forges valid authentication cookies so the operator can log in without a password. A magic request parameter, a short prefix followed by a fixed value, is handled before WordPress finishes loading and returns a normal response with content before exiting. Finally, the payload hooks a large set of actions and filters to rewrite every other component: the db.php and advanced-cache.php drop-ins, the theme injection, the hidden loader and its .htaccess and .user.ini prepend directives, the ZIP restore bundle, the shared-memory segment, and the database copy. It even opens a raw database connection to insert its payload option directly, bypassing WordPress.

The single most important lesson from this case is that persistence is not limited to files. Sucuri recovered live copies of the payload in three non-file locations, any one of which will rebuild the whole set on the next request. The full payload sits in an options row under a random name, stored in the same gzip and base64 format, and advanced-cache.php reads it back through a direct database connection. On servers that support System V shared memory, the payload is written into a segment identified by a fixed numeric key. That segment lives in RAM, so it survives file deletion and database cleanup alike, and on shared hosting it can even be owned by a different account. The infection also registers cron hooks, including randomized names alongside a known fetch hook. System cron runs the WordPress cron file, not visitor traffic, then triggers redeployment on schedule. Related SC variants use database triggers that recreate an administrator on insert. A trigger runs inside the database, so it survives a full file restore and even the deletion of the account it keeps recreating, which makes cleaning users pointless until the trigger is gone.

Because every component can rebuild the others, the order of operations matters more than the individual deletions. Sucuri's recommended cleanup starts by neutralizing the prepend before deleting its target. The auto_prepend_file value is cached by PHP for up to 300 seconds, so emptying the prepend target to an inert stub first, then stripping the directive from .user.ini, php.ini, and .htaccess, avoids taking down every PHP request on the account. Next, clear the off-disk payload copies: remove the payload row from the options table, purge the shared-memory segment, and delete the control options and transients. On shared hosting, a shared-memory segment may be owned by another account, in which case only that account or the host can remove it, and it becomes harmless once the drop-ins that read it are gone. Then remove the scheduled tasks and any database triggers: clear the malicious cron hooks and audit information_schema.TRIGGERS for any trigger that recreates an administrator on in