Do Son 
At a Glance
| Malware family | XMRig cryptominer deployed via Redis abuse |
| Threat actor | Unnamed operator (suspected single actor, linked by wallet reuse) |
| Target / victims | 3,562 internet-facing Redis servers, mostly APAC cloud hosts |
| Delivery vector | Redis rogue replication (SLAVEOF) into cron injection |
| Key capabilities | Cron persistence, XMRig mining, C2 heartbeat, multi-path fallback |
| Source | Hunt.io research on an exposed operator directory |
TL;DR
A Redis cryptomining botnet compromised 3,562 servers by abusing Redis replication to plant Monero miners. Researchers found the operator’s full toolkit in an open directory. The campaign relied on missing authentication, not any software bug.
How Researchers Found the Redis Cryptomining Botnet
Security firm Hunt.io found an exposed web directory on a rented Hetzner server in Germany. The directory held the operator’s entire working kit. Researchers pulled 147 files from it, including Python exploit code and campaign logs.
As the Hunt.io report puts it, “Most open directories tied to a cryptomining campaign hold a payload and little else. This one held the operator’s entire working toolkit.” That rare access let analysts count victims from raw data.
The Rogue Replication Attack Explained
The main technique is a rogue replication attack against Redis. The operator points a victim at a fake Redis master. The victim then pulls a crafted data file and writes it to disk.
This method needs no exploit. It abuses a normal Redis feature instead. The report notes the trick works “no authentication bypass and no memory-corruption bug required.”
From Replication to Cron Persistence
The crafted file lands in a cron directory as a scheduled job. That job fires every five minutes on the victim host. It then downloads XMRig straight from the official GitHub page.
Pulling the miner from GitHub is a deliberate choice. The request resolves to github.com, not attacker infrastructure. This helps the traffic slip past basic egress monitoring.
Command and Control and Monero Mining
Each infected host connects to a public Monero pool over port 443. The miner uses TLS to blend in with normal HTTPS traffic. A hidden binary named .xmrig runs the mining work.
Separately, each host pings a Python C2 service over plain HTTP. That heartbeat reports whether a host stays alive. The operator logs every check-in to a local database.
The same Monero wallet appears in every payload. It also appears on the operator’s own local mining setup. That reuse links the botnet’s profit directly to the operator’s workstation.
Confirmed Victims and Real Numbers
The victim count comes from the operator’s own logs, not marketing figures. Two runs against a 12,966-host list produced 3,562 distinct compromises. The success rate per run sat between 22 and 26 percent.
Most targets blocked the attack at the authentication stage. A third run told a sharper story. Against a pre-checked no-auth list, the same code hit 72.6 percent.
Confirmed victims ran Redis versions from 2.8.17 up to 7.2.0. That eight-year spread points to weak deployment settings. As the report states, the weakness is “purely deployment/configuration, no authentication set, not a version-specific bug.”
Techniques That Failed
The toolkit tried more than one path. SSH key injection returned zero results across 2,342 hosts. A MongoDB sandbox escape probe also failed at scale.
A WordPress credential spray chain was recovered but never confirmed at scale. Only the Redis rogue replication attack worked reliably.
Attribution: Suspected, Not Confirmed
Attribution here is suspected, not confirmed. Wallet reuse ties this campaign to an earlier February 2026 directory in Moldova. That older kit deployed Meterpreter and XMRig with no Redis part.
Wallet reuse proves shared monetization only. It does not prove one person wrote both toolkits. Infrastructure clues suggest a Windows host running inside a Docker container.
Defense and Detection Guidance
Never expose Redis to the public internet. Bind it to localhost or a private network only. Require authentication and enable protected mode on every instance.
Rename or disable dangerous commands like CONFIG, SLAVEOF, and REPLICAOF. Watch for unexpected replication events from unknown hosts. Audit cron directories, apt.conf.d, and profile.d for stray entries.
Defenders should not assume the visible cron entry is the only foothold. The operator built redundant persistence across several surfaces. A single cleanup often leaves other hooks in place.
Indicators of compromise include a hidden miner in the temp directory and outbound TLS traffic to a known Monero pool. Blocking mining pool domains at the network edge adds a useful layer.
Why This Redis Cryptomining Botnet Matters
This case shows how old, well-known techniques still pay off. The rogue replication method has circulated for years. Yet thousands of servers remain exposed and unauthenticated.
The lesson is simple and practical. Fix the deployment, not just the version. Authentication and command restriction remain the only real defense.
Support Our Threat Intelligence
Find our threat intelligence and malware analysis helpful? Support our work today and unlock a 100% ad-free reading experience!
Buy Me a Coffee
