Threat actors compromised 3,562 internet-exposed Redis servers in a large cryptomining campaign that abused Redis replication features to install XMRig.
The attackers targeted unauthenticated instances and used rogue replication servers to write malicious cron jobs onto vulnerable Linux systems.
The campaign was uncovered after researchers found an exposed attacker-controlled directory containing 147 files, including Python exploit scripts, campaign logs, portable Python runtimes, Windows registry hives, and infrastructure data.
The recovered logs showed that the operators scanned 12,966 Redis hosts and successfully compromised thousands of them across two separate campaign runs.
The affected systems ran Redis versions from 2.8.17 through 7.2.0. This wide version range indicates that the attacks did not rely on a newly disclosed software vulnerability.
Instead, the main weakness was unsafe Redis deployment, especially instances exposed to the internet without authentication enabled.
Redis Servers Hijacked
The attackers used Redis’s legitimate master-replica synchronization process as an attack mechanism. Their tools first checked whether a target accepted Redis commands without authentication.
They then changed the Redis working directory and database filename through CONFIG SET commands.
Next, the attackers instructed the victim server to become a replica of a rogue Redis server controlled by the operators.
The victim connected to the rogue server, completed the Redis replication handshake, and downloaded a crafted RDB database file. That file was designed to create a cron job under paths such as /etc/cron.d/redis-miner.
The cron entry executed every five minutes and downloaded XMRig, an open-source Monero miner, from the official XMRig GitHub release location. The malware was renamed to a hidden file, such as /tmp/.xmrig, before execution.
The XMRig command used encrypted TLS traffic and connected to pool.moneroocean.stream over port 443. Using port 443 can make mining traffic appear more similar to normal encrypted web traffic.
The payload also used the victim hostname as a mining worker identifier, allowing the operators to track individual infected systems.
After writing the cron file, the scripts issued SLAVEOF NO ONE and restored the original Redis configuration. However, this cleanup did not remove the malicious cron job.
![Raw query result, every hit is 188.245[.]99.156:8081, confirming the hostname has never been resolved anywhere else (Source: hunt.io)](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhZjhoI_y-tMyew7gFbKSznQVyCBesjMxluG3NglA7JAX4WEuSP990G2tV-9GyLInLP9e5xkK64J05brsJMPxy66Ci8Dk4GjBdtgsqMiP99IeQwl6_vlkfyY2AG1t0uA4o_BeaVrX3Fi85dJRm1k5btGz1eoGdi3amEeu0PIRpFauMNvEUPHv6dyCoE1kK8/s1999/Redis+Cryptomining+Botnet+Compromised+-+figure+22.webp)
Researchers noted that modifying Redis persistence settings could also create a risk of data loss if a target depended on RDB snapshots during the attack.
Campaign data showed that authentication was the main defensive control. In the first run, attackers compromised 3,388 of 12,966 targets, or 26.1%.
A second run compromised 2,862 systems. After removing duplicate victims, researchers calculated 3,562 unique compromised Redis servers, hunt.io said.
Indicators of Compromise
| Indicator | Type | Role / Detection Context |
|---|---|---|
188.245.99.156 | IP address | Primary attacker infrastructure hosting the rogue Redis replication service, payload staging, and C2 components |
188.245.99.156:10000 | IP:Port | C2 callback endpoint. Infected hosts issued HTTP requests resembling /ping?h=<h |
Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.
Detect 58% more threats with fresh intelligence from 16K+ organizations. Integrate TI Feeds in you SOC
