Redis Botnet Hijacks 3,562 Servers, Operator Files Expose Toolkit

The Redis cryptomining botnet has compromised 3,562 servers by exploiting unauthenticated Redis instances, and the operator’s own leaked files revealed the full attack toolkit, confirming the scale and methods of the campaign. The evidence, hosted on a Hetzner IP, includes Python exploit code, campaign logs, a portable Python runtime, and Windows registry hives, giving researchers unprecedented insight into the operation.

How did the attackers compromise Redis servers without authentication?

Attackers scanned public IP ranges for Redis instances that left authentication disabled, a common misconfiguration in cloud‑native deployments. Once a target responded to a simple PING command, the script issued CONFIG SET dir and CONFIG SET dbfilename to point the database dump location to a writable directory, then used SLAVEOF to force the victim to replicate from a malicious master.
Because the technique relies only on configuration commands, it works across Redis versions from 2.8.17 to 7.2.0, as noted by researchers who observed no version‑specific bugs (source: r/netsec discussion).

What techniques did the botnet use to install Monero miners?

After hijacking the replication stream, the attackers crafted a malicious RDB (Redis database) blob that contained a newline‑injected cron entry. When the victim wrote the dump, the cron file landed in /etc/cron.d/, scheduling a job that pulls the official XMRig binary from GitHub over TLS and points it at pool.moneroocean.stream:443.
This approach keeps the payload low‑profile and leverages legitimate download channels, making network‑based detection harder.

Why did the campaign achieve a 72.6% success rate on a fresh target list?

The operators maintained a “pre‑qualified” list of no‑auth Redis hosts that had been verified recently. When they ran a third campaign against that list, they reported a 72.6% infection rate—roughly three times higher than the overall 22‑26% success seen in the full‑fleet attempts. The data suggests that list freshness, not the exploitation technique, is the primary limiter (source: r/netsec discussion).

What does the exposed toolkit reveal about attacker operational hygiene?

The leaked directory contained 147 files, including the original Python exploit source, raw JSON logs for each compromised host, a bundled portable Python 3.11 runtime, and two exported Windows registry hives. The presence of raw logs means the attacker kept detailed per‑host records, a practice more common in financially motivated campaigns than in espionage operations.
It also shows a level of professionalism: the team packaged a self‑contained runtime to ensure the payload runs on any Linux host, and they stored Windows registry hives for later pivoting, indicating multi‑platform ambitions.

How can organizations protect Redis instances from this style of abuse?

First, enable requirepass or use ACLs to enforce authentication on every Redis deployment. Second, bind Redis to internal interfaces only, or place it behind a firewall that restricts inbound traffic to trusted sources. Third, monitor for anomalous CONFIG SET and SLAVEOF commands in Redis logs; these are strong indicators of a replication‑based takeover.
Finally, regularly audit cron directories for unknown entries, and consider using file integrity monitoring to alert on changes to /etc/cron.d/.

What does the Monero wallet address tell us about the threat actor?

The same wallet appeared in a separate open directory in Moldova that hosted Meterpreter and XMRig deployers, dated back to February 2026. This linkage pushes the timeline of the actor’s activity at least five months earlier than the Hetzner leak, suggesting a sustained operation that recycles infrastructure and monetary accounts across campaigns.

What this means for you

Any organization that runs Redis without authentication is effectively exposing compute resources to a low‑effort, high‑return cryptomining botnet. By tightening access controls, limiting network exposure, and implementing real‑time monitoring for configuration changes, you can cut off the attack surface that these actors rely on.
In short, treat Redis like any other critical service: lock it down, watch it, and keep your software supply chain clean.

Frequently asked questions

How can I tell if my Redis server has been compromised by this botnet?

Check for unexpected cron files in <code>/etc/cron.d/</code>, unknown <code>CONFIG SET</code> or <code>SLAVEOF</code> commands in Redis logs, and the presence of the XMRig binary or its process. Network traffic to Monero mining pools is another strong indicator.

What steps should I take to secure an open Redis instance?

Enable authentication with a strong password or ACLs, bind the service to localhost or a private subnet, restrict inbound traffic with firewall rules, and disable the <code>CONFIG</code> and <code>SLAVEOF</code> commands for untrusted clients.

Is cryptomining the only payload used in Redis abuse campaigns?

No. While cryptomining is common because it yields quick profit, attackers have also delivered ransomware, backdoors, and data exfiltration tools through the same replication technique, as seen with the Meterpreter deployers in a related Moldova leak.

Can enabling authentication fully prevent this attack?

Authentication blocks the initial unauthenticated <code>PING</code> check, which stopped all SSH attempts in the observed campaign. However, attackers may still try credential‑stuffing or exploit other services, so defense‑in‑depth is essential.

Why does the operator’s leaked toolkit matter for defenders?

The toolkit provides a complete view of the attacker’s code, logs, and deployment steps, allowing defenders to create signatures, improve detection rules, and understand the operational patterns of financially motivated botnets.