WordPress Backdoor Rebuilds Itself Seconds After You Delete It and Takes Its Orders From Ethereum

A WordPress backdoor was deleted and came back within seconds. Deleted again, back again. It lived in at least 8 places, the server’s memory too, and had a hidden admin that could log in without a password.

That is what the cleanup team at Sucuri ran into on a site they were called in to fix. They removed the malware carefully, file by file, and the same backdoor kept returning within seconds of each removal. Their analyst Gabriel Barbosa published the full breakdown on 30 September. The researchers call the family SC, after the “SC_” markers they found in the injected code.

It kept coming back because each copy can write the others to disk again. In the researchers’ words: “Delete the plugin and a drop-in rewrites it. Delete the drop-in and the theme rewrites it.” Clean the files on disk, and the next page load brings them all back from the database or from a block of shared memory.

These are the places they found it on that site. The file names change from site to site, so this is what it looked like here:

1
2
3
4
5
6
7
8

.user.ini
wp-content/c1b12371.php
wp-content/.c1b12371.php
wp-content/db.php
wp-content/advanced-cache.php
wp-content/themes/khorshidi/functions.php
wp-content/mu-plugins/hyper-engine-kit.php
wp-content/plugins/hyper-engine-kit/hyper-engine-kit.php

The .user.ini file is a small settings file that PHP reads per folder. One line in it, auto_prepend_file, makes PHP run a chosen file before any PHP request in that folder and the folders below it. That includes requests that never reach WordPress. The chosen file is short and plain-looking, a loader: its only job is to load a hidden file next to it, the one whose name starts with a dot. Delete only the hidden file and the loader quietly does nothing. The site stays up and looks fine while another copy rebuilds the hidden one.

db.php and advanced-cache.php are drop-ins, files WordPress loads on its own very early, before ordinary plugins. db.php carries the full backdoor inside itself, compressed and encoded. WordPress loads advanced-cache.php whenever caching is on, and this one can rebuild the backdoor from five different sources in a fixed order. The theme gets a block of code added to the bottom of functions.php, which runs on nearly any page, and that block does the same job.

The backdoor itself sits in two places. One copy is a must-use plugin, which WordPress loads automatically and out of sight. The other is a normal plugin with its own settings page, so a quick look makes it seem like a caching plugin. The two copies keep each other on the same version. When the loader writes a fresh copy, it tells PHP to drop the old cached version so the new file runs straight away.

The code is hard to read. Each file holds a table of scrambled strings and a small decoder that turns a number into the function name it stands for. The names you would search for are not in the file. SC runs without eval, the PHP function that runs a piece of text as code, and the newest pieces carry no marker.

Clean files are still not enough. The researchers found live copies of the backdoor in three places that are not files. A full copy of the backdoor sits in a row of the WordPress options table in the database, under a random name. On servers that support it, the backdoor also writes a copy into shared memory, a block of the server’s RAM, under a fixed number. That copy survives file deletion and a database cleanup alike, and on shared hosting the block can even belong to another account.

The third place is scheduled tasks. The server’s own cron runs the WordPress task file on a timer, without any visitor, and that puts the files back on schedule.

Related SC variants went one step further, with a trigger inside the database itself that creates a new administrator when a new row goes in. Delete the account, and the next new row brings it back.

The backdoor also gives the attacker a way in that you cannot see. It creates an administrator account, or takes over a hidden one that is already there, and when the normal route is blocked it writes that account straight into the users tables. Then it filters the account out of the user list and the user counts, and out of the view per role. Your dashboard shows the admins you know, and the extra one may not be on the list. It forges valid login cookies for that account, so the attacker can log in without a password.

It hides itself the same way. It removes its own line from the plugin list and from the update checks. As a backup, it runs a bit of JavaScript in the admin screen that scrubs it from the plugin table. When the attacker tells it to, it switches off a security plugin and wipes that plugin’s folder, and it can first change or raise the rights of another account.

The attacker can send the site one specific request, a short prefix with a fixed value, and the backdoor picks it up before WordPress has finished loading. As long as the backdoor is there, that request gets a normal page back, which tells them from outside that the backdoor is still in place. The researchers call it a live beacon.

For its orders, the backdoor carries a list of about twenty public Ethereum gateways, services that read data from the blockchain on request. It asks those gateways to read its instructions from a smart contract. Block the one gateway you see in your logs and the backdoor moves to the next, so they have to be blocked as a set.

