- Sucuri analyzed a WordPress infection, named SC, that kept itself in at least eight places across files, the database and shared memory, each able to rebuild the others.
- Deleting files alone fails, because the next page load restores them. Cleanup has to follow a set order, with off-disk copies cleared first.
- Ask your host and security team whether incident runbooks cover the database, scheduled tasks, triggers and shared memory, not only files.
Cleanup is often framed as deletion. Find the bad file, remove it, move on. Sucuri's analysis of one WordPress compromise shows why that framing can fail. In this case, the surviving copies rebuilt the infection on the next page load.
The lesson is that an infection can be a system, not a file. A system has to be dismantled in the right order. Anyone who has deleted a file and watched it reappear has felt this.
Sucuri does not say this case involved a store. But the report notes what the backdoor can be told to do on one. On a store, the same backdoor can be told to inject checkout-skimming code, so every hour it survives is an hour of risk to customers.
What Sucuri found
Sucuri's analyst Gabriel Barbosa described a backdoor that kept coming back within seconds of every removal. Sucuri calls the family SC, after "SC_" markers in the injected content.
The payload lived in at least eight places at once. Those places spanned files, the database and shared memory. Each could rebuild all the others.
Sucuri does not say how many sites carry SC. The report also does not say how the malware first got in. The Hacker News, which covered the report, notes the entry point is not known. That matters, because a cleanup that leaves the entry open invites a repeat.
How the loop works
WordPress loads certain files automatically and early. Two of them are "drop-ins", named db.php and advanced-cache.php. Sucuri found SC inside both. A third copy sat at the bottom of the active theme's functions.php file.
The main payload posed as a caching plugin. It was installed twice, once as a normal plugin and once as a "must-use" plugin. The must-use copy, Sucuri says, loads automatically and invisibly. The fake plugin even had a convincing settings page.
The deeper copies sit off disk. The full payload was stored in a database row under a random name. On servers that support it, another copy lived in shared memory, which is a block of RAM. Sucuri says that copy survives file and database cleanup. On shared hosting it can belong to a different account.
The advanced-cache.php drop-in could rebuild the plugin from five sources in order. They were an existing must-use plugin, an existing plugin copy, shared memory, a ZIP bundle, and the database. Scheduled tasks also triggered redeployment.
What the backdoor does once running
The payload hides from the admin plugin list and from update checks. It also creates a hidden administrator. It writes the account straight into the database and forges login cookies, so the operator needs no password.
To receive orders, the malware holds the addresses of about twenty open Ethereum access points. It queries them to read commands stored in a smart contract.
Blocking the one address that showed up in traffic would not cut the line. The others are ready to take over. Defenders need to block the whole list together.
What comes back from the contract can push script into the pages visitors see. It can also deliver fresh PHP to install, plus a hit list of security plugins to switch off and erase. Sucuri also saw database triggers in related variants. A trigger recreates an administrator whenever the account is deleted.
Why the order of cleanup decides the outcome
Sucuri describes a workable order in three moves. Stop the code from running. Clear the copies held in the database and memory. Then delete the files together, in one pass. Deleting files early only prompts the surviving copies to rewrite them.
One step carries its own risk. A setting called auto_prepend_file runs a loader before every PHP request. PHP caches that value for up to 300 seconds. Delete the target file while the cache is warm and every PHP request on the account fails. Sucuri advises emptying the file first, then removing the directive.
Questions to put to your team and host
First, does your incident runbook cover more than files? Sucuri says SC keeps its foothold in database settings, cron jobs, triggers and the user list. Ask who reviews those, and how often.
Second, who can clear shared memory on your hosting? Sucuri says only the owning account or the host may be able to remove a segment. Know that answer before an incident.
Third, does anyone watch outbound traffic from the web server? Sucuri lists requests to public Ethereum gateways as a sign of infection.
Fourth, after cleanup, are credentials rotated and the original entry point closed? Sucuri says a returning file means a persistence point survived or the entry path is still open. Treat a reappearance as unfinished work, not a new incident.
A cleanup that ends at the file system may end too early. The sources describe an attacker who planned for the defender's first move.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Sucuri.
