SC 4.0.3 Self-Healing WordPress Malware That Rebuilds Itself  🔗 **Source:** [SC 4.0.3 Self-Healing WordPress Malware That Rebuilds Itself](https://www.mdpabel.com/malware-research/sc-403-self-healing-wordpress-malware/) > [!note]+ Document Notes > > [!info] Analysis generated 2026-08-28 by Claude (Opus 5) via readwise-deep-read. > > **Source:** Article — https://www.mdpabel.com/malware-research/sc-403-self-healing-wordpress-malware/ · ~5,062 words · published 2026-08-23. > > **Author:** Md Pabel (mdpabel.com; WordPress malware researcher / incident responder). Reader's author field says "mdpabel.com." > > **Form:** first-person malware forensics writeup with IOCs, MITRE ATT&CK mapping, and cleanup procedure. Static analysis only — samples not executed. > > Register key: [STATED] · [EVIDENCE] · [INFERENCE] · [RECOMMEND]. Full text read. > > # 🏷️ Title: SC 4.0.3 — Self-Healing WordPress Malware That Rebuilds Itself > <!-- deep-read:sections start --> ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ## 📝 Summary **The specimen.** [STATED] A **self-healing WordPress malware** (internal marker **SC 4.0.3**; observed alias *"Trace Scanner Lite"*) that *"regenerate[s] almost immediately after its files were deleted."* The defining feature *"is not any single file. It is the redundancy"* — a persistence **mesh**, not a chain. **The mesh.** [STATED] Components that restore each other: a normal plugin AND an identical **must-use plugin** copy; the drop-ins **advanced-cache.php** and **db.php** (each embedding a full compressed payload copy); an injected **theme functions.php** block; a **.user.ini** setting `auto_prepend_file` to a visible loader that includes a hidden `.`-prefixed loader; plus non-file stores — **WordPress options/transients**, **System V shared memory** (fileless), **ZIP backups**, and a **browser service worker**. *"Removing one node leaves several others able to reconstruct it."* **Proof of unity.** [EVIDENCE] The db.php implant and the functions.php block each decode to **185,171 bytes with SHA-256 8284d68…**, *"exactly the hash of the recovered trace-scanner-lite.php"* — *"the strongest proof that the files belong to one persistence system."* **Capabilities.** [STATED] Steals admin passwords (hooks auth, records plaintext post-login); creates a **hidden administrator** (prefix `admin_`/`adm_`/`administrator_`/`backup_` + 10 hex chars); **forges valid auth cookies for every existing administrator** (14-day expiry) so *"the attacker does not need to know each administrator's password"*; hides itself from wp-admin lists, Site Health, and elFinder/file-manager filters; **spreads to sibling WordPress sites** writable by the same OS account; and backdates files (**timestomp**) so *"dates displayed in a hosting file manager are not a trustworthy infection timeline."* **C2 via Ethereum.** [STATED] Uses **Ethereum smart-contract calls as a decentralized dead-drop resolver** — `eth_call` with selector `0x3bc5de30` against three embedded contract addresses returns an XOR key and encrypted C2 URLs, then exchanges XOR-obfuscated JSON. TLS verification disabled for C2. ## 📖 Main Content ### Why deletion fails [STATED] A request enters PHP; `.user.ini`'s `auto_prepend_file` runs the small loader before the requested script; that reaches the hidden loader, which recreates the MU plugin; WordPress auto-loads MU plugins and recognizes advanced-cache.php/db.php as drop-ins; any survivor runs recovery logic. *"Deleting the plugin directory therefore does not delete the payload"* — the theme and db.php each carry a full copy, and advanced-cache.php *"can recover from ZIP, a WordPress option, or shared memory even when the visible PHP copies have been removed."* [INFERENCE] The design defeats the instinctive response (delete the file you see) by construction — every visible node is backed by an invisible one in a different substrate (config, drop-in, DB, RAM, browser). Renaming `wp-content` worked as emergency interruption *"because several calculated and hard-coded paths suddenly stopped resolving"* — the accidental discovery that revealed the mesh. ### Site-specific naming defeats signature-by-filename [EVIDENCE] Names like the loader `59e2e230`, ZIP `83af5c0a`, service worker `e777f187` are *"deterministic hashes of the victim's WordPress absolute path (ABSPATH) plus a short role label"* — `first 8 of md5(ABSPATH + "ldr")` etc. [INFERENCE] So *"a different absolute path produces different hexadecimal names,"* and hunting for `59e2e230.php` across sites is useless. The correct indicators are **content markers** (`SC_ADV_BEGIN:4.0.3:`, `sc_cron_fetch`), **payload hashes**, and **C2 config** (the `0x3bc5de30` selector, contract addresses) — behavior over filename. Pabel repeatedly stresses this: *"Hexadecimal names from one victim must never become a universal deletion list."* ### The browser as a persistence layer [STATED] The service worker (SHA-256 7bafee00…, scope `/` via `Service-Worker-Allowed: /`) intercepts `wp-login.php` POSTs to steal `log`/`pwd`, resolves C2 through the same Ethereum mechanism, receives and executes Base64 JavaScript, and *"can attempt plugin reinstallation using an authenticated administrator's upload nonce."* [INFERENCE] This is the detail most responders would miss: *"server cleanup alone may leave an administrator browser capable of leaking new credentials or helping reinstall the payload."* The malware persists in the human operator's browser, outside the server entirely — a genuinely modern move that turns incident response into a multi-substrate problem (disk + DB + RAM + config + every admin's browser profile). ### Anti-forensics discipline [STATED] Timestomp (MITRE **T1070.006**) — copies plausible timestamps from real WordPress files or backdates ~1 year. Hides from wp-admin by hooking plugin lists, update data, Site Health, and file-manager filters, so *"'not visible in wp-admin' is not evidence that the file is absent."* [INFERENCE] Every default trust signal a WordPress admin uses (file dates, plugin list, user list, Site Health) is specifically poisoned — the malware is built against the standard investigation workflow, not just against detection. ### The forensic method itself is the model [EVIDENCE] Pabel's discipline is the article's second lesson: samples *"handled as text and were not executed"*; no C2/RPC endpoint contacted; **negative results reported as bounded** (the generated-admin pattern *"not observed"* — *"does not clear the user table"*; sc_cron_fetch absent from the captured cron row — *"a bounded negative result"*); and repeated refusal to overclaim (hexadecimal option names *"require validation"*, are *"not a safe deletion criterion"*). [INFERENCE] This is textbook evidence hygiene — separating *"the behavior proven by the recovered code from possible initial-access hypotheses,"* stating confidence per claim, and never letting a suggestive artifact become a diagnosis. It's the same "a finding is a claim until something runs; state your confidence" discipline in Courtney's CLAUDE.md, applied to malware. ### Initial access unknown, honestly [STATED] *"The recovered code proves persistence, credential theft, C2, defense evasion, browser compromise, and lateral spread. It does not contain reliable evidence of the first exploit."* Hypotheses listed (vulnerable plugin, stolen credential, writable file-manager flaw, lateral spread) without picking one. [INFERENCE] Given this same batch's wp2shell read, the initial-access class is exactly what that exploit provides — wp2shell (or its kin) gets you admin; SC 4.0.3 is what a competent operator installs afterward to never lose it. Together they span the kill chain: entry → persistence. ## 🗒️ Notes - [INFERENCE] This is the persistence half of the week's WordPress-security kill chain: wp2shell (Reynolds) is initial access; SC 4.0.3 is what survives cleanup once you're in. Cross-link them — an admin account minted by an author_exclude SQLi is exactly the foothold this malware would fortify into a multi-substrate mesh. - [EVIDENCE] The single most important operational lesson: **hunt by behavior/markers/hashes/C2, never by filename** — names are `md5(ABSPATH + role)` and differ per site. The high-value content indicators (`SC_ADV_BEGIN:4.0.3:`, `sc_cron_fetch`, `sc_payload_persistent`, selector `0x3bc5de30`, `auto_prepend_file`) are the reusable detection artifact. - [INFERENCE] The browser-service-worker persistence layer is the finding most WordPress cleanups would miss and the one worth a standalone note: server eradication is insufficient; every admin browser profile needs the service worker unregistered and site data cleared, or it re-leaks credentials and can reinstall the payload via a live upload nonce. - [INFERENCE] Ethereum-as-dead-drop-resolver is a notable C2 evolution — no takedownable domain; the resolver is a smart contract on a public chain, and the RPC providers are legitimate infrastructure being abused (Pabel correctly declines to label them malicious). Worth a reference note on resilient-C2 patterns. - [STATED] The forensic-method discipline is itself citable as a model for Courtney's agent-audit work: text-not-executed, no live-endpoint contact, per-claim confidence, bounded negatives, "a matching filename alone is not a diagnosis." This is the reproduction-and-confidence rigor her CLAUDE.md demands, demonstrated end-to-end. - [EVIDENCE] Corroboration named: independent August 2026 reporting (Monarx, Seven Labs) describes the same SC 4.0.3 marker scheme and Ethereum bootstrap — so this is a live campaign, not a one-off, and the family designation is provisional (SC 4.0.3 marker > "Trace Scanner Lite" alias). ## 📚 References [EVIDENCE] Named: **SC 4.0.3** (internal marker) / **Trace Scanner Lite** (alias), WordPress **MU plugins**, drop-ins **advanced-cache.php** / **db.php**, **.user.ini** `auto_prepend_file`, **System V shared memory** (`ftok(wp-config.php,'s')`), **OPcache**, **WordPress options/transients** (`sc_payload_persistent`, `sc_persist_manifest`, `sc_cron_fetch`), **service worker** (`Service-Worker-Allowed: /`, MDN), **Ethereum JSON-RPC** `eth_call` selector `0x3bc5de30` + 3 contract addresses, **MITRE ATT&CK** (T1027, T1056.003, T1070.006 Timestomp, T1053, T1102.001 Dead Drop Resolver, T1505.003 Web Shell), **elFinder**, **WP-CLI** `wp user session destroy`, **F5-adjacent** corroboration from **Monarx** and **Seven Labs**, **cPanel/phpMyAdmin** (evidence captures). SHA-256 IOCs and contract addresses fully listed. ## 🗣️ Paraphrase A WordPress infection that rebuilds itself the moment you delete part of it, because it isn't one file — it's a mesh of mutually-restoring copies spread across a normal plugin, a must-use plugin, two drop-ins (advanced-cache.php, db.php), the theme, a .user.ini auto-prepend loader, WordPress database options, fileless shared memory, ZIP backups, and even the admin's browser via a service worker. Every copy decodes to the same payload hash, proving they're one system. It steals admin passwords, forges valid login cookies for every admin, plants a hidden admin, hides from wp-admin and file managers, backdates its files, spreads to sibling sites on the same account, and finds its C2 servers through Ethereum smart-contract calls so there's no domain to take down. File names are per-site MD5 hashes, so you must hunt by behavior and content markers, not filenames — and you must eradicate every node in one pass under execution containment, then rotate all credentials and clean every admin browser, or it comes back. ## 📰 Newsletter **The malware you can't delete.** Md Pabel's forensic writeup of SC 4.0.3 ("Trace Scanner Lite") is a masterclass in modern WordPress persistence. It's not a file — it's a self-healing mesh: a plugin, an identical must-use-plugin copy, the advanced-cache.php and db.php drop-ins, the theme's functions.php, a .user.ini auto-prepend loader, database options, fileless System V shared memory, ZIP backups, and a browser service worker — each able to rebuild the others (all decoding to the same payload hash). It forges valid auth cookies for every admin (no password needed), hides from wp-admin and file managers, backdates its own files, spreads to sibling sites on the same hosting account, and resolves its command-and-control through Ethereum smart contracts so there's no domain to seize. Two operational lessons: hunt by behavior and content markers (filenames are per-site MD5 hashes), and server cleanup alone fails — every admin browser needs its service worker killed too. Pabel's evidence discipline (text-not-executed, per-claim confidence, bounded negatives) is as instructive as the malware. ## ✅ Action Items 1. [RECOMMEND] #action/h1 File the detection guidance in Courtney's security wiki: hunt SC 4.0.3 by content markers (`SC_ADV_BEGIN:4.0.3:`, `sc_cron_fetch`, `sc_payload_persistent`), payload hash, and C2 selector `0x3bc5de30` — never by the per-site hashed filenames. Include the browser-service-worker cleanup step that server-only cleanups miss. 2. [RECOMMEND] #action/h2 Cross-link with the wp2shell analysis as the two halves of one kill chain (initial access → self-healing persistence); together they're a complete case study for the agent-audit / incident-response file. 3. [RECOMMEND] #action/h3 Capture Pabel's forensic discipline (samples as text, no live-endpoint contact, per-claim confidence, bounded negative results, "filename is not a diagnosis") as a reference model — it's the reproduction-and-confidence rigor Courtney's CLAUDE.md demands, demonstrated on real malware. ## 🧪 Hypotheses - [INFERENCE] H1: Ethereum-resolver C2 spreads to more commodity WordPress malware families because it's takedown-resistant (no domain, no hosting to seize) and cheap — the dead-drop-on-a-public-chain pattern is too effective not to copy. - [INFERENCE] H2: Browser-service-worker persistence becomes a standard second stage in credential-theft malware — it survives server cleanup, sits in the trusted admin's own browser, and has a live authenticated session to abuse. Most current WordPress cleanup guides don't mention it. - [INFERENCE] H3: Fileless (shared-memory) + database-embedded persistence makes filesystem-scanner-based malware detection (the dominant WordPress security-plugin model) increasingly insufficient — detection has to move to behavior, DB content, and egress monitoring. ## 📊 Methodology [EVIDENCE] Exemplary static-analysis method: decode string-substitution layers, unpack Base64/gzip, compare payload hashes across components (the byte-for-byte SHA-256 match is the unity proof), map file/DB/hook/browser/network behavior, and confirm DB persistence with read-only queries after the file analysis. Samples handled as text, never executed; no C2 or RPC endpoint contacted. MITRE ATT&CK mapping provided with the explicit caveat that it's "approximate." [INFERENCE] The method's rigor is the point: every claim carries a confidence level, negatives are bounded ("does not clear the user table"), suggestive artifacts (large hex-named options) are flagged as requiring validation rather than deleted, and initial access is explicitly left unresolved. Limits Pabel names himself: single victim's sample set, unknown entry route, C2-delivered regexes not in the static files (so cleanup targets can't be fully claimed). ## ❓ Questions - [INFERENCE] What was the initial access vector — and given this batch, could it have been a wp2shell-class core exploit or a compromised plugin? (Pabel correctly leaves it open; the kill-chain pairing is my inference.) - What do the C2-delivered cleanup regexes target — i.e., does the malware remove competing infections or specific security tools? (Not in the static files.) - How many sites/campaigns share the SC 4.0.3 marker scheme (Monarx/Seven Labs corroborate a campaign — what's its scale)? - Do WordPress security plugins currently detect the fileless shared-memory and browser-service-worker layers, or only the disk copies? ## 🔮 Future Research - [RECOMMEND] Read the corroborating Monarx and Seven Labs analyses named in the article for campaign scope and any initial-access evidence Pabel's single sample lacked. - [INFERENCE] Pair with the wp2shell read as a complete kill-chain case study (entry → persistence) for Courtney's security file; the two articles were fed together and belong together. - [RECOMMEND] Track whether mainstream WordPress security tooling adds shared-memory and service-worker detection — the gap this malware exploits is the detection frontier. ## 💡 Implications - [INFERENCE] For WordPress incident response broadly: the piece redefines "cleaning a hacked site" from a file-deletion task to a multi-substrate eradication problem — disk, database, shared memory, config, and every admin's browser must be cleared in one containment window, or the mesh rebuilds. Most cleanup guidance and most security plugins address only the disk layer. - [INFERENCE] For Courtney's site-audit / security work: the behavior-over-filename lesson is directly operational — signature-by-filename detection is defeated by per-site hashed names, and the durable indicators are content markers, payload hashes, and C2 protocol artifacts. This is a concrete detection-strategy correction. - [STATED→INFERENCE] For the batch's kill-chain arc: wp2shell showed AI-accelerated *entry*; SC 4.0.3 shows sophisticated *persistence* that survives naive cleanup. The combination is the full modern WordPress compromise — machine-fast to get in, mesh-redundant to stay in — and it argues (with the Syntax and Reynolds reads) that the winning defenses are structural: least-privilege file permissions, per-site OS isolation (the lateral-spread vector), read-only production, and egress monitoring for the Ethereum-RPC C2 pattern. ## 🧠 Learning Styles Assessment [EVIDENCE] Exceptional for systems and visual learners: the ASCII persistence-graph diagram, the component-map and IOC tables, the per-figure cPanel/phpMyAdmin evidence captures, and the MITRE mapping give multiple entry points. Reading/writing learners get precise prose with hashes and formulas. [INFERENCE] The "start with the problem you're seeing" opening (symptom checklist before analysis) is smart pedagogy for the responder audience — it lets a reader confirm relevance before investing in the deep technical body. ## 📊 Accessibility Assessment [EVIDENCE] Well-structured: descriptive figure captions for every cPanel/phpMyAdmin screenshot (the evidence is narrated in text, not screenshot-only), tables with labeled columns, an ASCII diagram that reads linearly. Content indicators and IOCs are in copy-able text form. [INFERENCE] The screenshots carry corroborating rather than sole evidence (the text states what each shows), so a screen-reader user loses little — a genuinely accessible technical writeup, which is rare for malware forensics. ## 🌍 DEIB Assessment [EVIDENCE] The lateral-spread mechanism (infects sibling sites under the same OS account) disproportionately harms **shared-hosting** users — the budget tier — where one compromised site can take down every site on the account. Pabel's cleanup guidance (isolate sites under separate OS users, restrict web-server write access) names controls that cost money/expertise. [INFERENCE] The unstated equity dimension matches the wp2shell read: structural protection (per-site isolation, read-only filesystems) is a resourced-hosting feature, and shared-hosting users are both the most exposed to lateral spread and the least likely to have the isolation that prevents it. The article serves them well by providing free, behavior-based detection guidance. ## ✅ Logical Validity - [EVIDENCE] Unusually rigorous: the central unity claim rests on byte-for-byte SHA-256 equality across components (proof, not inference); capabilities are tied to specific recovered code; negatives are explicitly bounded; and the confidence section cleanly separates high-confidence (persistence, C2, credential theft, spread — all in the code) from low-confidence (initial access — not in the samples). - [INFERENCE] No overclaiming to flag — the article's discipline is its hallmark. The only inherent limits (single victim's sample set, C2-delivered logic absent from static files, unknown entry route) are all stated by the author. Corroboration by independent reporting (Monarx, Seven Labs) strengthens the campaign-level claims. This is close to a model of how to write a defensible forensic finding. ## 🛡️ DARVO Analysis Not applicable to this source — malware forensics with no interpersonal dynamics. Notable for its epistemic humility: the author repeatedly declines to overclaim (no attribution, initial access unknown, filenames not diagnostic), the opposite of the confident-narrative style that malware writeups often adopt. ## 🎯 Conclusion The persistence half of this week's WordPress-security kill chain and a model of forensic discipline. SC 4.0.3's defining trait is redundancy: a self-healing mesh spanning plugin, must-use plugin, two drop-ins, theme, an auto-prepend loader, database options, fileless shared memory, ZIP backups, and the admin's own browser via a service worker — every node proven identical by SHA-256, every node able to rebuild the rest. The operational lessons are sharp and reusable: **hunt by behavior/markers/hashes/C2, never by filename** (names are `md5(ABSPATH+role)`), and **server cleanup alone fails** — the browser service worker re-leaks credentials and can reinstall via a live upload nonce. Paired with the wp2shell read (initial access), it completes the modern compromise picture — machine-fast entry, mesh-redundant persistence — and reinforces the week's structural-defense thesis (per-site OS isolation, least-privilege file permissions, egress monitoring for the Ethereum-RPC C2). Pabel's evidence hygiene — text-not-executed, per-claim confidence, bounded negatives, "a filename is not a diagnosis" — is itself the citable artifact, a working demonstration of the reproduction-and-confidence rigor Courtney's own instructions demand. <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/SC 4.0.3 Self-Healing WordPress Malware That Rebuilds Itself.md|SC 4.0.3 Self-Healing WordPress Malware That Rebuilds Itself by Md Pabel]] ## Highlights - That is exactly the hash of the recovered `trace-scanner-lite.php`. This byte-for-byte match is the strongest proof that the files belong to one persistence system. ([View Highlight](https://read.readwise.io/read/01m14cpa8vw7sftcnact6vf5a7)) - Note: The unity proof done right: db.php implant and the theme functions.php block each decode to the identical 185,171-byte payload (SHA-256 8284d68…). Evidence, not inference — the model for how to prove components belong to one system, and the reason to hunt by hash/marker not per-site hashed filename. #atom/literature/h2 - This means server cleanup alone may leave an administrator browser capable of leaking new credentials or helping reinstall the payload. Every browser/profile used to administer the site should have the site’s service worker unregistered and its site data cleared after the server has been cleaned. ([View Highlight](https://read.readwise.io/read/01m14cp1tcn0wjj367nygpbatf)) - Note: The finding most WordPress cleanups miss: persistence in the admin's own browser via a service worker (scope /) that intercepts wp-login POSTs and can reinstall via a live upload nonce. Server eradication is insufficient — incident response is now a multi-substrate problem (disk + DB + shared memory + config + every admin browser). #atom/literature/h1