Hiding instructions on a blockchain is older than SC. In October 2023 the researchers at Guardio Labs named it EtherHiding. Hacked WordPress sites read code from a smart contract on the BNB Smart Chain and showed visitors a fake browser update, which installed info-stealers such as Lumma. Their point back then was that once the contract is on the chain, Binance cannot simply shut it down.

On 16 October 2025, Google’s threat intelligence team reported about 14,000 web pages where one group using the method had injected its code, up to June that year. Reading from a contract this way costs nothing and creates no transaction. Changing what the contract says cost the attackers between 0.25 and 1.50 dollars a time.

The same day, the team wrote that UNC5342, a group it links to North Korea, had been using EtherHiding since February 2025, on Ethereum as well. The group spreads malware through fake job interviews and steals cryptocurrency. It was the first time the team had seen a state-backed group adopt the method. That link is the team’s assessment of that one campaign. The researchers who found SC do not say who is behind it.

In the WordPress campaigns of 2023 and 2025 the lookup ran as JavaScript in the visitor’s browser. SC does the lookup from PHP, on the web server itself. The researchers list requests going out from the web server to Ethereum gateways as one of the signs of infection.

A backdoor did the same from the server earlier this year. In April 2026, someone bought a set of more than 30 WordPress plugins and planted a backdoor in them. It wrote itself into wp-config.php and, from PHP, asked an Ethereum smart contract for the address of its command server through public gateways. On 7 April the WordPress.org plugin team closed 31 of those plugins in a single day. Austin Ginder of the WordPress hosting company Anchor Hosting wrote it up two days later. Nothing in his write-up or in Sucuri’s links the two cases.

SC collects the site’s URL and host, the WordPress and plugin versions, the active themes and the must-use plugins. It takes the session tokens of the administrators who are signed in at that moment, the keys that keep them logged in. It encrypts all of that and sends it off. The reply can contain new PHP to install, a list of security plugins to remove, and JavaScript to inject into the pages your visitors load. On a web shop, the researchers write, that script enables checkout skimming, code that copies the card details customers type in at the checkout.

The researchers have not said how many sites carry SC. WordPress runs 40.1 percent of all websites, according to W3Techs.

The write-up also does not say how SC got onto this site. The researchers say most hacked sites they clean were broken into through old holes in plugins, themes and other parts that already had a fix.

Cleaning SC out means doing it in the right order, in one go. Delete files first and the remaining copies write them back. The approach that works, the researchers write, is to stop the code from running, clear the copies that are not files before the ones that are, and only then remove the files. The order they give:

• → Make the .user.ini line harmless first. PHP remembers that setting for up to 300 seconds. Delete the file it points to while PHP still remembers it, and PHP requests on the account fail until the time runs out. So you empty that file first, then take the line out of .user.ini, php.ini and .htaccess.
• → Then the copies that are not files: the row in the options table, the shared-memory block and the extra settings the backdoor stores next to it. On shared hosting the memory block may belong to another account. In that case only that account or the host can remove it, and it does nothing once the drop-ins that read it are gone.
• → Then the scheduled tasks, and any database trigger that creates an administrator.
• → Then the hidden administrator account.
• → Only then the files, in one pass, including both plugin copies, the ZIP restore file and the injected block in functions.php.
• → Scan again and keep watching. A file that comes back means a copy survived, or the way in is still open.

Afterwards, close the hole it came in through, and change the passwords and keys the attacker could have touched.

Where to look on your own site:

• → .user.ini, php.ini or .htaccess with an auto_prepend_file line that points at a hidden file
• → wp-content/db.php and wp-content/advanced-cache.php that you or a plugin you know did not put there
• → A plugin that sits in both mu-plugins and plugins with the same contents
• → A ZIP file with a random hex name in wp-content, wp-content/uploads or a theme folder
• → A large, encoded value in the options table under a name you do not recognise
• → Administrators in the database’s users table that do not show up in your dashboard
• → Requests from your web server to public Ethereum gateways

If something you deleted keeps coming back, a copy is still alive somewhere off the disk, or a scheduled task is still set. Deleting the same file again will not fix it.

Want to see what your own site loads before any plugin? Open wp-content and check who put db.php and advanced-cache.php there. My Ethical Hacking Complete Course Zero to Expert takes you there step by step: reconnaissance, scanning, exploitation and traffic analysis, hands-on, from your first day with no Linux or hacking background.

→ Join my complete ethical hacking course

Hacking is not a hobby but a way of life.

Sources:

Sucuri | Guardio Labs | Google Threat Intelligence