Hackers Turn More Than 3,500 Redis Servers Into Cryptocurrency Miners

A large cryptomining operation has compromised 3,562 Redis servers and turned their processing power into a source of Monero revenue.

The campaign did not rely on a newly discovered software flaw. Instead, it targeted internet-facing Redis instances that accepted commands without authentication.

The operators scanned 12,966 potential targets, then used Redis replication features to plant a scheduled task that downloaded and ran a miner.

The result can be slower applications, unusually high processor use, higher cloud bills, and a risk that normal Redis data may be disrupted.

Researchers at Hunters.io identified the campaign after finding an exposed directory containing 147 files, including exploit code and campaign logs.

Hunters.io said in a report shared with Cyber Security News (CSN) that the records provide an unusually clear view of how the operation was built, tested, and measured.

The logs show two large runs compromised 3,388 and 2,862 hosts respectively, with overlap between them. That leaves 3,562 distinct victims.

The affected systems covered Redis releases from 2.8.17 to 7.2.0, showing that configuration, rather than one vulnerable version, was the central problem.

Redis Servers Turned Into Cryptocurrency Miners

The main attack abused Redis master-replica replication. After confirming that a server did not require a password, the attackers changed where Redis wrote its data and directed it to copy content from a rogue server.

The received data created a cron task, a small Linux scheduler entry that repeatedly runs commands. Every five minutes, the task fetched XMRig, renamed it to hide among temporary files, and connected it to a mining pool over encrypted port 443.

This approach can make the traffic look less unusual than mining on a dedicated port. It echoes the pattern covered in an earlier Redis cryptojacking campaign, where exposed, poorly protected instances were also the opening.

The attackers used several fallback locations for the scheduled task. They also tested ways to add SSH keys and to use Redis scripting, but those tracks produced no confirmed compromises at scale.

The successful replication method matters because it uses a legitimate feature that remains available across many releases.

The impact goes beyond stolen computing resources. During the attack, the altered Redis write settings can interfere with normal snapshot files.

Organizations relying on Redis persistence could therefore face data-loss risk alongside the performance hit. Similar replication abuse was recently seen in P2PInfect exposed Redis attacks, underlining why public Redis exposure is dangerous.

Hardening and Hunt Priorities

Defenders should first remove Redis from direct internet access, restrict it to trusted networks, and require authentication.

Where replication is not needed, administrators should restrict or rename the SLAVEOF or REPLICAOF command and keep protected mode enabled. Upgrading alone will not solve this particular exposure, though patches still remain important for other risks.

Teams should inspect cron directories and user crontabs for unexpected references to download tools, archive extraction, or mining software.

They should also review Redis settings for unusual data directories or filenames, then look for unauthorized APT hooks and login-shell scripts.

The broader lesson also appears in the RedisRaider mining activity report, which documented attackers turning weak Redis access controls into code execution.

Network monitoring can help identify systems that were already hit. Security teams should investigate unexpected HTTP connections to the campaign infrastructure, encrypted mining traffic, and sustained processor consumption by processes running from temporary directories.

The miner is legitimate software being misused, a trend also visible in the Linux XMRig mining campaign, so detection should focus on behavior rather than a filename alone.

A complete response should isolate the server, stop malicious processes, remove every persistence mechanism, rotate Redis and related credentials, and review data integrity before returning the host to service.

Administrators should also check service-account SSH key locations, because the recovered toolkit attempted to place keys outside the usual root account paths for signs of follow-on access.

Indicators of compromise (IoCs):-

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.

Keep your SOC up to date on active malware & phishing within 24h of their emergence. Try ANYRUN to prevent incidents with early detection.