3,562 Redis Servers Hacked for Crypto Mining: Is Your Server Next?

3,562 Redis Servers Hijacked for Crypto Mining: Inside the Rogue Replication Attack Nobody Patched Their Way Out Of

Quick Answer: Attackers compromised 3,562 internet-exposed Redis servers using unauthenticated replication (SLAVEOF/REPLICAOF) to plant cron jobs that deployed XMRig miners. No exploit was needed — just missing authentication.

Last verified: September 16, 2026

Picture this: your Redis instance has been humming along fine for months — caching sessions, backing a job queue, doing exactly what it's supposed to do. No alerts. No crashes. Then one afternoon your cloud bill spikes, your app response times crawl, and when you finally SSH in, there's a cron job quietly re-downloading a binary called tmp.xmrig every five minutes. Nobody broke in through a zero-day. They just asked Redis nicely, and Redis said yes — because nobody ever told it to say no.

That's not a hypothetical. It's what happened to 3,562 real-world Redis servers in a cryptomining campaign uncovered by threat intelligence firm Hunt.io, and reported by Cyber Security News. The story is a useful case study for any SOC analyst, DevOps engineer, or cloud security team — because the attack technique here doesn't depend on a CVE at all. It depends on a default that's been sitting quietly in production for over a decade.

Table of Contents

• What Actually Happened
• How the Rogue Replication Attack Works
• Why This Isn't "Just a Cryptominer" Problem
• Indicators of Compromise
• Detection Commands for SOC Teams
• Prevention and Hardening Checklist
• Expert Tips From the Field
• FAQ
• Final Takeaway

What Actually Happened

According to Hunt.io's research, the operator behind this campaign made a rookie mistake that ended up exposing the entire operation: they left their own working toolkit sitting in an open web directory. Researchers pulled 147 files from it — Python exploit source, JSON campaign logs, and even Windows registry hive exports — giving analysts an unusually complete view of how the botnet was built and run, rather than the usual scraps of a payload.

The operator's own logs showed two scanning runs against a shared list of 12,966 Redis hosts, resulting in 3,562 distinct compromised servers once overlap was accounted for. The affected instances ran Redis versions ranging from 2.8.17 (2015) all the way to 7.2.0 (2023) — an eight-year spread that confirms this wasn't about an unpatched vulnerability. It was about servers left open on the internet without a password.

The toolkit also tried three other attack paths — SSH key injection, Redis scripting abuse, and even some WordPress/MongoDB probing — but none of those produced confirmed compromises at scale. Only rogue replication worked, and it worked well.

How the Rogue Replication Attack Works

This is the part every backend engineer should actually understand, because it doesn't require exploiting a bug — it abuses a completely legitimate Redis feature: master-replica replication.

Here's the attack chain in plain terms:

• Step 1 — Find an open door. The attackers scanned for Redis instances reachable on the internet that didn't require a password (no requirepass set, protected mode disabled).
• Step 2 — Redirect the write path. Using the standard CONFIG SET command, they changed the server's working directory (dir) and database filename (dbfilename) — the same commands a legitimate admin would use, just aimed somewhere malicious.
• Step 3 — Force a rogue sync. They issued SLAVEOF (or its newer alias REPLICAOF) pointing the victim at an attacker-controlled "master" server listening on ports 16379–16385. The victim, trusting the replication protocol, pulled down a crafted RDB (Redis database) file.
• Step 4 — Persistence via cron. That crafted RDB file was engineered so that when Redis wrote it to disk, it landed as a valid cron entry — commonly at /etc/cron.d/redis-miner — that fired every five minutes.
• Step 5 — Deploy the miner. The cron job fetched XMRig, a legitimate open-source Monero mining tool, renamed the binary to blend in with temp files, and pointed it at a mining pool over port 443 — using TLS so the traffic looks like normal encrypted web browsing rather than obvious mining activity.

Nothing in that chain requires memory corruption, an auth bypass bug, or a zero-day. It's Redis doing exactly what it was configured — or rather, not configured — to do.

Why This Isn't "Just a Cryptominer" Problem

It's tempting to write this off as a nuisance — higher CPU bills, some slower dashboards, nothing "serious." That take misses two things security teams should care about.

First, data integrity risk. The attack works by changing where Redis writes its persistence files. If your application actually depends on Redis's RDB snapshotting for durability, that redirection can corrupt or overwrite legitimate backup data — turning a mining nuisance into a data-loss incident.

Second, this is a foothold, not just a miner. Any attacker who can write arbitrary files via replication can, in principle, write more than a cron job — SSH keys, web shells, or a second-stage payload. The fact that this particular campaign stuck to cryptomining doesn't mean the next operator using the same technique will.

For enterprises running Redis behind cloud load balancers or in Kubernetes clusters, this campaign is a reminder that unauthenticated internal services exposed at the edge are exactly the kind of gap that enterprise vulnerability management programs and continuous exposure scanning are built to catch — this is squarely the kind of finding an attack surface management tool or a managed SOC-as-a-service provider should be flagging before an attacker's scanner finds it first.

Indicators of Compromise

Per Hunt.io's report, the following indicators are associated with this specific campaign. Treat any hits as high-priority for investigation — and remember these are defanged for safe reference, not for direct use.

Type	Indicator	Description
C2 / staging host	188.245.99[.]156	Operator server used for replication, C2, and payload staging
Rogue replication ports	16379–16385	Fake Redis master listener range
Mining pool	pool.moneroocean[.]stream:443	XMRig connects here over TLS
Persistence path	/etc/cron.d/redis-miner	Primary cron-based persistence
Fallback paths	/etc/cron.hourly/redis-miner, /var/spool/cron/root	Secondary persistence locations
Hidden binary names	tmp.xmrig, tmp.xr	XMRig disguised as temp files

