3,500+ Redis Servers Hijacked in Massive Cryptojacking Campaign

Rather than relying on a single newly discovered Redis vulnerability, the campaign reportedly focused on internet-accessible Redis deployments with weak or missing authentication and insecure configurations. Attackers scanned thousands of Redis systems, abused legitimate replication functionality, planted persistence mechanisms, and ultimately deployed XMRig, an open-source cryptocurrency miner commonly used to mine Monero.

Researchers observed the attackers scanning nearly 13,000 Redis hosts, demonstrating how quickly automated threat actors can identify poorly secured database infrastructure at internet scale.

The campaign highlights a fundamental security lesson: a fully patched database can still be compromised when it is unnecessarily exposed to the internet and insufficiently protected.

Key Takeaways

• 3,562 unique Redis servers were reportedly compromised.
• Attackers scanned approximately 12,966 Redis hosts during one campaign run.
• The campaign targeted Redis deployments across a broad range of versions.
• Missing or weak authentication was a major factor enabling compromise.
• Attackers abused Redis replication and configuration functionality to deliver malicious data.
• A malicious cron job was used to establish persistence.
• The final payload included XMRig, a cryptocurrency-mining application.
• Mining activity was associated with Monero.
• Attackers attempted to restore Redis configuration after establishing persistence.
• The campaign demonstrates the continuing risks of internet-exposed databases.

How the Attack Worked

The operation followed a multi-stage attack chain designed to turn exposed Redis servers into mining infrastructure.

1. Internet-Wide Redis Scanning

The attackers first searched the internet for accessible Redis services.

Researchers reportedly identified scanning activity targeting 12,966 Redis hosts. Of those, thousands were successfully compromised across multiple campaign runs. After accounting for overlapping victims, the total number of unique compromised servers was estimated at 3,562.

This demonstrates the effectiveness of automated scanning against infrastructure that has been unintentionally exposed to the public internet.

2. Identifying Unauthenticated Redis Instances

The attackers tested whether Redis servers would accept commands without requiring appropriate authentication.

When an exposed instance allowed unauthorized administrative interaction, the attackers could begin manipulating Redis configuration and persistence mechanisms.

Importantly, this means the campaign was not necessarily dependent on exploiting a newly disclosed CVE.

The underlying problem was often insecure deployment.

3. Redis Replication Weaponized

The attackers abused Redis's legitimate replication capabilities.

Replication is normally used to synchronize data between Redis instances in distributed environments. In this campaign, however, threat actors configured compromised servers to communicate with attacker-controlled Redis infrastructure.

The malicious replication process allowed the attackers to deliver specially crafted database data to the victim.

This transformed a legitimate Redis feature into part of the attack chain.

4. Malicious Files and Cron Persistence

The attackers reportedly manipulated Redis persistence-related settings to influence where database files were written.

This technique could ultimately be used to place a malicious cron configuration on the underlying Linux system.

A scheduled task then provided persistence and allowed the attackers to repeatedly download or execute the mining payload.

This is particularly significant from an incident-response perspective because simply restarting Redis or restoring its configuration would not necessarily remove the operating-system-level persistence.

5. XMRig Deployed for Cryptomining

The final objective was cryptocurrency mining.

The campaign reportedly deployed XMRig, a legitimate open-source mining application that is frequently abused by threat actors for unauthorized Monero mining.

Once active, the miner consumed the compromised server's CPU resources and connected to external mining infrastructure.

Although XMRig itself is legitimate software, its unauthorized deployment turns it into a cryptojacking payload.

Why Redis Is an Attractive Target

Redis is widely used as an in-memory database and caching platform across web applications, APIs, cloud environments and enterprise infrastructure.

However, Redis instances are generally not intended to be freely accessible from the public internet.

An exposed Redis service can provide attackers with significantly more control than a typical public-facing application endpoint, particularly when authentication and access controls have not been properly configured.

Previous campaigns have also demonstrated the attractiveness of Redis to cryptojacking operators. Security researchers have documented attacks involving exposed Redis instances, malicious cron jobs and cryptocurrency miners.

The latest campaign therefore represents another example of a long-running threat pattern rather than an isolated incident.

Broad Range of Redis Versions Targeted

One notable aspect of the campaign is the reported range of affected Redis versions.

Researchers observed compromised systems running versions ranging from Redis 2.8.17 through 7.2.0.

The broad version range reinforces the conclusion that the campaign was primarily focused on exposure and insecure configuration, rather than exploiting one specific newly disclosed vulnerability.

This distinction is important for security teams.

Simply maintaining an up-to-date Redis version does not protect an installation that is:

• Publicly reachable
• Unauthenticated
• Poorly segmented
• Running with excessive privileges
• Missing host-level monitoring

Attackers Attempted to Hide Their Activity

After completing the malicious replication process, the attackers reportedly restored Redis configuration and removed the replication relationship.

However, the persistence mechanism created on the underlying operating system could remain.

This creates an important forensic challenge.

An administrator may inspect Redis and find that the configuration appears normal while a malicious scheduled task continues executing in the background.

For this reason, a suspected Redis compromise should be treated as a potential host compromise, rather than simply a database configuration problem.

Potential Business Impact

Cryptojacking may not initially appear as serious as ransomware or data theft, but large-scale mining campaigns can produce significant consequences.

Increased Infrastructure Costs

Cloud servers compromised for mining can consume large amounts of CPU resources, resulting in unexpected cloud bills.

