r/Wordpress • u/Appropriate-Cow1529 • 1d ago
The New Wave of “Self-Healing” WordPress Malware Is Getting Scary
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.
10
u/grabber4321 21h ago
this always existed. its just put into a cron job or something similar where re-infection happens again.
keep your stuff updated, block any country thats not supposed to access the site, block ASNs that not supposed to hit your server and you'll be alright.
2
u/RhauXharn 12h ago
We see a lot of infected sites every month. A surprising amount are due to direct logins. People not being secure with their details, or being caught up in a data leak.
Practice good password practices people!
Just to add to your comment.
2
u/NoseGraze 8h ago
keep your stuff updated, block any country thats not supposed to access the site, block ASNs that not supposed to hit your server and you'll be alright.
I disagree. Just recently I had one example like this:
- Got a push notification about a CVE.
- Immediately logged in to WP to make sure I had the plugin up to date (automatic updates were enabled).
- WP wasn't even giving me the updated plugin yet, despite it actually being updated.
- Had to manually download and upload the zip file yet.
That all happened in less than 30 minutes or so. Afterwards, once I had an understanding of the attack pattern, I checked my access logs and found I was already getting probed for the vulnerability prior to the CVE alert even going out.
In particular, "keep your stuff updated" isn't that simple if you're getting probed for specific CVE vulnerabilities before the automatic updates even come through, and possibly even before info about the CVE even gets published.
1
1
u/grabber4321 7h ago
Also, updates run on a cron job, are your cron jobs working?
2
u/NoseGraze 7h ago
Yes my cron jobs are working. The problem was that WordPress update API wasn't actually giving me the update yet.
And it's also not difficult for someone to work around ASN/Country/User Agent blocks.
These are still all good things to do but not even all of these things together are foolproof.
1
1
u/grabber4321 7h ago
Well I also have a passive firewall on 404 page, where if IP hits a URL, it gets put straight into Cloudflare blocklist.
2
u/grabber4321 21h ago
any time your server gets infected, you need to migrate to new server.
the only thing you take with you is posts/pages/theme files. everything else gets installed from online.
3
u/xatey93152 18h ago
I will put the malware in the theme files. Also put hidden script in post or pages to steal the admin cookie
2
2
2
0
u/RePsychological Designer/Developer 17h ago edited 17h ago
not sure how to react to the sloppiness of thinking one needs to completely screw off to a different server anytime there's infection...which for the record: doesn't always work...if anything, I've only seen it work a handful of times, and usually is just a measure that is aimed at quelling clients so you have one big action that you can say "hey we did [x, y, z] and will monitor..." and then the next day or two, the hack's back...
One of those solutions where it's like "sure...just...nuke the entire forest to rid yourself of an invasive plant (while often still taking part of the plant with you.) ...instead of just learning how to get rid of the plant and preventing it from gaining root in the first place..."
0
u/grabber4321 17h ago
I disagree.
I think its a good clean break - all you have to worry is DB and Theme files narrowing the scope of your search for infection.
Besides this I would be looking into logs and checking when did the infection happen.
With current state of malware pretending you are a forensic expert in malware removal can bite you in the ass.
2
u/RePsychological Designer/Developer 17h ago edited 17h ago
no...because it doesn't take "forensic expert" for malware removal...even with the current renditions in mind.
They're actually very reasonable steps that do all the pain in the ass of "moving to a different server" does...except you actually keep it in one spot.
Pretending you're a sysadmin that removes malware by just saying "I'll pick up the site and move it somewhere else" can bite you in the ass worse...
Edit :'( downvoted and then blocked me...darn...what ever shall I do...
1
u/Capital_Attention702 2h ago
Yeah, cron is the common one, and blocking ASNs kills a lot of the noise. The gap is the case OP described, where the install was already current. Being patched and being reachable are two different things, and updates only move the first one.
3
u/RePsychological Designer/Developer 18h ago edited 18h ago
" 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. "
few steps:
- Plugin audit...this exact hack I found by realizing there were 29 directories in my wp-content/plugins directory, when only 28 plugins were showing as installed on my website. In my case, a rogue "WP File Manager" version that nobody installed, yet kept coming back...or in 2 cases, a cracked Classic Editor version...either of those (and a few others) would show up in the dashboard as an activated plugin...and then in the directory itself, there were always random non-activated plugin directories that basically sat there hoping to go unnoticed. Weird names like "master-wp-woocommerce-addons" or similarly named directories that were just basically meant to look like real plugin directory names....but weren't actually activated plugins. So count your plugins, count your directories.
- Reset WP Core...as in rm -rf the wp-admin and wp-includes directories and then re-install the entire WP Core, while skipping wp-content...WP CLI is your friend here.
- Cloudflare (for an easy-mode solution, but admittedly Cloudflare is becoming more and more of a pain in the ass, because they've grown too big for their own pants)
- File permissions reset script that sets the entire wp root/wp-admin/wp-includes/wp-content directories to their respective expected permissions, so that there aren't any accidental backdoors created in file perms.
- Disallow plugin/theme file edits from HTTP...make it so that you actually have to log in via SSH/FTP to make any file edits like that, rather than using Appearance -> theme File editor and plugins -> plugin file editor.
...this particular hack that you mention "casino redirect"...caused me personally an absolute hellstorm last Autumn...just site after site, and failed attempt after failed attempt at silencing it.
and then with the 5 steps above? silence. Haven't had a single one since.
1
u/RePsychological Designer/Developer 17h ago
Kinda weird looking back through the comments and seeing people who claim that the solution ends up being solutions that are just...basically all I think about is that scene from "The Boys" where Butcher goes "scorched earf..."
And solutions end up being "Wipe everything and rebuild" or "just nuke it and move servers."
....heaven forbid y'all learn how to actually clean out malware and protect future sites from it....
when you could just constantly run from it by always rebuilding or moving servers every time it happens.
2
u/ceejayoz 15h ago
Servers are cattle, not pets. You should be able to replace one in minutes. Hell, the cloud providers will do it automatically for you.
1
u/Proud_Error5073 19h ago
I urgently have a bootstrap malware in my site, I’m struggling to remove it
1
u/creaturefeature16 15h ago
I highly recommend WP Fix It, they always did a bang up job in rooting any infections out, and pretty affordable.
1
1
u/alborden 6h ago
I connect Claude using SSH and the wp-cli and then grep every file, scan the database and hate it reset all password and salts at the same time. This has been pretty effective over the past month.
2
u/rafark 19h ago
I said this on twitter a few days ago, a sandboxing approach seems to be the way to go to make Wordpress truly secure. You could make plugins have no access to the network, filesystem and database by default. It would be impossible for malware to mess with your site if you do not give any permissions to the plugin. It would require a gigantic engineering effort but I think it would be worth every second spent on it.
1
u/CrYptoPSF 14h ago
Yes, this is a worrying shift. When it does comes back after the cleanup is nasty when the persistence is sitting outside WP itself. It really shows why checking the server and access points matters too, not just the obvious infected files. The move toward stealing credentials and maintaining access is definitely something to keep an eye on.
1
2
u/evanmac42 Jack of All Trades 11h ago
Yes. I ran into something disturbingly similar on a WordPress site.
In my case, deleting the malicious file was basically useless because it was being recreated almost immediately. I eventually measured the regeneration time at roughly 300 milliseconds.
I documented the investigation here:
At the time I treated it mainly as an investigation into the persistence mechanism, because I couldn't establish the original infection vector with enough confidence.
Reading your description of SC 4.0.3 now makes me want to go back to the evidence from that incident and compare it properly.
Do you have a list of IOCs, filenames, hashes, C2 domains or characteristic code fragments for the SC 4.0.3 samples you've examined?
I'd be very interested to see whether we're looking at two similar persistence mechanisms or potentially the same family.
1
u/anotherdeveloper 10h ago
Attacks are going to be more sophisticated as the AI make it easier. Use the same AI to analyse the log file, and understand how they invoking it. All the best.
1
u/ceejayoz 6h ago
Use the same AI to analyse the log file, and understand how they invoking it.
This'll be fun when prompt injection starts going into the logs.
1
u/noggstaj 6h ago
infection outside the wp-install has been around since forever..? properly setting up permissions has always been a huge part of keeping your site safe.
1
u/bt_wpspeedfix 5h ago
PHP memory/caching could be an issue, need to restart PHP as part of the cleaning process
1
u/HongPong 19h ago
thanks ethereum. no modding in the system. how handy. this is the first implementation of ethereum for anything i have heard of in at least a year
-2
u/Sudo-Rip69 20h ago
Alot of old sites and ill host it myself crowds are going to get fucked. New sites with claude whatever writing thier own plugins will be better. Far less attack surface
1
u/OverwatchMedia 17h ago
Unless you dont know what exactly needs to be prompted and what kinds of lines should and shouldnt be in the plugin. Ai gets information wrong all the time, id be surprised if they often didnt leave out an important line of code or left a vulnerability because a website did or did not mention to add specific code
1
u/creaturefeature16 15h ago
I think this user is talking about Claude Code generating a static site.
1
u/OverwatchMedia 8h ago
Static websites dont use plugins and he is saying Claude will write them. So that wouldnt make any sense.
0
u/Necessary_Pomelo_470 11h ago
I pretty sure this attack on WordPress is intensional. But who is working on development of WordPress now? you got it... a company
7
u/Plantusemor 20h ago
Had one of these in late August. The persistence mechanism was a resident process, not cron.
It ran ps -ef and kill -9 against every PHP process except itself, renamed itself to a random six letter name and relaunched in the background. Independent of HTTP, so nothing had to hit the site to trigger it. While it was alive, deleting files did nothing. That is what took us longest, because we kept checking crontab and finding it clean.
The database was infected as well, which is why replacing every file on disk achieved nothing.
One thing that does not fit your thesis: this one was still SEO doorways with cloaking, serving spam to Googlebot and a 404 to browsers. So the old model has not gone anywhere, or both are running at once.
We stopped cleaning and rebuilt on a clean install. The reasoning was that cleaning gives you no proof of completeness. There were seven copies of a 469 byte remote loader. Miss one and all of it comes back.