A cryptocurrency mining operation has silently taken over 3,562 Redis database servers worldwide, converting their processing power into Monero for the attackers behind it. The campaign came to light after researchers at Hunters.io stumbled onto an exposed directory that the operators had left open on the internet, revealing 147 files that included exploit scripts, campaign logs, and operational notes. Because the attack exploited a misconfiguration rather than a software bug, it matters right now: any organization running Redis without authentication is a potential target regardless of which version it uses.
The scale of the compromise becomes clearer once the campaign logs are broken down. Hunters.io found records of two separate scanning and infection runs, one hitting 3,388 hosts and a second reaching 2,862, with significant overlap between the two lists once duplicates were removed, leaving 3,562 distinct victims out of 12,966 servers the attackers had probed. Notably, the affected instances spanned Redis versions from as far back as 2.8.17 up through the more recent 7.2.0, a range wide enough to confirm that the common thread was an unauthenticated, internet-facing configuration rather than a single flawed release.
What happens next largely depends on how quickly exposed operators lock down their instances, since the underlying weakness, an internet-reachable Redis server with no password, remains just as usable to copycat campaigns as it was to this one. The technique at the center of the attack relies on a legitimate Redis feature rather than a zero-day, which means patching alone will not close the gap. Administrators are being urged to treat exposure itself, not just outdated software, as the vulnerability that needs fixing.
How the Cryptocurrency Mining Campaign Worked
The attackers built their intrusion around Redis’s master-replica replication system, a feature meant to let one server mirror the data of another for backup or scaling purposes. According to Hunters.io, once the operators confirmed a target server had no password set, they reconfigured where that server wrote its data and pointed it to replicate from a server they controlled.
Turning Replication Into a Delivery Mechanism
That rogue replication process delivered a cron task, the small Linux scheduling entry that fires commands on a set interval. Every five minutes, the planted task pulled down a copy of XMRig, the open-source Monero mining software, and renamed the binary so it would blend in among ordinary temporary files. The miner then connected to a mining pool over port 443, the port normally reserved for encrypted web traffic, which lets its network activity hide more easily inside typical outbound connections than mining traffic sent over a dedicated port would.
This is not the first time exposed Redis instances have been used this way. The pattern mirrors an earlier wave of Redis cryptojacking activity and also resembles replication abuse documented in P2PInfect campaigns, both of which relied on the same basic weakness: a database server sitting open to the internet with nothing guarding it.
Fallback Methods That Did Not Pan Out
Hunters.io’s review of the leaked toolkit showed the operators experimenting with more than one path to persistence. Beyond the cron-based approach that ultimately succeeded at scale, the logs showed attempts to inject SSH keys into authorized-key files and to abuse Redis’s own scripting capabilities. Neither of those alternate methods produced confirmed compromises across the victim set, suggesting the replication-and-cron combination was the operation’s only reliable technique.
Why This Matters Beyond Stolen Processing Power
The consequences extend past a higher cloud bill or a sluggish application. Because the attackers altered how Redis wrote its data during the intrusion, the same changes that enabled the mining payload can interfere with the server’s normal snapshot files. For organizations that depend on Redis persistence to avoid data loss, that means the mining campaign carries a secondary risk: corrupted or disrupted data alongside the performance hit.
Hardening Steps and What Defenders Should Check
Security teams reviewing their own environments have a clear starting point, according to the guidance drawn from Hunters.io’s findings and standard Redis hardening practice.
| Priority | Action | Why It Matters |
|---|---|---|
| 1 | Remove Redis from direct internet exposure | Eliminates the entry point the entire campaign depended on |
| 2 | Require authentication on every instance | Blocks the initial unauthenticated access step |
| 3 | Restrict or rename SLAVEOF/REPLICAOF where replication is unneeded | Closes the specific feature abused for payload delivery |
| 4 | Keep protected mode enabled | Adds a default safeguard against remote misconfiguration |
| 5 | Apply version patches | Addresses other risks, though it will not fix this exposure alone |
Signs of an Existing Compromise
Administrators should inspect cron directories and user crontabs for unfamiliar references to download utilities, archive extraction, or mining tools. Redis configuration files deserve a second look too, particularly unusual data directories or filenames that do not match normal operational settings. Hunters.io’s data also points to unauthorized APT hooks and login-shell script modifications as artifacts worth hunting for, along with SSH key files placed outside the standard root account paths.
On the network side, security teams should watch for unexpected HTTP connections to unfamiliar infrastructure, encrypted traffic patterns consistent with mining pools, and sustained high processor usage coming from processes launched out of temporary directories.
Recommended Response If a Server Is Compromised
A full response, per the hardening guidance associated with this campaign, involves isolating the affected server, terminating malicious processes, removing every persistence mechanism found, rotating Redis and related credentials, and reviewing data integrity before the host goes back into production.
Indicators of Compromise
Hunters.io published the following indicators tied to the campaign’s infrastructure and tooling. IP addresses and domains below are defanged and should only be re-fanged inside controlled threat intelligence tools such as MISP, VirusTotal, or a SIEM.
| 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 | hxxp://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 | 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 |
The broader lesson from this cryptocurrency mining campaign is straightforward: Redis was never designed to be exposed to the open internet without authentication, and attackers are actively scanning for instances that violate that basic rule. Closing off direct exposure and enforcing authentication removes the entire attack path this campaign relied on, regardless of which Redis version an organization happens to be running.
Disclaimer: This content was partially produced with the help of AI tools
