SC WordPress Malware Rebuilds Itself After Removal Using Database and Memory Persistence

A newly analyzed WordPress malware family, tracked as SC for the “SC_” markers embedded in its injected code, uses a self-healing persistence mesh that can restore a deleted backdoor within seconds.

Researchers found that SC does not rely on a single web shell or plugin. Instead, the malware creates at least eight interdependent persistence points, including .user.ini, hidden PHP loaders, WordPress drop-ins, theme files, a must-use plugin, and a conventional plugin copy.

Each component can restore the others, turning cleanup into a containment problem rather than a straightforward file-removal exercise.

The infection commonly begins with a malicious .user.ini directive using auto_prepend_file.

This forces PHP to execute an attacker-controlled loader before processing every request within the affected directory tree, including requests that never reach the WordPress application.

The directive typically points to an innocuous-looking PHP shim in wp-content, which then conditionally loads a hidden, dot-prefixed PHP file containing the actual restoration logic.

This design also introduces an operational risk during remediation. PHP caches .user.ini directives, meaning that deleting the prepend target while the directive remains cached can cause application-wide PHP failures until the cache refreshes.

Administrators therefore need to neutralize the directive safely and coordinate PHP-FPM or relevant process restarts before removing the referenced loader.

SC abuses two WordPress drop-in locations that execute before standard plugins: wp-content/db.php and wp-content/advanced-cache.php.

The malicious db.php contains a compressed and Base64-encoded copy of the full backdoor.

If the primary payload is absent or has been truncated, the drop-in decodes and writes a new plugin copy to disk during WordPress bootstrap.

The advanced-cache.php component is particularly dangerous because it can execute before ordinary plugins when caching is enabled.

Rather than relying on a single embedded backup, it searches several restoration sources in sequence: a must-use plugin, a regular plugin copy, a System V shared-memory segment, a ZIP archive, and a payload stored in the WordPress database. It can then load the recovered code through the plugins_loaded hook.

The malware also injects a bounded malicious block into the active theme’s functions.php. This theme-resident implant functions as another recovery node, recreating the plugin whenever it disappears.

Such use of legitimate-looking WordPress locations makes simple filename-based detection unreliable, particularly because filenames, metadata, and identifiers vary across samples.

The most significant SC capability is its use of non-file persistence. The malware stores a full compressed payload in a randomly named wp_options row, which advanced-cache.php can retrieve through a direct database connection using the victim site’s own WordPress credentials.

Sucuri Researchers said that, the campaign distributes its payload across WordPress files, database options, archive backups, scheduled tasks, and System V shared memory, ensuring that removing one component merely triggers another to rebuild it.

SC WordPress Malware

Consequently, a defender can clean the web root thoroughly and still see the infection return on the next request.

SC also stores PHP code in System V shared memory where supported. This in-memory copy can survive disk cleanup and, depending on the hosting environment and process lifecycle, persist until the relevant PHP processes or shared-memory segment are explicitly removed.

Related variants have also been observed using scheduled WordPress cron tasks and, in some cases, database triggers that recreate hidden administrator accounts.

Once active, the payload conceals itself from plugin views, update checks, and WordPress administration screens. It masquerades as a legitimate plugin, often providing fake settings pages, shortcodes, and activation routines to reduce suspicion.

The must-use plugin copy is automatically loaded and can remain invisible to administrators who only inspect conventional plugins.

For command-and-control, SC abuses public Ethereum JSON-RPC gateways and smart-contract calls rather than relying on one hardcoded attacker domain.

The malware selects from a broad pool of public RPC services, queries smart contracts using eth_call, and retrieves encrypted instructions or current command infrastructure.

This approach complicates network blocking because defenders must account for the complete set of abused gateways rather than only the endpoint visible in one incident.

The backdoor can profile the compromised site, collect WordPress and plugin details, identify active themes and administrator session data, inject malicious front-end JavaScript, deploy additional PHP, and disable security plugins.

On e-commerce sites, injected client-side code can enable checkout skimming and payment-data theft.

Effective response requires stopping execution before deleting files.

Incident responders should place the site into maintenance mode or isolate it, preserve forensic copies, inspect .user.ini and .htaccess directives, disable malicious bootstrap paths, terminate or restart affected PHP workers, and inspect System V shared-memory segments.

The WordPress database must be reviewed for suspicious options, unknown administrator accounts, cron hooks, and database triggers before restoring files.

A clean restoration should include WordPress core replacement, trusted theme and plugin redeployment, credential rotation, regeneration of WordPress salts, review of hosting-account access, and validation that no malicious drop-ins, loaders, database objects, or in-memory remnants remain.

For SC infections, deleting the visible plugin is not remediation; it is only the event that activates the malware’s recovery mechanism.

Cut every SOC alert investigation by 21 min. Power your SOC with instant IOC context for immediate response: Integrate TI Lookup in your SOC