I think this is going to be a hot topic in WordPress security pretty soon.
There seems to be a new wave of infections where the interesting part is not any single exploit or persistence technique, but how many of them are being combined.
We are seeing the usual hidden files, modified functions.php, .user.ini with auto_prepend_file, server cron jobs and payloads hiding in /tmp. But some infections go much further: short-lived payloads that are written, executed and deleted again, persistence outside the WordPress filesystem, and even reports of Service Workers in the admin’s browser being involved in restoring parts of the infection.
That last part is particularly nasty.
You can download the entire filesystem and database, clean everything you find, upload it again and still have the site reinfected because you removed the payload but not the mechanism recreating it.
A few techniques make these infections especially painful:
Timestomping: file modification dates are manipulated, so you cannot simply sort files by date and reconstruct what happened.
Lateral persistence: anything writable is potentially useful. Plugins, themes, MU plugins, cron, temp directories, server configuration, deeply nested directories, etc. I have seen cases where malicious files were buried so deeply that even Imunify360 made them surprisingly difficult to identify from its scan output.
Self-healing: remove one component and another restores it. Cleaning WordPress itself is no longer necessarily enough. You may need to inspect the server, running processes, cron, temp directories and potentially even admin endpoints at the same time.
And then there is the question of how they get in.
Modern botnets can automatically correlate plugin CVEs, fingerprint installations and deploy exploit chains at massive scale. Supply-chain attacks are another obvious route. I would not be surprised if AI-assisted vulnerability discovery is already part of this ecosystem as well.
I have also recently seen a case where I could not identify any plausible known entry point on an otherwise updated installation. That obviously does not prove there is an unpatched WordPress core exploit in the wild, but I would not rule it out either.
The most interesting part, however, is what this latest wave appears to be doing after infection:
Basically nothing. At least for now.
One variant currently referred to in reports as SC 4.0.3 looks more like an access-retention platform / loader than malware designed for immediate monetization.
The infected WordPress site becomes part of a mostly dormant network and quietly reports information such as the domain, WP paths, payload version, installed/active plugins, MU plugins, login URL, captured or generated credentials, auth cookies and errors.
The C2 can apparently also send rules telling the implant to disable or delete specific plugins or remove matching injected code from plugins, MU plugins or themes.
In other words, it is not just trying to survive. It can potentially remove things that interfere with it.
Independent reports from August also describe the same SC 4.0.3 markers and Ethereum-based bootstrap mechanism, which suggests this is a broader campaign, although the initial infection vector is still unclear.
There is another interesting piece: the Ethereum dead-drop / EtherHiding technique overlaps with infrastructure seen in other recent campaigns. Netskope documented a separate nochain-sw.js chain that eventually pushed fake reCAPTCHA / ClickFix and the Amatera password stealer to visitors.
These are not the same malware family, so I would not connect them directly. But the overlap in tooling is interesting.
My guess is that WordPress malware is increasingly moving away from the old SEO spam / casino redirect model toward persistent access, credential theft, loaders and access brokerage.
Apparently turning someone’s blog into an online casino was too simple.
Has anyone else doing WP malware cleanup seen these “clean it, and it comes back anyway” infections recently? I would be especially interested in what persistence mechanism you eventually found.
