[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$f6OqL4oL9XMyuNFSBpRW1fDRsVxMnnX9jT0uP2_TmdS0":3},{"article":4,"iocs":51},{"id":5,"title":6,"slug":7,"summary":8,"ai_summary":9,"brief":10,"full_text":11,"url":12,"image_url":13,"published_at":14,"ingested_at":15,"relevance_score":16,"entities":17,"category_id":28,"category":29,"article_tags":33},"c38a6a36-3253-4a54-83f7-f2cb6b09c291","SC WordPress Malware: A Self-Healing Mesh of Loaders, Drop-Ins, and a Blockchain-Controlled Backdoor","sc-wordpress-malware-a-self-healing-mesh-of-loaders-drop-ins-and-a-blockchain-co-1fd76d","Overview During recent website cleanup work, we analyzed a WordPress compromise where the same backdoor kept returning within seconds of every removal, no matter how carefully the visible files were deleted. Throughout this article, we’ll refer to this family of malware as SC, named after the “SC_” markers found in the injected content. What makes SC worth documenting is how it survives. 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. Continue reading SC WordPress Malware: A Self-Healing Mesh of Loaders, Drop-Ins, and a Blockchain-Controlled Backdoor at Sucuri Blog.","A new WordPress malware family, dubbed SC, has been identified that employs a sophisticated self-healing mechanism to ensure its persistence. The malware resides in at least eight locations simultaneously, including files, the database, and shared memory, with each component capable of rebuilding the others. This circular system makes traditional cleanup methods ineffective, as removing one part of the infection triggers another to restore it.","SC WordPress malware uses a self-healing mesh to survive deletions via multiple persistent components.","OverviewDuring recent website cleanup work, we analyzed a WordPress compromise where the same backdoor kept returning within seconds of every removal, no matter how carefully the visible files were deleted. Throughout this article, we’ll refer to this family of malware as SC, named after the “SC_” markers found in the injected content.What makes SC worth documenting is how it survives. 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. 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.We’ll walk through each component of the infection, how they regenerate each other, what the core backdoor actually does, and the order of operations that a real cleanup has to follow.The Components We RecoveredEvery SC file we examined shares the same obfuscation scheme. There is no eval, no marker on the newest pieces, and no readable function names. Each file carries a table of scrambled strings and a small decoder that resolves a numeric index into a real function name through a positional substitution cipher. See the example below:Here is what each component does: The .user.ini trigger. A single line, auto_prepend_file, points PHP at a loader that runs before every request in that directory tree. This fires even on requests that never reach WordPress. The value is cached by PHP. That cache is why deleting the prepend target carelessly is dangerous. If the file it points at is removed while the cache is still warm, every PHP request on the account fails until the cache expires. The visible shim. The .user.ini points at a plainly named PHP file, and that file does one thing: if a hidden dot-prefixed file exists next to it, it includes it. The shim keeps the .user.ini value stable and innocuous while the real logic lives in the hidden file. If a defender removes only the hidden file, the shim silently does nothing and the site stays up, which buys the attacker time while another component recreates the hidden file. In this example, the file was named c1b12371.php, but the name varies from site to site. It is commonly located in the wp-content directory. The string-table loader. The hidden dot-prefixed file is the first real loader. It locates the fake plugin and rebuilds it in mu-plugins from three sources tried in order: an existing copy in the plugins folder, an encoded stub in the cache directory, and a ZIP restore bundle with a random hex name. It writes through a temporary file, sets mode 0644, and calls opcache_invalidate so the freshly written file executes immediately. It also defines a constant that ties it to the auto_prepend side of the family—for this example, named .c1b12371.php, also located in the wp-content directory. The db.php drop-in. WordPress loads wp-content\u002Fdb.php very early during bootstrap. This copy carries the entire backdoor payload inside itself as a gzip plus base64 blob. On any request where the fake plugin is missing or too small, it decodes the blob and writes the plugin straight back to disk. The advanced-cache.php drop-in. This is the earliest and most dangerous position of all. When caching is enabled, WordPress loads advanced-cache.php before ordinary plugins. Unlike the others, it does not carry the payload inline. It is a finder that can rebuild the plugin from five independent sources in order: an existing mu-plugin, an existing plugin copy, a System V shared-memory segment holding PHP, a ZIP bundle searched for across several folders, and finally the database itself. For the database path, it opens a direct connection using the site’s own credential constants and reads the payload out of a specific option row, decoding the same gzip format. Once it has a copy, it hooks plugins_loaded and includes it. The theme injection. The active theme’s functions.php runs on nearly every request. The attacker appended a bounded block to the bottom of an otherwise legitimate theme, fenced by begin and end markers. That block is the theme-resident twin of the db.php drop-in: it rewrites the plugin whenever it goes missing.and 8. The backdoor payload, in two places. The actual malware is a large WordPress-aware file installed as both a must-use plugin and a normal plugin. The two copies are identical. The plugin folder even ships a convincing fake settings page, a shortcode, and an activation hook in plain sight, so a quick look suggests a real caching plugin. The must-use copy loads automatically and invisibly. Keeping two copies is deliberate redundancy, and the payload competitively updates one from the other so both stay on the same version.Summary Of The Key Components#Path \u002F LocationTypeWhat It DoesLoads \u002F Triggers Via1.user.iniConfigSets auto_prepend_file to run #2 before every PHP request in the tree. Cached by PHP.PHP-FPM, every request2wp-content\u002Fc1b12371.php *ShimIncludes the hidden #3 file if it exists. Silently no-ops if removed.The .user.ini prepend3wp-content\u002F.c1b12371.php *String-table loaderRebuilds the mu-plugin and defines SC_AUTO_PREPEND.The shim (#2)4wp-content\u002Fdb.phpBootstrap drop-inCarries the full backdoor as a gzip+base64 blob. Decodes and re-deploys the plugin whenever it’s missing or too small.WordPress bootstrap (loads early)5wp-content\u002Fadvanced-cache.phpEarliest drop-inRebuilds the plugin, hooks plugins_loaded, and includes it.WordPress bootstrap when WP_CACHE is set6wp-content\u002Fthemes\u002Fkhorshidi\u002Ffunctions.phpInjected blockTheme-resident twin of db.php that carries the same payload and re-drops the plugin.Active theme, every request7wp-content\u002Fmu-plugins\u002Fhyper-engine-kit.php *Backdoor payloadSelf-hiding payload with multiple persistence and remote-control capabilities.MU-plugin autoload, every request8wp-content\u002Fplugins\u002Fhyper-engine-kit\u002Fhyper-engine-kit.php *Copy of #7Duplicate copy of the same payload used for redundancy.Plugin autoload* File names vary from site to site.What the Backdoor Actually DoesThe payload is the reason the rest of the mesh exists. Once running, it performs several distinct jobs.It hides itself. It filters the plugin list, the update transient, and the site and network plugin views to remove its own entry, so it does not appear in the admin plugins screen or in update checks. It also emits admin JavaScript to scrub itself from the plugin table as a fallback.It talks to command and control over blockchain infrastructure. Rather than a single hardcoded server, the payload carries a list of roughly twenty public Ethereum RPC gateways and a set of smart-contract method selectors. It sends requests to those gateways to read instructions from a smart contract. Because these legitimate third-party gateways are being abused as transport, blocking only the one seen in traffic leaves the rest available as fallbacks, so the whole set must be blocked together.It fingerprints the site and fetches a payload. It collects the site URL and host, the WordPress and plugin versions, path hashes, the active themes, the mu-plugin list, and the current administrator session tokens, encrypts that bundle, and posts it to the resolved endpoint. The reply can carry front-end JavaScript to inject (which, on a store, enables checkout skimming), new PHP to install, and lists of security plugins to deactivate and delete. When told to remove a security plugin, it can deactivate it, wipe its directory, and even reassign or elevate another account first.It creates a hidden administrator. It either adopts an existing hidden admin or generates a new one, writing the account directly into the users and usermeta tables when the normal API is unavailable. It stores the capabilities under the default capabilities meta key, then hides the account from the user list, user counts, and","https:\u002F\u002Fblog.sucuri.net\u002F2026\u002F09\u002Fsc-wordpress-malware-a-self-healing-mesh-of-loaders-drop-ins-and-a-blockchain-controlled-backdoor.html","https:\u002F\u002Fblog.sucuri.net\u002Fwp-content\u002Fuploads\u002F2026\u002F09\u002FSC-WordPress-Malware.png","2026-10-01T00:57:15+00:00","2026-10-01T04:00:03.494874+00:00",8,[18,21,24,26],{"name":19,"type":20},"WordPress","product",{"name":22,"type":23},"PHP","technology",{"name":25,"type":23},"shared memory",{"name":27,"type":23},"blockchain","89f78b1c-3503-45a1-9fc7-e23d2ce1c6d5",{"id":28,"icon":30,"name":31,"slug":32},null,"Malware","malware",[34,39,41,46],{"category":35},{"id":36,"icon":30,"name":37,"slug":38},"26b0b636-0e31-4db1-bffb-61bdf9f20a58","Supply Chain","supply-chain",{"category":40},{"id":28,"icon":30,"name":31,"slug":32},{"category":42},{"id":43,"icon":30,"name":44,"slug":45},"ade75414-7914-4e23-a450-48b64546ee70","Open Source","open-source",{"category":47},{"id":48,"icon":30,"name":49,"slug":50},"e7b231c8-5f79-4465-8d38-1ef13aea5a14","Threat Intelligence","threat-intelligence",[]]