How WP-SHELLSTORM Exposed 1.4M WordPress Sites

The SOCRadar Threat Intelligence Team traces an exposed directory back to a Chinese-linked cybercrime operation and details findings from the investigation.

Every so often, a threat actor’s mistake hands over the keys to their entire operation. That’s what happened here: a Python SimpleHTTPServer instance, left open for 22 days, exposed the full toolkit, logs, and target lists of a professional, financially motivated cybercrime group.

The SOCRadar Threat Intelligence Team found it. What turned up, now tracked as WP-SHELLSTORM, is a modern webshell access-brokerage operation: over 1.4 million targeted domains, 27 CVEs weaponized, more than 5,700 active webshells, and a second, quieter campaign hitting enterprise Java infrastructure that hasn’t surfaced in other public reporting on this actor.

Here’s the breakdown.

How Was the WP-SHELLSTORM Campaign Discovered?

On June 11, 2026, SOCRadar’s Threat Intelligence Team spotted an open directory at 137.175.93[.]126: the operator’s own home directory (/home/tance and /root), sitting on a US-based VPS with no authentication whatsoever. Inside: roughly 800MB across 434 files, including webshells, exploit scripts, scan results, bash history, and C2 configuration.

The investigation stuck to passive OSINT the whole way through: downloading what was already public, checking DNS/WHOIS records, and doing static binary analysis. No active exploitation or unauthorized access was involved.

The exposure lasted three weeks before the operator apparently noticed and tried to clean up (more on that below).

Who Is Behind the WP-SHELLSTORM Attacks?

Attribution in cases like this is rarely a slam dunk, and it’s worth being upfront about which links are solid versus circumstantial. Here’s what our team has pieced together:

• System user “tance”: the operator’s own bash history ends with cd /home/tance followed by launching a tmux session, and the exposed directory is rooted there.
• The handle “chen-kk”: found embedded in a filename among the operational tools.
• “chenyk” / [email protected]: a developer identifier found in a separate, related campaign’s victim configuration data (more on that campaign shortly). The “chen” prefix overlaps with “chen-kk,” but the team is treating this as circumstantial: “chen” is an extremely common Chinese surname, and 163.com is simply a popular Chinese webmail provider. The stronger link between the two campaigns isn’t the name; it’s that they were run from the same staging server.
• FOFA reconnaissance: the actor used FOFA (the Chinese equivalent of Shodan) for target discovery, and FOFA accounts require a Chinese phone number to register. That’s a genuinely actionable data point, since FOFA has a law-enforcement cooperation channel.
• Simplified Chinese throughout: comments in the exploit code, and a directory literally named “nacos-xxljob批量” (batch), among other tells.

There’s also an interesting wrinkle: one IP address in Taiwan (113.196.56.150) generated over 42,000 requests against the exposed server, systematically downloading the actor’s own tools. The team isn’t overreaching here; it could be a second operator, a customer, or a researcher who found the same directory. Log data alone can’t settle it.

The SOCRadar Threat Intelligence Team’s overall read: this isn’t a nation-state APT crew. It’s a professional, financially motivated cybercrime group (what’s sometimes called a WABO, or Webshell Access Brokerage Operation) with medium-to-high technical capability and, ironically, fairly weak operational security.

What Other Platforms Does the WP-SHELLSTORM Actor Target Beyond WordPress?

This is a finding that hasn’t surfaced anywhere else. Most public reporting on this actor (including a related writeup from June 22, covering the same open directory) has focused entirely on the WordPress side. But the operator’s bash history reveals a second, parallel track: scanning and exploiting Apache Nacos, XXL-Job, and Spring Boot, the backbone of a lot of microservice and fintech infrastructure, especially in systems with Chinese-origin components.

The tooling included:

• A SQL injection scanner for Nacos’s embedded Derby database
• An RCE tool for XXL-Job, a distributed job scheduler
• A Spring Boot heap-dump scanner, paired with the open-source JDumpSpider tool for pulling credentials out of memory dumps

What makes this genuinely dangerous is the chaining. Nacos configuration files routinely contain XXL-Job admin URLs and access tokens as part of normal distributed-scheduler setup. So a single Nacos auth bypass can hand an attacker a working admin token for XXL-Job, and from there, arbitrary remote code execution on every executor node connected to that instance. No password guessing required.

What Was the May 2026 Nacos Credential Theft Campaign?

Digging into the timeline, the SOCRadar Threat Intelligence Team found that this Java-focused activity wasn’t just a side project. It was an earlier, separate campaign. Over just two days in early May 2026, the actor exfiltrated 613 configuration files from 11 victim systems across nine organizations spanning fintech, e-commerce, logistics, gaming, and consumer electronics. Using the well-documented Nacos authentication bypass (CVE-2021-29441: send a request with a “Nacos-Server” User-Agent header and skip auth entirely), they pulled:

• Cloud credentials for AWS, Alibaba Cloud, Oracle Cloud, Tencent Cloud, and DigitalOcean (5 victims)
• Production database connection strings and passwords (9 victims)
• Alipay RSA private keys (2 victims)
• JWT secrets, third-party API keys, and internal service tokens

One victim even had a Telegram bot token for payment notifications sitting in plaintext config, a small but telling reminder of how often “internal” configuration servers end up holding the keys to production payment systems.

The team’s assessment is that this was the actor’s funding round: harvest high-value credentials first, then pivot, five weeks later, into the much noisier, higher-volume WordPress webshell business. Same staging server, same toolset (the XXL-Job exploit script shows up in both campaigns’ file trees), different monetization strategy. All identified active cloud credentials were reported to the relevant providers for revocation, and affected organizations were notified through responsible disclosure.

