The Backdoor You Can’t Delete: WordPress Malware That Regenerates After Removal

 

SC WordPress backdoor is specifically engineered to rebuild itself after cleanup, using a self‑healing mesh of persistence layers across files, the database, and shared memory. Removing visible malware does nothing if even one persistence node survives. 

The SC backdoor is not a single file — it’s a redundant network of loaders, drop-ins, fake plugins, database payloads, and shared-memory segments. Each component can recreate the others, forming a circular recovery loop.

Core behaviors

• Lives in at least eight locations at once (files, DB, shared memory).

• Any surviving component rewrites missing ones on the next page load.

• Uses early‑loading WordPress hooks (auto_prepend, drop-ins, mu‑plugins).

• Stores full payloads in the database and in System V shared memory, allowing reinfection even after disk cleanup.

• Hides itself from plugin lists and update checks, and can forge admin cookies.
  
  

Deleting the malicious plugin or file does not remove the backdoor.
Here’s how the regeneration loop works:

Persistence Layer	What It Does	How It Rebuilds Others
.user.ini	Forces PHP to load a malicious loader before WordPress	Recreates loaders and plugins from DB/shared memory
Hidden loaders (.c1b12371.php)	First-stage loader	Rebuilds fake plugin from cache, ZIP bundle, or DB
advanced-cache.php	Runs before normal plugins	Restores plugin from 5 sources including shared memory
db.php	Contains full payload encoded	Rewrites plugin whenever missing or too small
Theme functions.php	Twin of db.php	Recreates plugin every page load if absent
Database payloads	Full backdoor stored in wp_options or posts	Rewrites files on disk via loaders
Shared memory segment	Payload stored in RAM	Rehydrates disk + DB after cleanup until reboot

This is why the malware “comes back within seconds” after removal. 

This is not a WordPress vulnerability — it’s a post‑exploitation persistence framework deployed after attackers gain access (usually via plugin CVEs, stolen credentials, or upload abuse). 

To eradicate it, defenders must:

1. Identify every persistence layer

Sucuri’s analysis shows SC hides in:

• mu‑plugins

• drop-ins

• wp-content loaders

• theme functions

• wp_options autoload entries

• shared memory

• ZIP restore bundles

• fake plugin directories
  

2. Clear shared memory

The payload can survive:

• full disk cleanup

• database cleanup
  until the server is rebooted or memory segments are manually cleared.
  

3. Audit server-level crontab

Attackers often add cron jobs outside WordPress to redeploy payloads.

4. Rebuild WordPress core from known-good sources

Because SC modifies early-loading components, replacing core files is mandatory.

5. Rotate all credentials

SC can:

• hide admin accounts

• steal admin session tokens

• forge authentication cookies
  
  

If a WordPress backdoor keeps reappearing, you’re not failing at cleanup — you’re dealing with a persistence mesh designed to regenerate itself.
You must remove every persistence node at once, including memory, database, and server-level tasks, or the infection will simply grow back.