StopAndProtect Campaign: Defending Against a 2,000-Site Compromised WordPress Malware and Data Theft Network

Security researchers have flagged StopAndProtect, a global cybercrime operation built on nearly 2,000 compromised WordPress websites. This is not a single malware family with a single signature to block. It is a full criminal toolkit operating on rented-by-force infrastructure: legitimate sites that have been hijacked and repurposed to distribute malicious software, commandeer infected hosts, and act as dead-drop storage for stolen documents, screenshots, and activity logs that track the status of the operation.

Two populations are at risk here, and both need to act:

WordPress site owners and hosting providers — your site may already be a node in this network, serving malware to your visitors and hosting stolen victim data without your knowledge. That is a legal, reputational, and regulatory liability (think PCI-DSS scope contamination, GDPR breach notification duties if personal data transits your server).
Every organization whose users browse the web — compromised legitimate sites bypass most domain-reputation controls. Users trust the site, the browser trusts the certificate, and the payload rides in on a domain with a clean history.

The severity here is amplified by scale and by the abuse of trust. Roughly 2,000 legitimate domains acting as delivery and C2-adjacent infrastructure defeats naive blocklisting and makes detection a behavioral problem, not an indicator problem.

Technical Analysis

What the Operation Looks Like

Based on the reported behavior, StopAndProtect operates as an infrastructure-first campaign:

Compromised WordPress sites serve as the delivery layer. Attackers gain access through the usual WordPress intrusion vectors — vulnerable plugins/themes, weak or reused admin credentials, unpatched core installations, and compromised hosting accounts. Once inside, they inject malicious PHP (web shells, redirect scripts, conditional malware-serving code) into the site.
Malware distribution: visitors to the hacked sites are profiled and served payloads — typically via injected JavaScript redirects, fake update lures, or drive-by download logic that only fires for specific geographies, browsers, or referrers to evade researchers and scanners.
Host commandeering: infected endpoints are enrolled into the operation's toolkit, which researchers describe not as one malware but a collection of criminal software — loaders, stealers, RAT-style components, and status-tracking agents.
Data warehousing: stolen documents, screenshots, and victim activity logs are staged back onto the compromised WordPress infrastructure itself, blending exfiltration traffic with ordinary web traffic to legitimate domains.

Why This Defeats Traditional Controls

Domain reputation is neutralized. The delivery domains are real businesses with years of history, valid TLS certificates, and clean passive DNS.
Payloads are conditional. Conditional cloaking means a SOC analyst browsing the reported URL from a corporate sandbox may see a perfectly normal site.
Exfiltration looks like web traffic. Uploading stolen screenshots and logs to an HTTPS endpoint on a legitimate WordPress site is nearly indistinguishable from normal form submissions at the perimeter.
The toolkit rotates. Because it is not a single malware family, hash-based and even family-level YARA coverage lags behind.

Exploitation Status

This campaign is confirmed active in the wild at global scale. There is no single CVE associated with the operation — the initial access vector is the broad, well-worn class of WordPress ecosystem weaknesses (outdated plugins, weak credentials, misconfigured hosting). Do not wait for a CVE to act; the exploitation is happening now against whatever your weakest WordPress property or endpoint happens to be.

The Defender's Mental Model

Break the campaign into two detection surfaces:

Server-side (your WordPress estate): unauthorized PHP file creation/modification, web server processes spawning shells, rogue admin accounts, unexpected outbound connections from the web tier, and archives of stolen data staged in web-accessible directories.
Client-side (your endpoints): browsers spawning script interpreters or installers after visiting legitimate-but-compromised sites, payloads executing from user-writable directories, and outbound HTTPS uploads of screenshots/logs/archives shortly after a suspicious execution chain.

Detection & Response

The rules below target the behavioral chain — web server process abuse, browser-driven payload execution, and exfil staging — rather than indicators that will burn within days. Validate against your baseline before enabling at high sensitivity.

YAML

---
title: Web Server Process Spawning Shell or Script Interpreter
description: Detects web server or PHP processes (httpd, nginx, php-fpm, w3wp) spawning command shells or script interpreters, consistent with web shell activity following WordPress compromise in the StopAndProtect campaign.
logsource:
  category: process_creation
  product: windows