What Malware and Webshells Does the WP-SHELLSTORM Actor Use?

The webshell side of the operation is a genuinely layered piece of engineering. The primary shell, down.php, is wrapped in four separate obfuscation passes: ROT13-and-hex, then base64-gzip, then variable-name obfuscation, before finally unpacking into a full-featured shell derived from the open-source BestShell project. Once running, it can browse and manage files, execute OS or PHP code, spin up reverse shells, fingerprint the host’s AV/WAF/EDR stack, scan for open ports, and manage MySQL, making it a fairly complete post-exploitation Swiss Army knife.

Alongside it: a Godzilla-framework shell using XOR-encrypted C2 traffic, a one-line dropper that writes a hidden file manager to disk, and a shell that camouflages itself by returning HTTP 404 to normal visitors and blocking known crawler user-agents.

For remote access, the operator used a dropper (tracked as SNOWLIGHT) that detects the target’s CPU architecture and pulls down a matching implant over WebSocket traffic, a technique intended to blend into normal HTTPS-adjacent traffic rather than standing out as a raw C2 connection. The implant itself, identified as VShell, takes deliberate steps to avoid detection: once running, it renames its own process to “[kworker/0:2],” mimicking a routine Linux kernel worker thread so it doesn’t jump out in a ps aux listing.

One data point stood out as clean evidence of an active botnet rather than isolated infections: at 13:30:44 UTC on June 11, within the same one-second window, 24 separate IP addresses all pulled down the same payload archive, one second after the operator ran a test download themselves. That’s coordinated command distribution, not opportunistic scraping.

How Large Is the WP-SHELLSTORM Campaign?

The most productive single exploit was a Breeze Cache Cleaner flaw (45,000+ targets, 17,000+ confirmed shells), followed by a ThemeREX Addons vulnerability (3,378 shells from 46,600 targets). At the other end of the scale, a Joomla JCE vulnerability was fired at over 560,000 targets but yielded only 77 confirmed shells, a useful reminder that raw target count and actual success rate can diverge wildly depending on how patched a given ecosystem is.

Did the Threat Actor Try to Cover Their Tracks?

Here’s the part with a bit of dramatic irony: the SOCRadar Threat Intelligence Team was monitoring the open directory’s access logs over time, and between the team’s first look on July 2 and a follow-up on July 4, the log file’s line count dropped sharply, with entries covering that exact window deleted. In other words, once the actor realized the exposed server had been found, they scrambled to cover their tracks. It didn’t undo the three weeks of prior exposure, but it’s a clear signal they knew they’d been spotted.

That log-tampering sits alongside a broader pattern of self-inflicted wounds: a FOFA config file left sitting in the open directory (traceable via FOFA’s own law-enforcement cooperation process), an un-scrubbed bash history revealing the full Java-side campaign, and hardcoded webshell credentials that make cross-correlating infections trivial. For a group running a genuinely sophisticated toolchain, the operational security was notably weak.

How Can You Defend Against the WP-SHELLSTORM Campaign?

If you run WordPress, Joomla, or any Java microservice stack, a few concrete steps:

Immediately:

• Block the known infrastructure: 137.175.93[.]126, 43.108.17[.]80, 113.196.56[.]150, and the domain xs.xxooonline[.]eu[.]cc
• Scan for the webshell filename patterns below
• Watch for processes named “[kworker/X:Y]” that don’t correspond to a real kernel thread: run ps aux | grep kworker and check whether /proc/<pid>/exe actually resolves to a kernel path

If you run Nacos:

• Upgrade to 2.2.1 or later, and make sure nacos.core.auth.enabled=true
• Test your own exposure with a header-based check: a request using the “Nacos-Server” User-Agent against /nacos/v1/core/cluster/nodes should not return data without authentication
• If you were ever exposed to CVE-2021-29441, rotate every credential that lived in that Nacos instance, not just the obvious ones

If you run XXL-Job or Spring Boot:

• Close unauthenticated XXL-Job executor endpoints and segment them from the internet
• Disable /actuator/heapdump in production and lock down all other Actuator endpoints behind authentication

For WordPress/Joomla specifically, the plugins below were directly targeted in this campaign and should be updated (or disabled) without delay if you’re running them:

(This table highlights the most heavily targeted plugins; the campaign touched 27 CVEs in total, including several with limited public exploitation data so far, worth a scan if you’re running anything from a smaller plugin vendor.)

What Are the Indicators of Compromise (IOCs) for WP-SHELLSTORM?

Have WordPress or Nacos/XXL-Job infrastructure exposed to the internet? Now’s a good time to check your logs against these IOCs. If you’d rather have this kind of exposure surfaced automatically, SOCRadar’s Attack Surface Management (ASM) module is built for exactly this: flagging forgotten servers and open directories before an actor like this one finds them first.

• 137.175.93[.]126: operator’s staging/tool server (US-based VPS)
• 43.108.17[.]80: C2 / VShell payload host (Alibaba Cloud, Singapore)
• 113.196.56[.]150, 113.196.59[.]51: high-volume access IPs (Taiwan, unattributed)
• xs.xxooonline[.]eu[.]cc: SNOWLIGHT stager domain

Webshell filenames to search for: .bd.php, .wp-log.php, .brq-.php, .sd.php, .leo_.php, .wvp-.php, .cc-.php, .nf-log.php, BZ_*.phtml

Primary webshell hash (down.php, SHA256): 84F7E396A48913851A10CC78C5CC22A25634564ABD0694465236D2F365E2BDEE

This is a partial list. The investigation turned up a considerably longer set of file hashes, shell variants, and a full mapping to the MITRE ATT&CK framework. Full details are available in the SOCRadar XTI platform’s Campaigns page.