Self-Healing WordPress Malware: Why the Hack Keeps Coming Back

Why the hack keeps coming back

Most WordPress infections have a bit of redundancy. An attacker drops a web shell and a spare admin account, and a careful cleanup gets both. SC goes much further. Sucuri describes it as "a circular system with no single point you can remove to stop it."

Its own example makes the point: "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."

So the owner who keeps deleting files isn't failing at cleanup. They're feeding a loop. Each partial fix leaves at least one copy alive, and that copy restores the rest on the next request. Many owners give up at this point and assume the site is cursed, or that their host is the problem. Neither is true. The malware was simply built to outlast a manual cleanup.

Where self-healing WordPress malware hides

Here's what Sucuri recovered from one infected site. File names vary from site to site, so treat these as shapes to look for, not exact names.

Then come the copies that aren't files at all. The full payload sits in a randomly named row in the options table. On servers that support it, another copy sits in a System V shared-memory segment, which lives in RAM and survives both file deletion and a database cleanup. Scheduled tasks put the set back on a timer. Sucuri also saw related variants add database triggers that recreate an administrator whenever a row is inserted, which survive even a full file restore.

There's another reason it survives. Many malware scanners look for eval, long base64 strings or well-known shell names. Sucuri found none of that in SC. Every file carries a table of scrambled strings and a small decoder that turns a number into a function name, with no eval, no readable function names and, on the newest pieces, no marker at all. A scanner that only matches known strings can report a clean site while all eight copies keep running. That's why the checks below look at where code runs, not just at what it says.

Key finding

A file-only cleanup can't beat SC. The copies in the database and in shared memory restore every file on the next page load.

What the SC backdoor does to your visitors

The rebuilding is only there to protect the payload, and the payload is where the damage happens. It hides from the Plugins screen and from update checks, so the site looks normal to its owner. It creates a hidden administrator and forges login cookies for it, so the attacker never needs a password. If you've read our analysis of the Admin Menu Editor Pro backdoor, the hidden-account trick will look familiar.

It also reports home, and not to a server you can block. The payload carries a list of about twenty public Ethereum gateways and reads its instructions from a smart contract. Block one gateway and the rest still work. Each check-in sends the site's details and the current administrator session tokens, and the reply can carry new PHP to install. It can also carry a list of security plugins to switch off and delete.

The reply can also carry JavaScript to inject into the front end. On a store, Sucuri notes, that means checkout skimming: your customers type their card details into your checkout, and a copy goes to someone else. At that point the hack isn't just your problem. It's theirs, and it lands on your business.

The cleanup order that actually works

Because each piece can rebuild the others, the order of the steps matters more than the steps themselves. Sucuri's approach cuts off execution first, clears the copies that aren't files next, and removes the files last, all in one pass. Take a full backup of files and database before you start, even an infected one, so you have something to compare against.

1. Defuse the prepend before you delete it. PHP caches the auto_prepend_file setting for up to 300 seconds. Delete the file it points at while the cache is warm and every PHP request on the account fails. Empty the target to a harmless stub first, then remove the directive from .user.ini, php.ini and .htaccess.
2. Clear the off-disk copies. Delete the payload row from the options table, along with the control options and transients that use an sc_ style prefix. Purge the shared-memory segment. On shared hosting another account may own it, so you may need your host for that step.
3. Remove scheduled tasks and database triggers. Clear the malicious cron hooks, then check information_schema.TRIGGERS for anything that recreates an administrator.
4. Remove the hidden administrator. Look in the database directly, because the account is filtered out of the Users screen, and remove the orphaned option that points at its ID.
5. Then remove the files, all in one pass. Take out the shim and its hidden loader, both copies of the fake plugin, the injected theme block, the db.php and advanced-cache.php drop-ins and the ZIP restore bundle.

Afterwards, reinstall WordPress core, plugins and themes from fresh downloads, rotate every password and the salts in wp-config.php, and watch the site for a week. If anything returns, a copy was missed, and you go back to step one. Our WordPress malware removal guide covers the general process, and our guide to PHP backdoors in WordPress explains where the less exotic ones hide.

Signs you're dealing with self-healing malware

You don't need to read obfuscated PHP to spot this family. These are the signs Sucuri lists, in plain terms:

• Code you didn't write inside wp-content/db.php or wp-content/advanced-cache.php, starting with an SC_ style marker.
• A fenced block at the bottom of your theme's functions.php.
• An auto_prepend_file line in .user.ini, php.ini or .htaccess that points at a hidden or unfamiliar PHP file.
• The same plugin in both mu-plugins and plugins, with a believable settings page.
• A ZIP file with a random hex name in wp-content, in uploads or in a theme folder.
• Your web server making outbound requests to Ethereum gateways.

And the biggest sign of all: a hack that keeps coming back after you've cleaned it. Our list of signs your WordPress site is hacked covers what visitors and search engines see first.

Sucuri doesn't say how SC got onto the site it studied, so don't read this as a warning about one plugin. Treat it as a warning about method. It's also not the only way back in this month. In the UpdraftCentral hack, attackers simply reinstalled their backdoor with a stolen key until site owners deleted it.

Get it cleaned properly the first time

Our $1 deep scan checks the places SC hides. It flags an auto_prepend_file pointing at a hidden or misplaced file, administrators hidden from the Users screen, unknown must-use plugins and suspicious cron jobs. If it finds an infection, our $49 cleanup removes it, starting with the rebuild sources rather than the files. Our cleanup tooling already covers the SC drop-ins, the database payload rows and the rogue admin accounts. The first cleanup is free for new users.

If you've already cleaned a site twice and it came back, stop deleting files. You're feeding the loop. Scan it, and let the rebuild sources go first.

References

• Sucuri: SC WordPress Malware, a Self-Healing Mesh of Loaders, Drop-ins and a Blockchain-Controlled Backdoor
• The Hacker News: WordPress Backdoor Rebuilds Itself After Cleanup
• PHP manual: auto_prepend_file