SC Malware Turns Cleanup Into a Regeneration Trigger

SC malware attacks WordPress with eight interdependent persistence points. Removing the visible plugin activates the recovery mechanism rather than disabling it, demanding a new remediation paradigm.

On September 30, Sucuri's incident response team published its analysis of SC, a WordPress malware that redefines the parameters of persistence. SC does not merely hide; it builds a circular network of at least eight interdependent components across files, the database, and shared memory, where the removal of any single element triggers the restoration of all others within seconds.

Key Takeaways

SC malware implements at least eight interdependent persistence points: .user.ini, hidden loader, db.php, advanced-cache.php, active theme injection, must-use plugin, conventional plugin, and System V shared memory.
Every component can regenerate all the others: deleting the visible plugin activates recovery, it does not disable it.
Command and control routes through approximately twenty public Ethereum RPC gateways, reading encrypted instructions via smart contract.
The payload survives disk cleanup in three non-file locations: a wp_options row, System V shared memory, and an encoded stub inside bootstrap components.

How the Circular Persistence Mesh Works

The infection typically begins with a .user.ini directive that sets auto_prepend_file to a hidden loader in wp-content. The loader reconstructs the plugin from existing copies, an encoded stub, or a ZIP archive. From there the system expands.

wp-content/db.php holds the full payload in gzipped, base64 format: if the plugin is missing, it rewrites it. wp-content/advanced-cache.php has five recovery sources: the must-use plugin, the ordinary plugin, System V shared memory, a ZIP archive, and the database. The active theme, via an injected block in functions.php, serves as an additional node. The payload is installed simultaneously as a must-use plugin and a conventional plugin, complete with a fake settings page.

Database persistence occurs through a row in wp_options with a random name containing the compressed payload. System V shared memory hosts PHP code that survives file deletion on disk. According to Sucuri, the result is "a circular system with no single point you can remove to stop it."

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

Decentralized C2 on the Ethereum Blockchain

The malware does not rely on blockable malicious domains. The payload carries a list of roughly twenty public Ethereum RPC gateways and a set of smart contract method selectors. It sends requests to these gateways to read encrypted instructions from a smart contract.

This architecture eliminates the traditional C2 chokepoint: there is no server to blackhole and no domain to seize. The source does not specify the exact smart contract addresses. The use of legitimate public infrastructure also makes it difficult to distinguish malicious traffic from ordinary traffic at the network monitoring level.

Obfuscation Strategy and Active Capabilities

The payload filters the plugin list, the update transient, and the site and network plugin views to remove its own entry. It also emits administrative JavaScript to delete itself from the plugin table as a fallback measure. This hiding occurs at the presentation layer, not the presence layer: the code remains active while the administrator cannot detect it in the interface.

Documented capabilities include site profiling, collection of administrator session tokens, frontend JavaScript injection, removal of security plugins, and e-commerce skimming. The source does not quantify the number of compromised sites or confirmed financial losses. The initial infection vector has not been determined.

Why Traditional Removal Is Counterproductive

The .user.ini directive generates a PHP cache that, according to the secondary source CyberSecurityNews, can last approximately three hundred seconds. Improper removal of the file causes PHP requests to fail for the residual cache period. This means a partial or sequential cleanup attempt exposes the site to a double blow: functional downtime and complete backdoor regeneration.

The operational paradigm requires a radical shift. Current file-centric cleanup playbooks, based on identifying and deleting known payloads, are structurally inadequate. What emerges clearly is the impossibility of treating SC as an infection to "clean": the infected system must be considered compromised in its entirety.

Immediate Actions

For teams managing WordPress installations, the Sucuri brief indicates three concrete actions specific to the SC case.

First: verify the presence of the .user.ini directive with auto_prepend_file in wp-content, which is the typical persistence entry point. Its presence activates the hidden loader and the regeneration cycle.

Second: inspect the drop-ins wp-content/db.php and wp-content/advanced-cache.php, which contain respectively the full payload in gzip+base64 and the five-source recovery mechanism. These legitimate caching and database files are overwritten by SC to function as bootstrap nodes.

Third: check the active theme, specifically functions.php, for injected blocks that serve as an additional recovery node. The brief documents that the active theme is an active persistence vector, not a passive target.

Verification must cover all eight persistence primitives before any remediation action: .user.ini, hidden loader, db.php, advanced-cache.php, theme injection, must-use plugin, conventional plugin, and System V shared memory. Sequential or partial removal triggers recovery within seconds.

Why This Matters

The dossier does not specify how the initial compromise occurs, nor does it provide invariant indicators of compromise: the reported filenames vary by site. It does not document the actual presence of database triggers in observed variants, described as present in "related variants" but not confirmed for the core SC. The exact System V shared memory segment key has not been disclosed.

The brief does not list specific operational actions beyond verification of the primitives. The source does not describe containment methods, rebuild procedures, or automated detection tools. These limits make the piece a signal rather than a prescription: the value lies in documenting the existence of a threat class that renders traditional cleanup approaches obsolete.

The evolution of threat actors toward persistence that exploits legitimate CMS mechanisms signals a research direction for security vendors and organizations managing WordPress fleets. The problem is no longer the single infection: it is the CMS bootstrap topology itself, transformed into a self-regenerating attack surface.

Information is based on the cited Sucuri analysis and current as of publication.

Sources

Sources and references

Get DeafLetter