Chinese-Speaking Operator Uses AI Agents to Target Government and Education Systems Across Asia Learn More Hunt.io Product Features OEM Pricing About Blog Login Get a Demo To embed a website or widget, add it to the properties panel. Chinese-Speaking Operator Uses AI Agents to Target Government and Education Systems Across Asia Learn More Hunt.io Product Features OEM Pricing About Blog Login Get a Demo To embed a website or widget, add it to the properties panel. Chinese-Speaking Operator Uses AI Agents to Target Government and Education Systems Across Asia Learn More Hunt.io To embed a website or widget, add it to the properties panel. Home Blog Redis Cryptomining Botnet Compromised 3,562 Servers, Exposed by the Operator's Own Files Redis Cryptomining Botnet Compromised 3,562 Servers, Exposed by the Operator's Own Files Published on Sep 8, 2026 TABLE OF CONTENTS Key Findings Overview: The Complete Attack Chain Scope Summary Initial Access and Reconnaissance Command-and-Control and Persistence Architecture Exploitation Techniques Payload and Monetization Victim Impact Analysis Command and Control Infrastructure Operational Security and Anti-Analysis Techniques Operator Tradecraft Assessment Infrastructure Analysis Indicators of Compromise Conclusion Note on withheld data: Individual victim IPs are aggregated by network block, not listed. Sensitive data incidentally exposed on unrelated third-party sites has been removed from this report and, where possible, reported to the relevant providers. This report documents attacker infrastructure and tradecraft; it is not a disclosure against any named organization. Most open directories tied to a cryptomining campaign hold a payload and little else. This one held the operator's entire working toolkit. We found it on port 80 at 188.245[.]99.156 and pulled 147 files: Python exploit source, JSON campaign-result logs, a bundled portable Python 3.11 runtime, and two exported Windows registry hives. Production scripts sit next to abandoned test scaffolding, bugfix comments carried over from earlier drafts, and raw campaign telemetry never meant for an outside reader. That matters for everything downstream: the numbers, techniques, and infrastructure in this report all trace back to the operator's own files rather than to the summaries their scripts print. Hunt.io first indexed the directory on 2026-06-21 and last confirmed it live on 2026-06-27, a window covered in full in the Infrastructure Analysis section. Key Findings Directly parsing the operator's own campaign logs shows 3,562 distinct Redis servers compromised across two runs against a shared 12,966-host list; 22 to 26% of targets were compromised and most of the rest blocked on authentication. Confirmed victims span Redis 2.8.17 (2015) through 7.2.0 (2023) and Linux from EOL RHEL/CentOS 6 to current Ubuntu kernels, pointing to missing authentication as the weakness rather than a version-specific bug. A third run against the pre-qualified 2,342-host no-auth fleet hit 72.6%, roughly triple the full-fleet rate, pointing to target-list freshness rather than the technique as the limiting factor. The toolkit runs four techniques across three services, but only Redis rogue replication worked at scale: SSH key-injection and MongoDB sandbox-escape returned zero across 2,810 attempts, and a complete WordPress credential-to-webshell chain was recovered but not confirmed at scale. The Monero wallet hardcoded throughout the toolkit also appears in a separate February 2026 open directory at 194.48.248[.]105 (Moldova), a Meterpreter and XMRig kit with no Redis component, pushing the operator's known activity back at least five months. The operator runs local cryptomining on their own host using the same wallet as the botnet payloads, tying the campaign's monetization directly to their workstation. The directory is a live working environment, not a payload drop: an R&D trail of persistence paths probed but never shipped (SysV init, /etc/modprobe.d, a webshell-via-Redis pivot) sits alongside narrow anti-analysis engineering, a runtime-only fileless loader and chr()-encoded string literals. The same recon infrastructure incidentally exposed sensitive data (SQL dumps, phpinfo() output, .git/config credentials) from unrelated third-party sites, which we have withheld and reported separately. Overview: The Complete Attack Chain The diagram below is the whole operation end to end, mass reconnaissance through to confirmed monetization. It brings together the three techniques that actually produced a measurable outcome: SLAVEOF rogue replication, AOF-based SSH key injection, and the Lua sandbox probe, plus the separate WordPress track running alongside it. One technique doesn't appear here: the multi-mechanism persistence bundle. It only ever ran against the operator's own QA host, never against the production fleet, so there's no campaign-scale outcome to plot for it. Every labeled edge below is backed by an artifact walked through in the sections that follow. Figure 1. The full attack chain, recon through confirmed monetization, with the SSH_INJECT, LUA_PROBE, and WP_SPRAY branches. The MongoDB reconnaissance-only probe targets a different service entirely and is omitted from this Redis-centric chain; it appears in its own row in the scope table below. The remainder of this report walks each branch of this chain in protocol-level detail, quantifies the confirmed-victim branch precisely, and documents the operator's own infrastructure and tradecraft before closing with indicators of compromise. Scope Summary Track Primary technique Confirmed impact Redis (primary) Rogue replication → cron injection → XMRig 3,562 distinct hosts compromised (of 12,966 targeted) Redis (secondary) AOF → SSH authorized_keys injection 0 of 2,342 confirmed MongoDB db.eval() JS sandbox escape probing 0 of 468 confirmed (script execution only) WordPress Credential spray, admin takeover, webshell staging Chain complete; scale not independently quantifiable from recovered files Initial Access and Reconnaissance Redis target discovery The operator works from a master list of 12,966 candidate Redis hosts (targets.txt, mirrored as redis_fleet.txt), narrowed down to 2,342 confirmed to take commands without authentication (noauth_hosts.txt). The bigger list looks like the output of a broad internet-wide sweep for anything listening on Redis's default port 6379. The smaller one is what's left after an initial PING/AUTH probing pass, the actual candidate pool for every no-auth technique described later in this report. Figure 2. Redis host discovery and authentication probing across internet-facing targets. WordPress target discovery A separate pipeline, wp_scan_results.json, runs against a completely different population of HTTPS hosts, checking each one for WordPress: version, installed plugins, and whether XML-RPC or directory listings are exposed. The plugin data goes deeper than a simple detection flag, one confirmed site running the breeze caching plugin at version 2.5.6 is marked "vulnerable": false, which only makes sense if the scanner is cross-referencing a real vulnerability database rather than just fingerprinting versions. Figure 3. WordPress fingerprinting, plugin enumeration, and exposure detection. 212 hosts out of that population come back as confirmed WordPress installs ("wp": true). Those 212 feed straight into fast_cred_results.json, a second-stage file that enumerates usernames per site, the direct input to the credential-spray stage covered later in this report. MongoDB target discovery A third target list, independent of the other two, gets probed for MongoDB's legacy server-side JavaScript execution feature. mongo_mine_results.json logs, per confirmed-scriptable host (468 of them), the MongoDB version in play, spanning long-dead releases like 2.4.14 up through 4.0.3, plus the full global-scope constructor chain available inside the JS sandbox and explicit checks for process, load(), and require(). That's the standard checklist for anyone probing a JavaScript sandbox for an escape. Figure 4. MongoDB host discovery and server-side JavaScript capability testing Incidental data exposure from unrelated third-party sites Separate from all three campaigns above, cred_scan_results.json runs a lighter sweep of the same HTTP/HTTPS population, just looking for exposed backup files, directory listings, and leaked credentials. Most entries come back empty ("backups": [], "leaks": [], "creds": null), but the hits get rolled up into cred_attack_results.json and, in more raw detail, leaked_data.json. None of it connects to the Redis, MongoDB, or WordPress work elsewhere in this report, it looks like the same scanning infrastructure being pointed opportunistically at whatever it happens to trip over. Confirmed exposures (hosts partially masked): 173.212[.]x.x: a readable SQL database dump on a WordPress site (Germany) 39.101[.]x.x: a readable SQL database dump on a WordPress site (China, logistics sector) 137.116[.]x.x: exposed phpinfo() output, full PHP configuration and environment disclosure 173.231[.]x.x: exposed phpinfo() output, full PHP configuration and environment disclosure 18.130[.]x.x: an exposed .git/config file revealing a private source-repository remote 54.88[.]x.x: an exposed .git/config file revealing a private source-repository remote 164.90[.]x.x: a readable directory listing under /wp-content/uploads/ 196.200[.]x.x: an exposed application test page on a student login/registration platform So the scanning infrastructure picks up sensitive material, database contents, environment configs, source-control credentials, from any site it happens to touch, regardless of whether that site was ever an actual target. None of these hosts show up anywhere else in this report, and I found nothing suggesting this exposed data was ever used against the Redis, MongoDB, or WordPress targets described elsewhere. Command-and-Control and Persistence Architecture Bef