detection:
  selection_parent:
    ParentImage|endswith:
      - '\w3wp.exe'
      - '\httpd.exe'
      - '\php-cgi.exe'
      - '\php.exe'
  selection_child:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\mshta.exe'
      - '\rundll32.exe'
      - '\certutil.exe'
      - '\bitsadmin.exe'
      - '\whoami.exe'
      - '\net.exe'
  condition: selection_parent and selection_child
falsepositives:
  - Rare CMS administrative plugins that invoke system commands
  - Legitimate application pool management by hosting control panels
level: high
---
title: Browser Process Spawning Script Interpreter or Installer
description: Detects web browsers spawning script interpreters or installers, consistent with drive-by malware delivery from compromised legitimate websites such as those abused in the StopAndProtect operation.
logsource:
  category: process_creation
  product: windows
detection:
  selection_parent:
    ParentImage|endswith:
      - '\chrome.exe'
      - '\msedge.exe'
      - '\firefox.exe'
      - '\iexplore.exe'
      - '\brave.exe'
      - '\opera.exe'
  selection_child:
    Image|endswith:
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\mshta.exe'
      - '\msiexec.exe'
      - '\rundll32.exe'
      - '\regsvr32.exe'
  condition: selection_parent and selection_child
falsepositives:
  - Browser-based SSO or extension installers in managed environments
  - Enterprise web applications that invoke local helpers (rare)
level: high
---
title: Archive Staging of Screenshots and Documents in User Directories
description: Detects creation of compressed archives in user-writable locations containing screenshot or document artifacts, consistent with data collection and exfil staging observed in the StopAndProtect toolkit (stolen screenshots, documents, and activity logs).
logsource:
  category: process_creation
  product: windows
detection:
  selection_compress:
    CommandLine|contains:
      - 'Compress-Archive'
      - 'tar -c'
      - 'tar.exe -c'
      - '.zip'
      - 'a -tzip'
      - 'a -trar'
  selection_paths:
    CommandLine|contains:
      - '\AppData\Local\Temp'
      - '\AppData\Roaming'
      - '\Pictures\Screenshots'
      - '\Desktop'
      - '\Documents'
  condition: selection_compress and selection_paths
falsepositives:
  - Users manually archiving documents
  - Helpdesk-driven log collection workflows
level: medium

KQL — Microsoft Sentinel / Defender

// Hunt: web server / PHP processes spawning shells or script interpreters
// Also catches browser-spawned script execution consistent with drive-by delivery
// Requires Endpoint process data (MDE) and/or Sysmon ingestion into Sentinel
let WebServerParents = dynamic(["w3wp.exe", "httpd.exe", "php-cgi.exe", "php.exe", "php-fpm", "nginx", "apache2"]);
let BrowserParents = dynamic(["chrome.exe", "msedge.exe", "firefox.exe", "brave.exe", "opera.exe", "iexplore.exe"]);
let SuspiciousChildren = dynamic(["cmd.exe", "powershell.exe", "pwsh.exe", "wscript.exe", "cscript.exe", "mshta.exe", "rundll32.exe", "regsvr32.exe", "certutil.exe", "bitsadmin.exe", "msiexec.exe", "whoami.exe", "net.exe", "curl.exe", "wget.exe", "bash", "sh"]);
DeviceProcessEvents
| where TimeGenerated > ago(14d)
| where (FileName in~ (WebServerParents) or InitiatingProcessFileName in~ (WebServerParents))
     or (InitiatingProcessFileName in~ (BrowserParents))
| where FileName in~ (SuspiciousChildren)
| extend SpawnType = iff(InitiatingProcessFileName in~ (WebServerParents), "WebServerChild", iff(InitiatingProcessFileName in~ (BrowserParents), "BrowserChild", "Other"))
| where SpawnType != "Other"
| project TimeGenerated, DeviceName, SpawnType, InitiatingProcessFileName, InitiatingProcessCommandLine, FileName, ProcessCommandLine, AccountName, FolderPath
| order by TimeGenerated desc;

KQL — Microsoft Sentinel / Defender

// Hunt: PHP/web tier making unexpected outbound connections or receiving web-shell-style POSTs
// Requires Syslog and/or firewall/proxy (CEF) ingestion into Sentinel
Syslog
| where TimeGenerated > ago(14d)
| where ProcessName has_any ("php", "httpd", "nginx", "apache2")
| where SyslogMessage has_any ("/bin/sh", "/bin/bash", "wget ", "curl ", "chmod +x", "base64 -d")
| project TimeGenerated, Computer, ProcessName, SyslogMessage
| order by TimeGenerated desc;

