SURIQ
The malware in the StopAndProtect operation is not what makes it dangerous. The infrastructure is. According to Check Point Research, one crew is quietly running close to 2,000 hacked WordPress sites as a rotating pool that delivers payloads, relays commands, and stores stolen files. Take a batch of those sites offline and the operation keeps running on the rest. That design, not a clever exploit, is why it has reached more than 6,000 victims around the world.
There are two ways this story can touch you, and most of the coverage only tells the first. If one of your users gets tricked into infecting their machine, you have an endpoint problem. But if you run a WordPress site and have not kept it patched, you may be standing on the other side of this: an unwitting host serving someone else's ransomware. That second job is the one almost nobody is talking about.
What StopAndProtect actually is
Check Point uses "StopAndProtect" for the whole operation, not a single piece of malware, and despite the name it does not always deploy ransomware. It is a toolkit. Once a machine is infected, the operators can pull in a file-encrypting ransomware module, a worm that spreads across Windows file shares and USB drives, a screen locker that throws up a ransom QR code, and a stealer that grabs files, saved passwords, WhatsApp contacts, and keystrokes. There is even a small chat tool so an operator can talk to the person they hit.
The entry point is a technique called ClickFix. A visitor to a compromised site sees what looks like a routine "verify you are human" prompt. Instead of a normal check, it walks them through copying a command and running it themselves. That single paste starts the chain: two PowerShell stages, then a series of .NET downloaders and a loader that checks whether it is sitting inside a security sandbox before it unpacks the working modules. We covered why this trick keeps working, and how to catch it, in our look at shared ClickFix delivery.
The real engine: neglected WordPress sites
Here is the part defenders should sit with. The operators did not build bulletproof hosting. They borrowed yours. Check Point reported that the roughly 2,000 sites in the pool are ordinary compromised WordPress installations, and that many were badly out of date, some by around five years, each carrying dozens of known vulnerabilities. Every hijacked site does triple duty: it serves the malware stages, it acts as a control channel, and it holds stolen data. Rotating across 2,000 of them is what makes the whole thing hard to knock down.
This is the same lesson as the SocGholish takedown and every unpatched-plugin webshell campaign before it: an abandoned or under-maintained site is not a low-risk asset. It is free, disposable infrastructure for whoever finds it first. We traced that pattern in the SocGholish disruption and in CMS webshell campaigns riding unpatched plugins.
Is your WordPress site part of it?
You will not get a ransom note if your site is conscripted. The victims are the people it infects, not you, so nothing will announce the problem. You have to go look. Signs a WordPress host has been turned into infrastructure like this:
-
Administrator or user accounts you do not recognize, or accounts created outside your normal process.
-
PHP files that do not belong to core, your theme, or a plugin you installed, especially anything dropped into upload folders.
-
Files or directories being served to visitors that you never published, or bursts of traffic pulling large archives from your site.
-
Fake "human verification" or CAPTCHA pages showing up on your site that you did not add.
-
Plugins or themes years behind on updates, which is how most of these sites were breached in the first place.
One detail from Check Point's report shows how ordinary the operators' setup was. Their own security slip exposed a custom program written in Visual Basic 6 whose only job was to manage the hijacked domains in bulk. This is volume work aimed at whatever unpatched sites are reachable, not rare tradecraft.
For endpoint defenders: the window before encryption
The steal-first, encrypt-later behavior is a gift if you are watching. Check Point found that operators often enumerate documents, record keystrokes, map connected file shares, and grab periodic screenshots before they decide whether to encrypt at all. That leaves a dwell period between infection and the visible damage. The crew's own exposed directories held roughly 31,000 screenshots and more than 700 stolen data archives, which tells you how long some victims sat compromised before anything locked.
The signals to alert on, in sequence: a browser process spawning PowerShell right after a user loads a web page; PowerShell reaching out to fetch and run a second script; then the later spread, new activity across file shares or scripts firing through the built-in Windows automation system. Any one of those on its own is noise. Starting from a "CAPTCHA" and running in that order, they are the shape of this chain.
What to do this week
-
Patch your own web properties first. Update WordPress core, your themes, and every plugin, and delete the ones you do not use. An outdated plugin is the front door here.
-
Audit for unknown admin accounts and stray PHP files on any site you run, and tighten what file uploads are allowed to write.
-
Tell your users the rule that beats ClickFix: a real website never asks you to open a terminal and paste a command to prove you are human. If a page tells you to do that, close it.
-
Alert on the chain, not just the payload. A browser launching PowerShell, PowerShell pulling a remote script, and follow-on activity over shares is the tell. Managed detection mapped to MITRE ATT&CK is built to flag that sequence even when the final module is one nobody has seen before.
Attribution is still open. Check Point did not name a group behind StopAndProtect, and that is fine. You do not need to know who runs it to shut the door on it. Keep your sites patched so you are not the next node, and teach the paste-this-command tell so your people are not the next victim.