For the complete IOC set, including additional QA/test IPs and SSH key-injection paths, refer to the original Hunt.io and Cyber Security News reporting.

Detection Commands for SOC Teams

These are read-only diagnostic checks — safe to run in production, and useful whether or not you suspect compromise yet.

Check if authentication is enforced on your Redis instance:

redis-cli -h  CONFIG GET requirepass

An empty result means no password is set. This is the single most important check to run today.

Check if protected mode is enabled:

redis-cli -h  CONFIG GET protected-mode

Should return yes. If it returns no on an internet-facing host, treat it as a critical finding.

Inspect cron for suspicious entries matching this campaign's pattern:

grep -r "xmrig\|moneroocean\|redis-miner" /etc/cron.d/ /etc/cron.hourly/ /var/spool/cron/ 2>/dev/null

This searches known persistence locations for the specific filenames and pool domain tied to this campaign. A hit here warrants immediate isolation of the host.

Check for unexpected outbound connections to mining infrastructure:

ss -tnp | grep ":443" | awk '{print $5}' | sort -u

Cross-reference the resulting IPs/domains against known mining pool ranges and your threat intel feed. Sustained, high-frequency outbound 443 traffic from a Redis host — not a web server — is a red flag.

Review current replication status:

redis-cli -h  INFO replication

Confirm your server isn't unexpectedly configured as a replica of an unfamiliar host. If master_host shows an address you don't recognize, that instance has likely already been compromised.

Prevention and Hardening Checklist

• Never expose Redis directly to the internet. Bind it to localhost or a private VPC/subnet, and gate access through a firewall or security group.
• Always set requirepass (or use Redis 6+ ACLs for granular, per-user authentication) — even on internal networks.
• Keep protected mode enabled unless you have a specific, documented reason to disable it.
• Rename or disable SLAVEOF/REPLICAOF via rename-command in redis.conf if replication isn't part of your architecture.
• Restrict CONFIG command access for application-level users; only administrative accounts should be able to change dir or dbfilename.
• Monitor for baseline CPU anomalies. A cache server pegged at high, sustained CPU is unusual behavior worth alerting on regardless of cause.
• Audit cron directories on a schedule, not just during incident response — cron persistence is cheap for attackers and easy for defenders to check.

None of these steps guarantee immunity — no control does — but together they close the exact gap this campaign relied on.

Expert Tips From the Field

A few practical notes worth passing on to your team:

• If your organization uses Redis Cloud or Redis Enterprise, note that Hunt.io's findings apply to self-managed, internet-exposed open-source Redis instances — not to Redis's managed cloud offerings, which enforce authentication by default.
• Don't assume "it's just a cache, there's nothing sensitive in it" is a reason to skip authentication. This campaign shows the risk isn't data theft — it's remote code execution via a feature, not a flaw.
• If you're running Redis inside containers or Kubernetes, double-check that your network policies actually restrict pod-to-pod and external access — a misconfigured NodePort or public LoadBalancer can re-expose an otherwise internal Redis instance without anyone noticing.

Related Cybersecurity Topics You Should Explore

• CVE-2026-26084 Explained: Patch FortiSandbox Now
  
• Fortinet Patches Silent MITM Flaw in FortiOS and FortiProxy ZTNA
  
• Linux cut Command Explained: Extract Any Field, Column, or Character in Seconds
  
• FortiGate CVE-2025-25249 Exploited to Deploy PivotC2 RAT — Patch Now
  
• Critical Dell SCG Bug (CVSS 9.8) Grants Root Access — Patch Now
  
• WeWorm: Zero-Click WeChat Worm Hijacks 1.4B Accounts via Call
  
• US Offers $10 Million for Iranian Hacker Behind Critical Infrastructure Attacks
  
• Panzer Ransomware Targets Italian Manufacturers With ESXi-Ready Malware

Frequently Asked Questions

Is this a new Redis vulnerability or CVE?
No. Researchers confirmed this campaign exploited missing authentication across a wide range of Redis versions (2.8.17–7.2.0), not a specific software flaw.

How do I know if my Redis server has already been compromised?
Check INFO replication for an unrecognized master host, inspect cron directories for unfamiliar entries, and look for unexpected outbound connections on port 443 from a Redis process.

Does upgrading Redis fix this issue?
Not by itself. Since the root cause is configuration — missing authentication and exposed replication — upgrading alone won't close the gap. Authentication and network restriction are required regardless of version.

What should I do if I find evidence of compromise?
Isolate the host, terminate the malicious process, remove all persistence mechanisms (cron entries, injected SSH keys), rotate Redis and related credentials, and review data integrity before returning it to service.

Is XMRig itself malware?
No — XMRig is legitimate, open-source Monero mining software. It becomes malicious only through unauthorized deployment on compromised systems, which is why detection should focus on behavior (unexpected process, unexpected persistence, unexpected traffic) rather than the filename alone.

Can this technique be used for more than cryptomining?
In principle, yes. Any technique that lets an attacker write arbitrary files to disk via Redis replication could theoretically be adapted to drop other payloads. This campaign's observed impact was limited to mining, per available reporting.

Final Takeaway

The uncomfortable truth in this story isn't a clever new exploit — it's that 3,562 organizations left a database open to the internet without a password, and that was enough. If there's one action item to pull from this today, it's simple: go check your own Redis instances right now. Run the CONFIG GET requirepass command above. If it comes back empty, you have work to do before the next scan finds you first.

Have you run into rogue Redis replication or similar misconfiguration-driven attacks in your environment? Share your detection approach in the comments, and subscribe for more real-world SOC breakdowns like this one.

Analysis based on SOC monitoring practices and public threat intelligence review (Hunt.io, Cyber Security News).