Security1 publisher3 min readPublished
Sucuri's SC backdoor rebuilds a hacked WordPress site from any of eight surviving copies
Sucuri says a WordPress backdoor it calls SC keeps itself in at least eight places across files, the database and shared memory. Cleaning the plugin or wiping files on disk does not clear it, because any surviving copy rewrites the rest on the next page load.
The Watch · Security desk
What happened
- That shared-memory copy lives in RAM, so it outlasts the two layers a standard cleanup touches: deleting files on disk and wiping the database.
- Cron hooks with randomized names redeploy the payload on a schedule through WordPress's own cron file, so it refreshes even with no visitor traffic.
- Sucuri does not know how the site was first compromised, citing the usual routes: unpatched flaws, weak credentials, plugin supply-chain attacks, and insecure upload features.
Compiled by The WatchSomething wrong?How this is made
Why it matters
- constraint Deleting the fake plugin or wiping files leaves at least one copy behind, and it rewrites the rest on the next request, so routine cleanup returns a still-infected site.
- decision Eviction now has to hit files, database and shared memory in one pass, flush the RAM segment, and strip the cron hooks, not just remove a plugin.
- exposure On shared hosting the RAM segment can belong to a different account, so a site owner scrubbing their own files has no way to reach the copy that reinfects them.
- capability Routing command-and-control through the Ethereum blockchain puts the channel inside legitimate infrastructure, so defenders cannot cut it by blocking one malicious domain.
The rebuild fires on every page load. A .user.ini file sets auto_prepend_file, so a loader runs before every PHP request in that directory tree [6]. The loader pulls in a hidden, dot-prefixed file [7], which finds the fake plugin and rebuilds it in mu-plugins from three sources: a copy already in the plugins folder, an encoded stub in the cache directory, and a ZIP restore bundle with a random hex name [8].
"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," security researcher Gabriel Barbosa said [3]. "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 you can remove to stop it" [4].
Two drop-ins carry the payload in full. wp-content/db.php loads during bootstrap and holds the entire backdoor compressed and Base64-encoded, re-deploying the plugin whenever it goes missing or shrinks [9]. wp-content/advanced-cache.php loads before ordinary plugins when caching is on and rebuilds the plugin from five independent sources, including the database and a System V shared-memory segment holding PHP [10]. The khorshidi theme's functions.php is a twin of db.php and rewrites the plugin whenever it is absent [11]. The fake plugin, hyper-engine-kit, sits in two locations at once, as a must-use plugin and as a normal one [12]. Sucuri calls the result a "self-healing mesh" and codenamed it SC after the "SC_" markers in the injected content [2][1].
The shared-memory copy is the piece a file-and-database cleanup misses. "On servers that support System V shared memory, the payload is written into a segment identified by a fixed numeric key," Sucuri said. "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" [15].
A scheduled task keeps the loop running without a visitor. "The infection 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," Sucuri said [16].
The code hides what it does. There are no readable function names; a decoder unscrambles it with a substitution cipher [5]. Once running, the backdoor hides itself from the admin plugins screen and from update checks, creates a hidden administrator account, and reaches its command-and-control server over the Ethereum blockchain [13]. From there the operator can inject arbitrary JavaScript to hit visitors with skimmers, run PHP, and deactivate or delete plugins [14].
How the site was first breached is not known. Sucuri lists the usual routes in: known flaws in WordPress, plugins and themes; weak login credentials; supply-chain attacks on popular plugins; and insecure upload features used to push PHP web shells onto the server [17].
What to watch
- Whether Sucuri releases indicators of compromise or the initial access vector for SC.
- Whether hosting providers add shared-memory flushing and cron removal to their WordPress cleanup guidance.
- Whether the khorshidi theme and hyper-engine-kit names turn up on other infected sites, marking a wider campaign.