SC WordPress Malware: Why Deleting the Backdoor Is Not Enough

A WordPress backdoor investigated by Sucuri can return within seconds after an administrator removes the infected files. The malware, identified as SC WordPress malware, spreads copies of its payload across WordPress files, the database, scheduled tasks and, on some servers, shared memory, turning cleanup into a persistence problem rather than a simple file-deletion job.

SC WordPress malware is built around redundancy

Sucuri found the infection during real website cleanup work and documented at least eight cooperating components. Several sit in familiar WordPress locations, including db.php, advanced-cache.php, the active theme's functions.php, a normal plugin and a must-use plugin, while other copies can exist outside the ordinary plugin directory. A must-use plugin is a WordPress plugin that loads automatically without needing to be activated through the normal Plugins screen, which makes it particularly useful for persistence.

The important detail is that these components are not independent infections. Sucuri found that surviving pieces can reconstruct missing pieces, so removing the most obvious malicious plugin does not necessarily remove the mechanism that restores it. That explains why a site can appear clean immediately after an administrator deletes suspicious PHP files and then become infected again when another request triggers one of the remaining loaders. The malware therefore behaves more like a recovery system for the attacker than a collection of unrelated backdoor files.

Why deleting the plugin can fail immediately

One of the recovered persistence paths uses WordPress's db.php drop-in. WordPress loads this file early during its startup process, and Sucuri found a copy of the payload stored inside it in compressed and encoded form. If the fake plugin disappears or becomes smaller than expected, the drop-in can decode its stored copy and write the plugin back to disk.

The advanced-cache.php drop-in adds another recovery path. When WordPress caching is enabled, this file loads before ordinary plugins and can search several locations for another copy of the malware, including a must-use plugin, a normal plugin, a shared-memory segment, a restore archive and the database. That means a cleanup focused only on the plugin directory is looking at one branch of a much larger system.

The database becomes part of the malware's storage

SC also stores the payload in a WordPress database options row using compressed and encoded data. This matters because a database backup or restore can otherwise be treated as a trusted recovery point; if the malicious option survives the restoration, the site's own bootstrap code may simply recreate the deleted files. Sucuri also documented control options and transient data associated with the malware family, giving investigators additional places to look when reviewing a compromised installation.

Database persistence changes the order in which an incident should be handled. Removing files before disabling the mechanisms that can execute or recreate them can produce a temporary improvement without actually breaking the infection cycle. A proper investigation therefore has to consider the WordPress database alongside the filesystem rather than treating the database as an unrelated source of application data.

Shared memory creates a persistence layer outside the files

The most unusual component Sucuri documented is a copy of the PHP payload held in System V shared memory, a mechanism that allows processes to share data through memory managed by the operating system. Because that copy is not an ordinary file, deleting everything under the WordPress directory does not remove it. Sucuri also noted that on shared hosting, the memory segment may be associated with a different account, which makes this persistence method harder to spot during a routine file cleanup.

This is the point where the incident stops looking like conventional WordPress malware. A file scanner can report a clean directory while an executable copy still exists elsewhere on the server. If another surviving component can retrieve that copy and restore the site's files, the apparent cleanup has not actually removed the attacker's foothold.

SC also uses WordPress itself as a recovery mechanism

The infection modifies more than plugin files. Sucuri found injected code in the active theme's functions.php, PHP configuration that can use auto_prepend_file to load a hidden file before normal application code, and scheduled tasks that can trigger redeployment. The auto_prepend_file mechanism is especially significant because it operates at the PHP configuration level and can run before WordPress handles a request normally.

The fake plugin copies are another example of the same strategy. Sucuri found the backdoor installed both as a normal plugin and as a must-use plugin, with the latter providing automatic loading even when the administrator does not see an active plugin that looks suspicious. In related SC variants, the researchers also observed database triggers capable of recreating an administrator account, showing why user cleanup by itself cannot be treated as proof that the compromise has ended.

The Ethereum connection is about command delivery, not cryptocurrency theft

SC also hides its command-and-control traffic behind public Ethereum remote procedure call gateways. A remote procedure call gateway is a service that lets software communicate with a blockchain node without running its own node, and Sucuri found the malware using public gateways as part of its command infrastructure. The practical consequence is that defenders are not simply looking for one attacker-owned server that can be blocked at the network edge.

The blockchain connection does not mean the malware itself is a cryptocurrency wallet or that the infection depends on stealing coins. In this case, the blockchain infrastructure is being used as a communication mechanism that makes the attacker's command channel harder to treat like an ordinary fixed server. That distinction matters during incident response because blocking one suspicious hostname may not eliminate the mechanism the malware uses to discover further instructions.

What defenders should look for on an infected WordPress site

Sucuri's indicators provide a practical starting point for an investigation. Administrators should examine unexpected PHP content in wp-content/db.php, wp-content/advanced-cache.php and the active theme's functions.php, along with suspicious .user.ini, php.ini or .htaccess entries that introduce an auto_prepend_file directive. Duplicate or unfamiliar plugins in both normal and must-use plugin directories also deserve inspection, particularly when they contain matching payloads or pretend to be legitimate utilities.

The database needs its own investigation rather than being checked only after the filesystem. Sucuri recommends looking for unusually large compressed and encoded values in WordPress options, suspicious control data, unexpected administrator accounts and residual records associated with those accounts. Investigators should also consider shared-memory contents and scheduled tasks where the hosting environment permits that level of inspection.

The cleanup problem is bigger than the malware file

A durable response has to break the recovery chain rather than repeatedly deleting whatever file appears next. That means isolating the affected site where practical, preserving relevant evidence, disabling the mechanisms that execute the malware, removing every persistence copy, checking the database and server-level components, and closing the original access path once it is identified. Credentials that may have been exposed should also be rotated because a clean filesystem does not invalidate credentials an attacker may already possess.

The distinction is important for WordPress administrators because the visible symptom can be misleading. If a malicious plugin returns after deletion, the useful question is not “where is the new file?” but “which surviving component recreated it?” Sucuri's analysis shows that answering that question requires treating the WordPress installation, its database and the underlying server as one connected incident rather than three separate cleanup jobs.