VQL — Velociraptor

-- Velociraptor hunt: identify suspicious child processes of web server/PHP and browser processes
-- plus recently created PHP files in web roots (potential injected web shells)
SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE (
        (CommandLine =~ '(?i)(cmd|powershell|wscript|cscript|mshta|rundll32|certutil|bitsadmin|whoami|/bin/(ba)?sh)')
        AND (
              Exe =~ '(?i)(w3wp|httpd|php|nginx|apache)'
           OR Name =~ '(?i)(chrome|msedge|firefox|brave|opera)'
        )
      )

VQL — Velociraptor

-- Velociraptor hunt: recently modified or created PHP files in WordPress directories
-- Adjust the glob to your hosting paths; flags web shells and injected malware loaders
SELECT FullPath, Size, Mtime, Ctime, Btime
FROM glob(globs=['/var/www/**/wp-content/**/*.php', '/var/www/**/wp-includes/**/*.php', 'C:/inetpub/**/wp-content/**/*.php'])
WHERE Mtime > now() - 604800
  AND FullPath =~ '(?i)(wp-content/uploads|wp-content/cache|tmp|\.ico|wso|alfa|c99|r57|shell|up\.php|wlogin)'
ORDER BY Mtime DESC

Bash / Shell

#!/bin/bash
# StopAndProtect-style WordPress compromise audit & hardening script
# Run on each WordPress host. Requires wp-cli for checksum/user checks.
# Usage: sudo bash wordpress_compromise_audit.sh /var/www/html

WP_ROOT="${1:-/var/www/html}"
REPORT="/root/wp_audit_$(date +%Y%m%d_%H%M%S).txt"

echo "=== WordPress Compromise Audit: $(hostname) $(date) ===" | tee "$REPORT"

# 1) Find PHP files modified in the last 7 days (injected web shells / malware loaders)
echo -e "\n[*] PHP files modified in the last 7 days:" | tee -a "$REPORT"
find "$WP_ROOT" -name "*.php" -mtime -7 -type f 2>/dev/null | tee -a "$REPORT"

# 2) Find PHP files in upload/cache directories (should almost never exist there)
echo -e "\n[*] PHP files in upload/cache/temp locations (high suspicion):" | tee -a "$REPORT"
find "$WP_ROOT/wp-content/uploads" "$WP_ROOT/wp-content/cache" /tmp /var/tmp -name "*.php" -type f 2>/dev/null | tee -a "$REPORT"

# 3) Hunt for common web shell signatures and obfuscation
echo -e "\n[*] Files matching common web shell / obfuscation patterns:" | tee -a "$REPORT"
grep -rlE "eval\s*\(|base64_decode\s*\(|gzinflate\s*\(|str_rot13\s*\(|assert\s*\(|shell_exec\s*\(|passthru\s*\(|system\s*\(\s*\$_" "$WP_ROOT" --include="*.php" 2>/dev/null | tee -a "$REPORT"

# 4) Verify WordPress core integrity (requires wp-cli run as the web user)
echo -e "\n[*] Core checksum verification:" | tee -a "$REPORT"
sudo -u www-data wp core verify-checksums --path="$WP_ROOT" --allow-root 2>/dev/null | tee -a "$REPORT" || echo "wp-cli not available - run manually: wp core verify-checksums" | tee -a "$REPORT"

# 5) Verify plugin integrity against wordpress.org
echo -e "\n[*] Plugin checksum verification:" | tee -a "$REPORT"
sudo -u www-data wp plugin verify-checksums --all --path="$WP_ROOT" 2>/dev/null | tee -a "$REPORT" || echo "wp-cli not available - run manually: wp plugin verify-checksums --all" | tee -a "$REPORT"

# 6) List administrator accounts - look for rogue admins created by attackers
echo -e "\n[*] Administrator accounts (verify each is legitimate):" | tee -a "$REPORT"
sudo -u www-data wp user list --role=administrator --fields=user_login,user_email,user_registered --path="$WP_ROOT" 2>/dev/null | tee -a "$REPORT" || echo "wp-cli not available - run manually: wp user list --role=administrator" | tee -a "$REPORT"

