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):-

Type	Indicator	Description
IP address	188.245.99.156	Operator host used for rogue Redis replication, command-and-control, and payload staging
IP address and port	188.245.99.156:10000	Command-and-control callback endpoint
IP address and port range	188.245.99.156:16379-16385	Rogue Redis replication listener ports
URL pattern	http://188.245.99.156:10000/ping?h=<hostname>	Victim check-in request pattern
IP address and port	45.155.102.89:10128	Local mining pool proxy used on the operator host
Domain and port	pool.moneroocean.stream:443	Mining pool endpoint used by botnet-deployed XMRig
Domain and port	socket.ayakliborsa.net:8081	Live operator-controlled hostname resolving to 188.245.99.156
IP address	47.250.92.230	Frequently reused QA or test target, ownership unconfirmed
IP addresses	34.166.99.116, 20.198.10.42, 213.6.207.123, 173.212.244.25	Additional observed development and QA targets
IP address	23.235.223.49	Recurring WordPress exploitation target
IP address and port	194.48.248.105:8081	Earlier open directory linked by cryptocurrency wallet reuse
Hostname	WIN-F13ECU568VF	Windows host identifier observed in the RDP certificate
TLS fingerprint	420c7850e09b7c2b9e39e2a93e204e3c56bcf08a685ff1daa986e3c348da5d2a	Pinned mining-pool certificate fingerprint in the newest payload
URL	https://github.com/xmrig/xmrig/releases/download/v6.22.2/xmrig-6.22.2-linux-static-x64.tar.gz	XMRig download location referenced by the payload
File path	/etc/cron.d/redis-miner	Primary cron-based persistence path
File path	/etc/cron.hourly/redis-miner	Fallback cron persistence path
File paths	/etc/cron.d/redis-update, /var/spool/cron/root, /var/spool/cron/crontabs/root	Additional cron persistence locations
File paths	/root/.ssh/authorized_keys, /home/redis/.ssh/authorized_keys, /var/lib/redis/.ssh/authorized_keys	SSH key-injection targets
File path	/etc/apt/apt.conf.d/99sys-update	APT hook persistence path
File path	/etc/profile.d/sys-init.sh	Login-shell persistence path
File names	tmp.xmrig, tmp.xr	Hidden XMRig binary filenames
File names	c2persist.py, rogue.py, boot.py, redisminer.py, s.php	Recovered campaign tooling and payload-related files

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.