Hunters.io finds 3,562 misconfigured Redis servers hijacked for Monero mining

Hackers compromised more than 3,500 internet-facing Redis servers left without authentication, using the databases’ own replication feature to install cryptocurrency-mining malware, according to research published by Hunters.io.

The campaign did not depend on a newly discovered software vulnerability. Instead, the attackers focused on Redis servers that were publicly accessible and configured to accept commands without authentication.

Hunters.io said the operators scanned 12,966 potential targets before using Redis replication functionality to compromise vulnerable systems and establish persistence. Two major attack runs recorded 3,388 and 2,862 compromised hosts respectively, with overlap between the campaigns leaving 3,562 distinct victims.

How Redis servers became cryptocurrency miners

The attackers exploited Redis master-replica replication to take control of exposed systems. After determining that a target did not require a password, they altered Redis’s data-writing configuration and instructed the server to replicate content from an attacker-controlled system.

That replicated content was used to create a cron job, a Linux scheduling mechanism that executes commands at specified intervals. The malicious task ran every five minutes, downloading the XMRig cryptocurrency miner and disguising the binary among temporary files.

The miner then connected to a Monero mining pool through encrypted port 443. Using a commonly used web-encryption port could make the traffic less conspicuous than cryptocurrency-mining communications operating on a dedicated or unusual port.

The campaign’s successful technique is significant because it relied on a legitimate Redis feature rather than exploiting a single vulnerable software release. The affected installations reportedly ranged from Redis 2.8.17 through 7.2.0, reinforcing the role of security configuration in the attacks.

Hunters.io’s findings also indicate that the operators experimented with several alternative methods. These included attempts to add SSH keys and use Redis scripting, although the researchers found no evidence that those approaches resulted in compromises at comparable scale.

Redis servers face performance and data risks

The immediate consequence of the campaign is the unauthorized use of computing resources for cryptocurrency mining. Organizations with compromised Redis servers could experience sustained processor consumption, slower applications and increased infrastructure or cloud bills.

But the consequences may extend beyond resource theft.

During the attack, the operators changed Redis write settings, potentially interfering with normal snapshot files. For organizations that depend on Redis persistence mechanisms, that creates a risk of data disruption or loss in addition to the performance impact.

The campaign also resembles previous attacks against exposed Redis infrastructure. Hunters.io linked the activity to the broader pattern of attackers abusing poorly protected Redis deployments, including activity associated with P2PInfect and RedisRaider.

The discovery therefore highlights a recurring security problem: organizations can remain exposed even when their software is not affected by a newly disclosed vulnerability if administrative interfaces and services are unnecessarily reachable from the public internet.

How defenders can secure Redis servers

Security teams should begin by removing Redis from direct internet exposure wherever public access is not required. Redis instances should instead be restricted to trusted networks, while authentication and appropriate access controls should be enforced.

Where replication is unnecessary, administrators should also consider restricting or renaming commands such as SLAVEOF or REPLICAOF. Protected mode should remain enabled where appropriate.

Hunters.io’s findings also show why simply upgrading software may not resolve this particular threat. The campaign affected multiple generations of Redis, meaning that configuration and exposure were central to the attackers’ success. Software updates nevertheless remain important for addressing other security vulnerabilities.

Incident responders should examine cron directories and user crontabs for suspicious entries associated with download utilities, archive extraction or cryptocurrency-mining software. They should also inspect Redis configurations for unusual data directories and filenames.

Security teams should search for unauthorized persistence mechanisms, including APT configuration hooks, login-shell scripts and unexpected SSH keys. Particular attention should be paid to service-account locations because the recovered toolkit attempted to place SSH keys outside the conventional root account paths.

Network monitoring can provide additional clues. Unexpected HTTP connections to attacker infrastructure, encrypted connections associated with mining pools and sustained CPU consumption from processes running in temporary directories can all indicate compromise.

The XMRig miner itself is legitimate software that has been repurposed for malicious activity. As a result, defenders should focus on behavior, execution location, persistence and network activity rather than relying solely on the filename of the mining program.

What organizations should do after compromise

For organizations that discover an affected Redis server, the response should begin with isolation. The compromised host should be separated from the network while malicious processes and persistence mechanisms are identified and removed.

Redis credentials and related authentication material should then be rotated. Investigators should review the integrity of stored data and persistence files before restoring the system to normal service.

Security teams should also examine SSH key locations associated with Redis service accounts and investigate signs of follow-on access.

Hunters.io’s investigation provides defenders with several indicators that can support threat hunting, including the operator infrastructure at 188.245.99.156, the command-and-control endpoint on port 10000, rogue replication listeners on ports 16379-16385, and the mining endpoint at pool.moneroocean.stream:443.

Other indicators include the persistence paths /etc/cron.d/redis-miner and /etc/cron.hourly/redis-miner, as well as hidden miner filenames such as tmp.xmrig and tmp.xr.

The recovered toolkit also included files named c2persist.py, rogue.py, boot.py, redisminer.py and s.php.

The broader lesson from the campaign is straightforward: internet exposure and weak access controls can turn legitimate infrastructure into an attack platform. For Redis administrators, reducing public exposure, enforcing authentication, restricting dangerous functionality and actively monitoring system behavior remain critical defenses against cryptojacking and related forms of server abuse.