Performance Degradation

Applications sharing the same infrastructure may experience slower response times because system resources are being consumed by unauthorized mining processes.

Operational Disruption

Sustained CPU utilization can affect legitimate workloads and potentially contribute to system instability.

Security Risk

A compromised Redis server may represent an initial foothold that could be used for additional malicious activity beyond cryptocurrency mining.

Data and Availability Concerns

Changes to Redis persistence and configuration mechanisms can also introduce risks to legitimate database operations and availability.

Detection and Threat Hunting

Security teams should not rely solely on malware signatures when investigating this type of campaign.

Instead, defenders should look for a combination of Redis configuration changes, unusual replication behavior, operating-system persistence and abnormal resource consumption.

1. Investigate Redis Replication

Review Redis replication status and identify unexpected upstream servers.

_redis-cli INFO replication_

Unexpected replication relationships should be investigated immediately.

2. Search Cron Jobs

Because cron persistence was reportedly used, investigate system-wide scheduled tasks.

_sudo ls -la /etc/cron.d/
sudo crontab -l_

Security teams should look for recently created or unexplained scheduled tasks.

3. Look for Cryptocurrency Miners

Investigate processes consuming unusually high CPU resources.

_ps -eo pid,ppid,user,%cpu,%mem,etime,cmd --sort=-%cpu | head -20_

Search specifically for known mining processes where appropriate:

_ps aux | grep -i '[x]mrig'_

4. Review Outbound Network Connections

Investigate Redis servers making unexpected external connections, particularly connections to unfamiliar infrastructure over TCP/443.

Network telemetry from firewalls, EDR, cloud security platforms and SIEM systems can help identify unusual outbound activity.

5. Monitor Redis Configuration Changes

Unexpected modifications to Redis persistence, replication or filesystem-related settings should be treated as potential security events.

Security teams should correlate these changes with:

• New cron entries
• Unexpected downloads
• High CPU usage
• Unknown external connections
• New or modified binaries
• Unusual Redis commands

Indicators of Compromise

Researchers reported the following infrastructure associated with the campaign:

IP Address:
188.245.99.156

Reported endpoint:
188.245.99.156:10000

Observed request pattern:
/ping?h=<hostname>

Organizations should search these indicators across:

• SIEM
• EDR
• Firewall logs
• Proxy logs
• DNS telemetry
• NetFlow/network monitoring
• Linux audit logs

IOCs should be treated as campaign-specific detection clues, rather than permanent signatures. Threat actors can rapidly rotate infrastructure.

Recommended Mitigations

1. Never expose Redis directly to the public internet

Where possible, Redis should operate within private networks and only accept connections from trusted application systems.

2. Enable strong authentication

Review Redis authentication and ACL configuration and ensure unauthorized users cannot execute administrative commands.

3. Use network segmentation

Restrict Redis access using:

• Firewalls
• Cloud security groups
• Network ACLs
• Private subnets
• VPNs
• Application-level access controls

4. Review Redis configuration

Verify that Redis is bound only to the interfaces that actually require access.

5. Monitor replication

Unexpected changes to Redis replication state should generate security alerts.

6. Monitor CPU utilization

Unexpected sustained CPU consumption on database servers can be an early indication of cryptomining.

7. Hunt for persistence

Investigate cron jobs, systemd services, SSH keys, newly created users and suspicious binaries when a Redis server is suspected of compromise.

8. Keep Redis Updated

Although this campaign primarily highlights configuration weaknesses, organizations should still maintain supported Redis versions and apply security updates promptly.

9. Include Redis in Attack Surface Management

Organizations should continuously identify internet-facing Redis instances rather than relying on periodic manual reviews.

What Security Teams Should Learn From This Campaign

The most important lesson is that patching alone does not eliminate infrastructure risk.

The attackers reportedly compromised thousands of Redis systems without needing a single universal zero-day. Instead, they found systems that were already exposed and insufficiently protected.

The campaign also demonstrates how legitimate functionality can become an attack mechanism.

• Redis replication is legitimate.
• Cron is legitimate.
• XMRig is legitimate software.
• Encrypted connections over port 443 are legitimate.

The threat emerges when attackers combine these components for malicious purposes.

For SOC teams, this means detection strategies should focus on behavior and context, not only known malware signatures.

A Redis server unexpectedly becoming a replica, modifying persistence settings, creating a cron task and generating sustained CPU utilization should be treated as a potentially serious incident.

Bottom Line

The compromise of more than 3,500 Redis servers demonstrates how quickly attackers can turn poorly secured infrastructure into a distributed cryptocurrency-mining platform.

The campaign is another reminder that databases should never be treated as harmless internal services simply because they are not directly exposed through a web application.

Restrict network exposure, enforce authentication, monitor configuration changes, investigate unusual replication activity and continuously hunt for persistence.

For organizations running Redis in cloud or on-premises environments, these controls can prevent a relatively simple cryptojacking operation from becoming a broader infrastructure compromise.

Quick Reference

Item	Details
Target	Redis servers
Unique compromised systems	3,562
Hosts scanned	12,966 reported in one campaign run
Primary weakness	Internet exposure / insufficient authentication
Abused functionality	Redis replication and persistence
Persistence	Cron
Mining software	XMRig
Cryptocurrency	Monero
Threat type	Cryptojacking
Primary impact	Unauthorized resource consumption and potential operational disruption
Threat level	High