# 7) Check for web server processes spawning shells (live compromise indicator)
echo -e "\n[*] Web server processes with shell children (should be empty):" | tee -a "$REPORT"
ps auxf | grep -E "(httpd|apache2|nginx|php-fpm)" | grep -E "(sh|bash|nc|ncat|python|perl)" | grep -v grep | tee -a "$REPORT"

# 8) Find recently created archives in web-accessible paths (exfil staging of stolen data)
echo -e "\n[*] Archives staged in web root (last 14 days - potential exfil staging):" | tee -a "$REPORT"
find "$WP_ROOT" -type f \( -name "*.zip" -o -name "*.tar*" -o -name "*.rar" -o -name "*.7z" \) -mtime -14 2>/dev/null | tee -a "$REPORT"

# 9) Hardening: block PHP execution in uploads directory
echo -e "\n[*] Writing .htaccess to disable PHP execution in wp-content/uploads..." | tee -a "$REPORT"
cat > "$WP_ROOT/wp-content/uploads/.htaccess" <<'EOF'
<FilesMatch "\.(php|phtml|php3|php4|php5|php7|phps)$">
    Require all denied
</FilesMatch>
EOF

# 10) List out-of-date plugins/themes (primary initial access vector)
echo -e "\n[*] Pending updates (outdated components are the #1 intrusion vector):" | tee -a "$REPORT"
sudo -u www-data wp plugin list --update=available --path="$WP_ROOT" 2>/dev/null | tee -a "$REPORT"
sudo -u www-data wp theme list --update=available --path="$WP_ROOT" 2>/dev/null | tee -a "$REPORT"

echo -e "\n=== Audit complete. Report saved to $REPORT ==="
echo "If sections 2, 3, 7, or 8 returned results, treat the host as compromised: isolate, preserve forensics, and rebuild from a known-clean backup."

Remediation

If you operate WordPress sites:

Run the audit script above on every WordPress host today. Any hits in sections 2, 3, 7, or 8 mean treat the host as compromised: isolate it from the network, preserve disk and access logs for forensics, and rebuild from a known-clean backup — do not attempt in-place cleanup of a compromised web tier unless you have full confidence in your root-cause analysis.
Verify file integrity. Use wp core verify-checksums and wp plugin verify-checksums --all to find tampered core and plugin files. Any plugin that fails checksum verification or was installed from a nulled/pirated source must be removed.
Patch everything. Update WordPress core, all plugins, and all themes. Remove (not just deactivate) unused plugins and themes — dormant code is still exploitable code. Enable automatic updates for core and for plugins from reputable vendors.
Credential hygiene. Force password resets for all WordPress admin and hosting/SFTP accounts, enforce MFA on admin login (e.g., via a vetted 2FA plugin or SSO integration), and audit for rogue administrator accounts.
Harden the attack surface. Disable PHP execution in wp-content/uploads (script step 9), restrict xmlrpc.php if unused, limit login attempts, place the admin panel behind IP allowlisting or a WAF (Cloudflare, Sucuri, ModSecurity with the OWASP Core Rule Set), and ensure file permissions prevent the web user from writing to core directories.
Monitor egress. Alert on outbound connections from the web tier that are not update/CDN/API traffic you can name. Stolen screenshots and activity logs leave through your firewall — egress filtering catches what inbound inspection misses.

If you are defending endpoints against the delivery side:

Deploy the browser-child-process detections above. Browsers spawning PowerShell, mshta, wscript, or msiexec is the single highest-fidelity signal of drive-by delivery from compromised legitimate sites.
Script control. Enforce PowerShell Constrained Language Mode and Script Block Logging, deploy WDAC or AppLocker to block execution from user-writable paths, and disable Windows Script Host for users who do not need it.
Smart filtering, not dumb blocklisting. Because the delivery domains are legitimate, rely on proxy/browser protections that inspect content and behavior (SmartScreen, Safe Browsing, TLS-inspecting secure web gateways with script analysis) rather than domain reputation alone.
Watch for collection behavior. Alert on bulk reads of Documents/Desktop directories followed by archive creation and outbound HTTPS uploads — the toolkit's screenshots, documents, and activity logs all move through that chain.

If you find your site in the operation's infrastructure: preserve evidence first, notify affected parties per your regulatory obligations (stolen third-party data stored on your server can trigger breach notification duties), rotate all credentials, and report the compromise to your hosting provider and relevant authorities.

Related Resources

Security Arsenal Alert Triage Automation AlertMonitor Platform Book a SOC Assessment platform Intel Hub