Skip to content
hacker_posts

WordPress 'SC' malware self-heals via eight footholds, blockchain C2

Sucuri details 'SC,' a WordPress backdoor that rebuilds itself from eight files plus a DB drop-in and shared memory, and reads C2 instructions from Ethereum smart contracts.

Published 3 min read
researchwordpressmalwarebackdoor

Sucuri analyst Gabriel Barbosa has documented a WordPress backdoor — tracked as "SC" after the SC_ markers in its injected code — built so that deleting any one component triggers the others to rebuild it. Cleanup in the usual order leaves the site reinfected. The persistence spans eight on-disk and off-disk locations, and the command channel is pulled from Ethereum smart contracts instead of a hardcoded server.

Why "delete the file" doesn't work

Barbosa's teardown lists a mesh where each node can regenerate the rest. In his words: "Delete the plugin and a drop-in rewrites it. Delete the drop-in and the theme rewrites it." The footholds, per Sucuri:

.user.ini                                    # sets auto_prepend_file
wp-content/c1b12371.php                       # shim loader
wp-content/.c1b12371.php                       # string-table loader (rebuilds mu-plugin)
wp-content/db.php                             # DB drop-in; full payload as gzip+base64
wp-content/advanced-cache.php                 # rebuilds plugin when WP_CACHE is set
<active-theme>/functions.php                  # appended payload block
wp-content/mu-plugins/hyper-engine-kit.php    # self-hiding backdoor
wp-content/plugins/hyper-engine-kit/...       # redundant copy

Off disk, the payload also lives as a gzip+base64 blob in a wp_options row, in a System V shared-memory segment keyed to a fixed number (so it survives file deletion and database cleanup), and behind cron hooks with randomized names that redeploy on a schedule. A hidden administrator account and information_schema.TRIGGERS entries can recreate the admin after removal.

The blockchain C2

Rather than a static domain, SC carries "a list of roughly twenty public Ethereum RPC gateways and a set of smart-contract method selectors," Sucuri says, and reads its instructions from a smart contract via those gateways. Blocking one gateway accomplishes nothing — the entire set has to go. It's a resilience trick, not a cryptomining angle: the chain is just an un-takedownable place to publish the next C2 address.

Exploitation status

This is confirmed, in-the-wild tooling analyzed from live infections; Sucuri attributes it to no named actor. The initial-access vector isn't the story here — SC is what gets dropped after a compromise, and its point is to outlast incident response.

Action checklist

Sucuri's removal order matters — do it in this sequence or expect reinfection:

  1. Neutralize the prepend first. Empty the auto_prepend_file target to an inert stub, then strip the directive from .user.ini, php.ini, and .htaccess.
  2. Clear the off-disk copies. Delete the payload row from wp_options, purge the System V shared-memory segment, and remove control options and transients.
  3. Kill the schedulers. Remove the malicious cron hooks and audit information_schema.TRIGGERS for admin-recreation triggers.
  4. Delete the hidden admin whose capabilities are stashed under the default capabilities meta key.
  5. Remove the files in one pass — both hyper-engine-kit copies, the loaders, the shim, the drop-ins (db.php, advanced-cache.php), and any ZIP bundles.
  6. Rescan. Any file that returns means a foothold survived or the entry vector is still open.

Context

Self-healing WordPress infections aren't new, but SC pushes the model to its logical end: redundancy across the config layer, the plugin layer, the theme, the database, and volatile memory at once, fronted by a C2 you can't seize. For anyone cleaning a compromised site the lesson is the one that keeps recurring across WordPress compromises — a half-cleaned site is a reinfected site. Treat SC as a full rebuild-from-known-good candidate unless you can account for every foothold above.

Related stories