How Monarx Is Stopping the Self-Healing _sc WordPress Infection

‍

Last month we broke down the anatomy of a WordPress infection that does something most malware doesn't even attempt: it engineers its own survival at every layer of the stack, from the filesystem and database to WP-Cron, the active theme, and even the browser of the administrator trying to clean it up.

This is the follow-up. It covers two things: how fast this campaign has actually scaled since we published that breakdown, and the layered detection-and-response combo our engineering team built specifically because a single tool (no matter how good) was never going to be enough against something built this way.

The scale of _sc: 10x more files analyzed

‍

‍

Before this campaign, Monarx was already processing a substantial volume of unique files each month across the infrastructure we protect, the normal churn of a global fleet of hosting partners running WordPress at scale. This infection changed that math. The persistence mechanisms behind it drive rapid reinfection cycles, and as a direct result we're now processing roughly 10x that volume.

The increase is also visible in remediation activity. During the first half of the year, Monarx averaged about 37 million remediations per day. By September, that had climbed to more than 207 million per day, and on September 7 alone, Monarx performed nearly 360 million remediations in 24 hours, almost 10x the first half daily average. The first seven days of September alone generated more remediation activity than the entire month of January.

That jump isn't a sign that our detection got noisier. It's a direct consequence of how this specific malware behaves. Nine parallel persistence mechanisms, each capable of restoring the others; a file recovery routine that regenerates the payload the moment an on-disk copy looks smaller than expected; database-level shadow copies; and scheduled WP-Cron jobs rechecking and rewriting state roughly every ten hours across every infected site. Every one of those behaviors generates more files, more writes, and more events for us to inspect, multiplied across every hosting partner and every sibling site on shared infrastructure that this thing has walked into.

This is what a genuinely polymorphic, self-healing infection looks like from the defender's side of the fence: it doesn't just infect more sites, it multiplies the sheer volume of work required to keep any one of them clean.

Why _sc requires both server and runtime protection

The honest engineering problem here is that this malware doesn't have one persistence mechanism you can neutralize once. It has nine, running in parallel, plus a browser-resident Service Worker that survives a full server-side cleanup entirely. Some of those mechanisms live on disk. Some live in the database. Some live inside a live PHP request that never touches disk in a matchable form until it's already executing.

That last part is the reason a purely on-server antivirus agent (however fast and however low-overhead) was never going to be a complete answer on its own. If a piece of this malware never writes its decoded, malicious logic to disk, a tool that only looks at disk can't see it.

So our team built a combination instead of a single point solution:

Monarx Agent does what a core antivirus module should: hands-free detection and remediation of the file, process, and in-memory components of this infection, including the layer that self-heals across db.php, advanced-cache.php, the active theme, and guard stubs. It remediates in memory and in-process, not just on disk, and it keeps re-checking its own remediation over time, so a file that "comes back" from one of the nine persistence mechanisms gets removed again automatically instead of waiting for the next manual scan. On top of that, Monarx Agent will also terminate known malicious processes it finds running in memory; a second, independent line of defense that matters specifically because this family is built to survive file-level cleanup. A process that's already running doesn't need its dropper file to still exist on disk to keep doing damage, so being able to kill the process itself, not just the file it came from, closes off another one of the nine ways this infection tries to come back.

ThreatShield, our RASP (runtime application self-protection) module, closes the gap Monarx Agent can't reach by design. It runs inside the live PHP execution context itself, monitoring the functions and hooks this malware depends on to operate; the crons it schedules, the hooks it registers, the calls it makes once its obfuscated strings have already been decoded at runtime. That's what lets it intercept and block the malicious calls as they happen: the automated, nonce-driven plugin reinstalls, the raw SQL run outside normal WordPress code paths, the credential-harvesting hooks; regardless of how well the payload that triggered them was obfuscated on disk.

This is also why a RASP is a fundamentally better fit against this specific campaign than a traditional WAF. A WAF sits in front of the application and makes its call based on what a request looks like on the way in, analyzing headers, payload patterns, and known-bad signatures. This malware decodes its logic at runtime and only assembles the malicious string in memory once PHP is already executing, so there's often nothing at the perimeter for a WAF to flag: the request that reinstalls the plugin arrives looking like an ordinary, authenticated, nonce-bearing admin action, because from the network's vantage point, that's exactly what it is. A RASP, on the other hand, doesn't have that blind spot, because it isn't inspecting the request from outside; it's inside the same PHP execution context as the application, watching what the code actually does: which functions it calls, which hooks it registers, which database queries it runs, and in what order. That's what lets ThreatShield catch a raw SQL query hitting wp_users outside of core, or a plugin-install flow triggered without a real human click, even when the payload driving it was invisible to signature-based scanning at every earlier stage.

Neither module alone stops this campaign cleanly.

• Monarx Agent without ThreatShield can win the disk-and-process fight and still lose to a malicious cron firing inside a live request.
• ThreatShield without Monarx Agent can catch the runtime behavior and still leave nine dormant, self-healing copies sitting on the filesystem waiting for their next chance to restore the plugin.
• Run together, one closes the gap the other is structurally unable to cover.

Self-healing _sc: The case for layered defense

We're saying this plainly because it's the actual lesson of this campaign, not a sales pitch: a single-layer defense is not a match for a multi-layer attack.

This malware was built by people who understood that most defenders check one thing (usually the filesystem either via Yara or RegEx based tools) and designed around that assumption. It hides the state in the database. It resolves command-and-control over Ethereum smart contracts specifically because there's no domain to seize and no IP to null-route. It back-dates file modification times to defeat "sort by newest" triage. And it plants a Service Worker in the administrator's own browser so that even a perfectly clean server gets silently reinfected the next time that admin logs into wp-admin.

Every one of those design choices is aimed at a defender who only has one kind of visibility. Hosting partners who rely on a single scanning approach, whether file based, signature based, or perimeter based, are exactly the audience this malware was built to beat. The partners weathering this campaign well are the ones running detection at more than one layer: on the server, inside the live PHP execution path, and with a human-led remediation path for sites where nine parallel persistence mechanisms have already taken hold.

What site owners and admins should do right now

If your site has shown any of the indicators from our original breakdown, such as an unfamiliar admin account, unexplained outbound traffic, or a Service Worker registered under /wp-admin/ you didn't put there, server-side cleanup is necessary but not sufficient. Two things matter beyond the server:

• Run an antivirus solution on your own machine. This campaign harvests admin credentials both server-side and through a malicious Service Worker that intercepts your login form directly in the browser. If your device is compromised too, rotating your WordPress password doesn't close the loop.
• Put CAPTCHA and two-factor authentication on your wp-admin login. A forged session cookie or a harvested password is far less useful to an attacker if logging in also requires a second factor they don't have. This won't stop every persistence mechanism described in our original post, but it directly cuts off the credential-theft and hidden-admin-recreation paths that let a "cleaned" site get walked right back into.

Continuing to track the _sc campaign

Our research team is continuing to track this campaign's infrastructure and payload updates, and the file-processing numbers above are a live reflection of how much ground it's still trying to cover. If you're a hosting partner seeing this kind of volume spike on your own infrastructure, or you want to talk through how Monarx Agent and ThreatShield work together against this specific family, reach out to our team. This is exactly the scenario the combination was built for.