A cryptomining operation just compromised over 3,500 Redis servers, turning them into engines for mining Monero under their control. These instances weren’t exposed due to a newly discovered flaw, but because many were left open on the internet without requiring a password. Attackers scanned nearly 13,000 Redis instances, zeroed in on misconfigured servers, and used Redis’s own features to stage the intrusion.
How the Attack Unfolded
Threat researchers from Hunters.io traced the campaign after spotting an unsecured directory full of logs and exploit files that detailed how the operation was both built and measured. The logs showed two large sweeps that together hit more than 3,500 unique Redis hosts. The versions affected ranged broadly—from 2.8.17 up through 7.2.0—suggesting it wasn’t a vulnerability in a specific release but a configuration oversight. Servers left without authentication were being hijacked.
The method depended heavily on Redis’s replication functionality. Once attackers confirmed a server didn’t require credentials, they changed where its data was written and pointed it at a malicious replica. That replica pushed content that created a scheduled task—a cron job in Linux—that, every five minutes, downloaded the XMRig miner, concealed it among temporary files, and connected to a Monero mining pool via port 443. This use of TLS-encrypted port traffic helps the miner blend in more than open mining ports usually do.
Risks & Indicators
Besides the drain on CPU power and inflated cloud bills, these misconfigurations carry serious risks for data integrity. Interference with Redis’s write paths can disrupt snapshot files and any setup relying on persistence. That makes this threat not just one of performance, but also of potential data loss and corruption.
Researchers have flagged several signs defenders should watch for: abnormal processor usage, unexpected HTTP connections between Redis servers and external hosts, unusual cron tasks, and modified SSH key files outside standard paths. Specific traceable indicators include IPs, domain names, and file paths tied to the compromised infrastructure, including files like /etc/cron.d/redis-miner, /var/spool/cron/root, and modified SSH authorized_keys entries.
Defensive Steps
Preventing this kind of attack starts with removing Redis from public internet access and limiting it to trusted internal networks. Enforcing authentication, renaming or disabling replication commands such as SLAVEOF/REPLICAOF, and keeping Redis in protected mode are essential. Simply updating to newer versions does not defend against this type of abuse.
Investigate configuration settings for unusual data directories or filenames, and scan cron job folders for unexpected entries. Also essential is reviewing paths for persistence mechanisms like SSH key injection or login-shell scripts. In the event of detection, isolate infected hosts, terminate malicious processes, eliminate all persistence hooks, rotate credentials, and audit data integrity before bringing systems back online.
Malicious use of otherwise legitimate software—like the XMRig miner—is becoming a growing trend. Detection strategies must shift focus from file names to behavior. This incident also underscores the wider danger of leaving core infrastructure services directly reachable from the internet. Encrypting mining traffic or using deceptive ports doesn’t hide the underlying misuses.
Those monitoring the threat landscape will want to track whether similar campaigns replicate this replication-based approach, especially given how long Redis versions spanning nearly all major releases have been vulnerable through misconfiguration. The real question now: are organizations proactive enough in closing these loopholes before this method becomes even more widespread?
