🚨 Redis Cryptomining Botnet Compromised 3,562 Servers, Exposed by the Operator’s Own Files

Researchers indexed an open directory on 188.245.99.156 (Hetzner) that held an operator’s full Redis cryptomining toolkit, not just a payload. 147 files in total: Python exploit source, JSON campaign logs, a bundled portable Python 3.11 runtime, and two exported Windows registry hives. Because the raw campaign logs were sitting there, the numbers come from the operator’s own per-host records, not the summaries their scripts print: 3,562 distinct Redis servers compromised out of 12,966 targeted, across two independently coded runs The only technique that scaled is rogue replication: PING to confirm no-auth, CONFIG SET dir/dbfilename, SLAVEOF to a rogue master, then a crafted RDB blob with an embedded newline that drops a cron entry into /etc/cron.d/ That cron job pulls a legit XMRig release straight from GitHub and points it at pool.moneroocean.stream:443 over TLS SSH key injection via AOF returned 0 of 2,342, MongoDB JS sandbox escape 0 of 468. Every SSH attempt bounced at the first CONFIG SET with AUTH_REQUIRED Confirmed victims span Redis 2.8.17 to 7.2.0, so this is missing authentication, not a version-specific bug A third run against a pre-qualified no-auth list hit 72.6%, roughly triple the full-fleet rate, so target-list freshness is the real limiter, not the technique The same Monero wallet turns up in a separate February 2026 open directory in Moldova with Meterpreter and XMRig deployers and no Redis component, which pushes known activity back at least five months Fix is config, not patching: requirepass, disable SLAVEOF/REPLICAOF where replication is not in use, or enable protected-mode. Upgrading does nothing here. Full write-up with IOCs: https://hunt.io/blog/redis-cryptomining-botnet-3562-servers submitted by /u/Straight-Practice-99 [link] [comments]Technical Information Security Content & DiscussionRead More