Critical Redis Vulnerability Exploited in Widespread Cryptomining Attacks

Key Takeaways

• Over 3,500 Redis servers have been compromised in a large-scale cryptomining campaign.
• The attacks exploit misconfigured, internet-facing Redis instances that lack authentication, not a new software vulnerability.
• Threat actors leverage Redis replication features to install Monero (XMRig) miners via scheduled tasks.
• Impacts include degraded application performance, increased cloud costs, and potential data loss due to altered Redis persistence settings.
• Immediate action is required to secure Redis deployments, including restricting network access, enforcing authentication, and monitoring for indicators of compromise.

Widespread Cryptomining Campaign Targets Misconfigured Redis Servers

A significant cryptomining operation has hijacked 3,562 Redis servers, converting their computational resources into a revenue stream for Monero cryptocurrency. This campaign is noteworthy not for exploiting a zero-day vulnerability, but rather for targeting Redis instances directly exposed to the internet and configured without proper authentication mechanisms.

The attackers initiated their operation by scanning 12,966 potential targets. Once an unauthenticated Redis instance was identified, they exploited Redis’s native replication capabilities to force the server to replicate data from a malicious source. This process allowed them to plant a scheduled task, which subsequently downloaded and executed a cryptocurrency miner.

The repercussions for affected organizations are substantial, including noticeable application slowdowns, unusually high CPU utilization, elevated cloud infrastructure expenses, and the risk of data corruption or loss due to interference with normal Redis data operations.

Unveiling the Attack Infrastructure

Security researchers at Hunters.io said in a report that they uncovered the campaign after discovering an exposed directory containing 147 files. These files offered an unprecedented look into the operation, including exploit code and detailed logs of the campaign’s development, testing, and execution phases.

Analysis of these logs revealed two major waves of compromise, affecting 3,388 and 2,862 hosts respectively. After accounting for overlaps, a total of 3,562 unique Redis servers were confirmed as victims. The compromised systems spanned a wide range of Redis versions, from 2.8.17 to 7.2.0, underscoring that the core issue was insecure configuration rather than a specific software flaw.

Redis Servers Turned Into Cryptocurrency Miners

The primary attack vector exploited Redis’s master-replica replication functionality. After verifying that a target server lacked password protection, the attackers manipulated Redis’s data writing location. They then instructed the Redis instance to replicate data from a rogue server under their control.

The replicated data introduced a cron task, a standard Linux scheduler entry designed to repeatedly execute commands. Every five minutes, this task retrieved the XMRig mining software, disguised it by renaming it to blend in with temporary files, and established an encrypted connection to a Monero mining pool over port 443. This method of using a common encrypted port helps the malicious traffic evade detection by appearing less suspicious than mining operations on dedicated ports. This strategy mirrors previous Redis cryptojacking incidents that also leveraged exposed, inadequately secured instances.

While the attackers experimented with other methods, such as adding SSH keys and utilizing Redis scripting, these alternative approaches did not yield widespread compromises. The success of the replication method lies in its reliance on a legitimate Redis feature, ensuring its effectiveness across numerous Redis versions.

Beyond the immediate theft of computing resources, the attack’s manipulation of Redis write settings can disrupt regular snapshot files. Organizations dependent on Redis persistence mechanisms face a dual threat: performance degradation and a significant risk of data loss. This abuse of replication highlights the inherent dangers of exposing Redis instances to the public internet without robust security measures, a lesson also reinforced by recent P2PInfect attacks targeting exposed Redis servers.

What You Should Do

Defenders must prioritize hardening their Redis deployments and actively hunting for signs of compromise:

• Restrict Network Access: Immediately remove Redis servers from direct internet exposure. Limit access to only trusted networks and specific, authorized IP addresses.
• Enforce Authentication: Implement strong authentication for all Redis instances. Never operate Redis without a password or access control lists (ACLs).
• Disable or Rename Replication Commands: If Redis replication is not explicitly required, restrict or rename the SLAVEOF or REPLICAOF commands to prevent their malicious misuse.
• Enable Protected Mode: Ensure Redis’s protected mode is enabled. This setting prevents remote clients from connecting to Redis if it’s running without a password and is bound to all interfaces.
• Inspect Cron Jobs: Regularly check cron directories (e.g., /etc/cron.d/, /etc/cron.hourly/) and user crontabs (/var/spool/cron/root, /var/spool/cron/crontabs/root) for any unexpected or suspicious scheduled tasks related to downloading tools, archive extraction, or mining software.
• Review Redis Configuration: Examine Redis configuration files for unusual data directories or filenames that might indicate a compromise.
• Check for Persistence Mechanisms: Look for unauthorized APT hooks (e.g., /etc/apt/apt.conf.d/99sys-update) and login-shell scripts (e.g., /etc/profile.d/sys-init.sh) that attackers might use for persistent access.
• Monitor Network Traffic: Implement network monitoring to detect unexpected HTTP connections to known command-and-control infrastructure, encrypted mining traffic (especially to common ports like 443 from unusual processes), and sustained high CPU usage by processes originating from temporary directories.
• Behavioral Detection: Since the XMRig miner is legitimate software, focus detection efforts on anomalous behavior rather than solely relying on file names. Look for processes running from unusual locations or exhibiting unexpected resource consumption.
• Incident Response: In the event of a compromise, immediately isolate the affected server, terminate all malicious processes, meticulously remove every persistence mechanism, rotate all Redis and related credentials, and thoroughly review data integrity before returning the host to service.
• SSH Key Audit: Inspect non-standard SSH key locations (e.g., /home/redis/.ssh/authorized_keys, /var/lib/redis/.ssh/authorized_keys) for signs of injected SSH keys, as the attackers attempted to establish 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.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.