Loading story…
An exposed directory on 188.245.99.156 revealed a cryptomining operation that compromised 3,562 internet-facing Redis servers from a target list of 12,966 hosts. The operator abused Redis instances with no authentication through rogue replication, using crafted RDB payloads to install cron-based persistence and download XMRig miners configured for the MoneroOcean pool. Two principal campaign runs achieved 26.1% and 22.1% compromise rates, while a prequalified unauthenticated target list yielded 72.6%, indicating that stale target data—not the underlying technique—limited the campaign.
The same server hosted rogue replication listeners, payload staging, and HTTP heartbeat collection, and reuse of a Monero wallet tied the infrastructure directly to monetization and to a separate February 2026 Meterpreter/XMRig toolkit. Attempts to inject SSH authorized_keys and probe MongoDB did not produce confirmed compromises; researchers also recovered, but could not quantify, a WordPress credential-spraying and webshell-staging chain. Organizations should require Redis authentication, restrict network exposure, and disable or tightly control replication commands where not required; upgrading Redis alone does not remediate unauthenticated deployments.
Map this exposure pattern across your cloud, code, and identities.
9 events from the most recent confirmed update back to the earliest known activity.
Researchers last confirmed that the exposed directory on 188.245.99.156 was live. The infrastructure was used for rogue Redis replication, payload staging, and miner heartbeat collection.
Hunt.io first indexed an exposed 147-file operator directory on 188.245.99.156. It contained Python exploitation code, campaign-result logs, a portable Python runtime, and exported Windows registry hives.
A separate open directory at 194.48.248[.]105:8081 was first indexed containing Linux shell-based Meterpreter and XMRig deployment tooling. The toolkit had no Redis component, but used the same Monero wallet later observed in the Redis-mining operation.
Reporting identified additional operator infrastructure and indicators, including a mining-pool proxy at 45.155.102.89:10128, socket.ayakliborsa.net:8081 resolving to 188.245.99.156, rogue replication listeners on ports 16379-16385, and a hostname callback URL pattern. It also documented recovered tool filenames and an XMRig pool TLS certificate SHA-256 fingerprint.
Recovered tooling targeted 212 WordPress installations with username enumeration, XML-RPC and wp-login.php credential spraying, and plugin-install webshell staging. A separate WordPress attempt against 31 targets produced no successful webshell deployments.
Redis-based SSH authorized_keys injection achieved no successful key injections or SSH logins across 2,342 targets, largely because hosts returned AUTH_REQUIRED. MongoDB server-side-JavaScript probing of 468 hosts likewise produced no confirmed sandbox escapes.
A third rogue-replication run against 2,342 pre-qualified unauthenticated Redis hosts compromised 1,701 systems, a 72.6% success rate, without adding victims beyond the established 3,562-host total. The result indicated that stale target lists, rather than the replication technique, constrained the broader campaign.
The rogue-replication workflow delivered a crafted RDB payload that wrote cron entries, primarily at /etc/cron.d/.redis-miner, then downloaded XMRig v6.22.2 from GitHub. The miners connected to pool.moneroocean[.]stream on TCP/443 using TLS and reported host heartbeats to 188.245.99.156:10000.
Two campaign runs targeting a shared list of 12,966 internet-facing Redis servers compromised 3,562 distinct hosts, with 2,688 victims overlapping between runs. The operation abused unauthenticated Redis access and rogue replication rather than a version-specific vulnerability.
Vulnerabilities, threat actors, malware, products, organizations, breaches, and observables Mallory has linked to this story. Indicator values are masked here and available in full in the app.
Indicator values are masked on this page. View all 22 in Mallory Domains, IPs, hashes, and URLs are exportable to your SIEM.
See where this exposure pattern shows up across your cloud, code, supply chain, and non-human identities.
5 references tracked. Mallory keeps watching after this page renders.
community.gurucul.com
Open sourcecryptika.com
Open sourcecybersecuritynews.com
Open sourcereddit.com
Open sourcehunt.io
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
AhnLab Security intelligence Center (ASEC) reported an ongoing campaign targeting poorly managed Linux servers, where attackers gain access through SSH brute-force attempts or stolen credentials and then deploy propagation malware to install **XMRig**-based coin miners. Observed through multiple honeypots, the activity uses a multi-stage toolset that includes Go-based downloaders and SSH spreaders, along with malware families such as **ShellBot/PerlBot**, **MIG LogCleaner**, and **XHide** to move laterally, fetch payloads, hide activity, and maintain control of compromised hosts. The miners are disguised as legitimate processes and are installed with multiple persistence mechanisms, including `systemd` services, cron jobs, hidden binary paths, and watchdog functions that restore deleted payloads. ASEC said the propagation malware scans for exposed SSH services, authenticates with credential lists, installs miners on newly compromised systems, and reports results back to attacker infrastructure, assessing that the same threat actor has likely been conducting Linux-focused cryptomining attacks since at least 2023.
Jul 15, 2026
Palo Alto Networks Unit 42 reported a self-replicating peer-to-peer worm dubbed **P2PInfect** that compromises exposed Redis servers by exploiting **`CVE-2022-0543`**, a critical Lua sandbox escape affecting Debian-packaged Redis deployments. The malware is written in **Rust**, targets both **Linux** and **Windows**, and was observed attacking Redis honeypots in Unit 42’s HoneyCloud environment. Researchers estimated that **934** internet-exposed Redis systems could be vulnerable out of more than **307,000** observed Redis instances. The worm uses a **P2P architecture** to spread, exchange node lists, and deliver updated binaries, giving operators a built-in mechanism to expand the botnet and push future payloads. Unit 42 also observed scanning for additional exposed Redis hosts and port **`22`** for SSH, although no confirmed SSH exploitation was seen. On Windows, the malware showed persistence and defense-evasion behavior including firewall rule changes, obfuscated PowerShell, a monitor process, self-updating binaries, and deletion of the initial dropper. Binaries named **`miner`** and **`winminer`** were recovered, but researchers said they found no definitive evidence that cryptomining had been activated.
Aug 14, 2026
Researchers disclosed multiple authenticated remote code execution paths in Redis, showing how users with valid Redis credentials could potentially escalate from datastore access to host-level shell access on stock builds including Redis `6.2.22`, `7.4.9`, `8.6.4`, and `8.8.0`. The reported issues include a stream consumer-group shared-`NACK` double-free linked to the `CVE-2026-25589` incomplete-fix family and a heap overflow in the bundled RedisBloom `TDigest` module affecting Redis `8.8.0`. The attack chains rely on commonly enabled capabilities such as `EVAL`, `RESTORE`, and `XGROUP`, and the report said the double-free was only fully fixed in `8.8.0` while that same release still remained exposed to the RedisBloom bug at disclosure time. At the same time, new offensive-security tooling emerged to help identify exposed Redis deployments. A Rapid7 Metasploit pull request introduced an auxiliary scanner for `CVE-2025-49844` ("RediShell") that checks whether a Redis server is running an unpatched branch and whether Lua `EVAL` is reachable, highlighting how configuration choices such as ACLs can reduce practical exploitability even on vulnerable versions. The combined disclosures underscore the need to patch Redis promptly, restrict dangerous commands, keep Redis off the public internet, rotate credentials, review RedisBloom usage, and monitor for anomalous command activity that could indicate exploitation attempts.
Jul 24, 2026