The first rule of Fight Club? First rule of botnet bandits? The same. Don’t talk about Fight Club or give cybersecurity researchers your criminal playbook.
That’s where threat actors behind a Redis-based botnet blew it. Researchers at Hunt.io found the complete infrastructure and tradecraft of a Redis Cryptomining Botnet exposed on a live production commercial server by German cloud computing giant Hetzner.
Next, Hunt.io simply downloaded the botnet platform, reverse-engineered the operator’s files, mapped the entire criminal footprint, formulated defensive strategy and notified those impacted.
“The whole picture, the campaign logs, the R&D trail, the wallet reuse, came from one exposed directory indexed while the operator was still working in it,” Hunt.io wrote in a research blog outlining the eventual Redis botnet exposure and June 27 shuttering.
The Redis botnet is named after the Redis in-memory database which is used to cache data and speed websites and apps. The operator behind the botnet are unknown, but their profile is typical.
Based on Hunt.io’s analysis, the operator hijacked computing power to mine cryptocurrency (Monero), running the campaign from a rented server in Germany that doubled as command-and-control infrastructure. Beyond the mining itself, toolkits hosted on Hetzner also included failed attempts to plant SSH backdoors and hijack MongoDB servers. Also believed targeted, but not confirmed at scale, were WordPress credential-and-webshell operations.
In size, the disrupted botnet campaign is mid-tier: not a sprawling, but one that reached thousands of servers off a broad, internet-wide sweep of exposed targets. It’s unclear how profitable this campaign earned operators. Researchers estimated adversaries compromised 3,562 servers, infecting them with tiny virtual machines that taxed CPUs to mine Monero cryptocurrency.
“The victim data spans eight years of Redis releases,” researcher wrote. Over those years the campaigns targeted Linux versions from EOL RHEL/CentOS 6 to current Ubuntu kernels.
Years of Abuse Went Largely Unnoticed
Based on Hunt.io’s analysis, the operator’s infrastructure shows signs of activity stretching back more than a year. A certificate tied to the operator’s own Windows host was seen as far back as June 2025, and the domain linked to their command server resolved continuously through July 2026.
Central to the operator’s tradecraft was a custom-built Python toolkit. Hunt.io doesn’t name it, but it handled everything from scanning for vulnerable targets to deploying the miner and checking in with infected machines.
That toolkit was used to scan the internet for Redis servers left open without a password, then quietly plant a scheduled task that downloaded and ran cryptomining software.
The 3,562 confirmed victims were largely unaware anything had happened. That’s because the operator’s tooling restored each server’s settings right after the attack. This left no obvious trace of tampering and routed any crypto-mining traffic over a standard, encrypted web port. This created a layer of stealth; as traffic blended in with normal internet activity rather than standing out to network monitoring.
No Bug Required: Just an Open Door
This wasn’t a flaw in Redis, MongoDB, or WordPress. Hunt.io is explicit that the core technique “abuses legitimate replication functionality nobody removed, not a bug a point release could patch out.” Every command the malware sent was one Redis is designed to accept.
Here’s how it worked: rather than sneaking in disallowed commands, the malware stood up a rogue Redis server and tricked victims into treating it as a replication master. Each victim then did exactly what a Redis replica is supposed to do. It connected to the fake server and was tricked into saving a malicious file to a system folder that runs scheduled tasks. That file quietly triggered a download of cryptomining software, which began generating Monero for a wallet built into the attacker’s toolkit.
Two other paths in the same toolkit – SSH key injection and a MongoDB exploit – were built but failed completely and blocked by authentication on every attempt.
The same toolkit also tried to break in via SSH and MongoDB — and both failed outright, blocked at the first authentication check. It’s a small but telling data point: turning on authentication didn’t just prevent the Redis attack, it stopped every other technique in the kit before it could do anything at all.
Hunt.io’s point: the fix only required one simple thing. SSH failed at authentication. MongoDB failed at authentication. Even parts of the Redis attack failed there. One password would have stopped every subsequent technique in the toolkit chain.
Bumbling Botnet Operators?
Hunt.io’s researchers don’t describe the operator’s tooling as haphazard, even though the infrastructure was left exposed. If anything, researchers read it the opposite way. Also unearthed were the operator’s inline bugfix comments carried forward across script revisions and dedicated quality assurance test hosts. This pointed to a sophisticated adversary that “iterates on and debugs their own tooling rather than running a static kit off the shelf.”
The toolkit also revealed one more clue: the same Monero wallet address used in this campaign shows up in a separate attack Hunt.io found back in February 2026, on unrelated servers in Moldova. That earlier attack used different tools, not Redis. It was the shared wallet that connected the operator to both campaigns.
So much for an intricate backend, the botnet’s death knell wasn’t tied to any advanced malware analysis. Rather, it was the adversary leaving their live working toolkit and campaign logs exposed in an open directory on port 80.
It’s a lesson for anyone managing an internet-facing service. Without a password you’re bacon is cooked.
