Massive Redis Cryptojacking Campaign Hijacks Thousands of Linux Servers
RedisRaider cryptojacking campaign compromises thousands of exposed, unauthenticated Linux Redis servers using cron persistence to deploy XMRig Monero miners.
Hunt.io researchers track a large-scale cryptojacking operation named RedisRaider that scans IPv4 ranges for Redis services exposed on TCP port 6379 and targets instances accepting unauthenticated connections. From a master list of 12,966 candidate hosts, 2,342 were confirmed to accept commands without authentication. Attackers abuse Redis commands (CONFIG SET dir/dbfilename, SET, BGSAVE) to write malicious cron entries into /etc/cron.d or /var/spool/cron, launching XMRig-based Monero miners, with branches including SSH authorized-key injection, Lua probing, and WordPress spraying. The article also references CVE-2026-81934, a Redis TLS use-after-free allowing unauthenticated command execution, fixed in releases including 8.2.9, 8.4.6, 8.6.6, 8.8.2, and 8.10.1.
- Campaign relies on misconfiguration and native Redis commands, not a software exploit
- CONFIG SET and BGSAVE abused to plant cron files that persist across Redis restarts
- 2,342 of 12,966 scanned hosts accepted commands without authentication
- IOCs include 188.245.99.156 as C2 and pool.moneroocean.stream as mining pool
- Defenders advised to patch CVE-2026-81934 and harden exposed Redis instances
Vulnerabilities mentionedAll →
| CVE | Vulnerability | CVSS | EPSS | Flags | Affected | Exposure | Published |
|---|---|---|---|---|---|---|---|
| CVE-2026-81934 | Use-After-Free in Redis TLS Pending-Data Handling Enables Unauthenticated RCE Redis contains a use-after-free flaw (CWE-416) in the tlsProcessPendingData() function, which manages the TLS pending-data list, and it affects only deployments that are configured with TLS support. A remote, unauthenticated attacker who can reach the TLS-enabled Redis service can trigger the flaw; the CVSS 4.0 vector scores it as high attack complexity with present attack requirements, suggesting timing- or condition-dependent exploitation. Successful exploitation may allow the attacker to execute arbitrary commands with the privileges of the Redis server process. Any Redis installation running with TLS enabled is in scope, though affected version ranges are not specified in the available data. No public proof-of-concept exists and the flaw is not in CISA KEV (EPSS 0.4%), but related headlines note a massive Redis cryptojacking campaign hijacking thousands of Linux servers, so Redis deployments are actively targeted in the wild even if this specific flaw's exploitation is not yet confirmed. Do: Identify Redis instances with TLS enabled (e.g., tls-port or cluster TLS configuration) and restrict network access to trusted clients, since only TLS-enabled deployments are affected. Upgrade to a patched Redis release when the vendor publishes one (affected version ranges are not specified in the available data). In the meantime, monitor Redis servers for indicators of the cryptojacking activity reported against Redis deployments in the wild. | 7.5 | <1% |
| massLikely hundreds of thousands of TLS-enabled deployments worldwide (Redis runs in millions of environments and public internet scans have shown hundreds of… |
Indicators of compromiseauto-extracted · verify before use · export allAll →
| Type | Indicator | Context |
|---|---|---|
| domain | hunt.io | oop from believed-write to confirmed shell access (Source : Hunt.io). The flaw can allow a remote, unauthenticated attacker to |
| domain | moneroocean.stream | ocal mining pool/proxy used by the operator’s own host pool.moneroocean[.]stream:443 Domain:port Mining pool used by botnet-deployed XMRig |
Full article817 words · extracted from gbhackers.com · click to collapse
A large-scale Redis cryptojacking operation targets thousands of exposed Linux servers by abusing unauthenticated Redis deployments to install XMRig cryptocurrency miners and establish durable, cron-based persistence.
The campaign scans IPv4 address ranges for Redis services exposed to the internet, typically on TCP port 6379, then attempts to interact with instances that allow connections without authentication.
Once access is obtained, the attackers use Redis’s administrative CONFIG SET command to modify the database save directory and file name.
The objective is to write attacker-controlled content into a Linux cron directory, turning Redis’s persistence mechanism into a code-execution and persistence primitive.
Attackers set the Redis working directory to locations such as /etc/cron.d or /var/spool/cron, configure a target filename through CONFIG SET dbfilename, store a malicious cron entry with SET, and invoke BGSAVE.
Redis then writes its database snapshot to the selected filesystem path.
When cron processes the file, it executes the attacker’s command, commonly fetching and launching an XMRig-based Monero miner.
Elastic’s published detection logic specifically identifies this chain: CONFIG SET dir, CONFIG SET dbfilename, SET, and BGSAVE operations associated with cron-directory persistence.
Cryptojacking operators favor Redis because misconfigured instances can provide an immediate foothold on cloud workloads, virtual private servers, and container hosts.
A successful compromise can consume CPU resources, degrade application performance, inflate cloud-compute costs, and potentially give the operator a platform for deeper discovery or lateral movement.
Hunt.io Researchers said that, the activity, RedisRaider, relies on internet-wide scanning and native Redis commands rather than a software exploit, making configuration errors not just unpatched CVEs the primary entry point.
Redis Cryptojacking Campaign
The use of cron persistence is particularly significant. Restarting Redis or killing a visible mining process may not remove the intrusion if the rogue cron file remains in place.
The operator works from a master list of 12,966 candidate Redis hosts (targets.txt, mirrored as redis_fleet.txt), narrowed down to 2,342 confirmed to take commands without authentication (noauth_hosts.txt).
Administrators investigating high CPU utilization should therefore inspect not only running processes but also cron directories, systemd units, shell startup files, /tmp, and Redis configuration changes.
The campaign also illustrates a recurring reality in cloud security: services intended for internal application communication are often unintentionally reachable from the public internet.
Redis should not be exposed directly without strict network controls, authentication, access control lists, and encryption.
In many environments, binding Redis to localhost or a private interface and enforcing security-group restrictions can eliminate the initial access path entirely.
The script pings the victim, sets dir to a candidate SSH path and appendfilename to authorized_keys, SETs a marker key holding the public key, flips on appendonly, and forces a flush with BGREWRITEAOF.
The renewed attention on exposed Redis services arrives as defenders are also addressing CVE-2026-81934, a Redis TLS use-after-free vulnerability in tlsProcessPendingData().
The flaw can allow a remote, unauthenticated attacker to execute commands with the privileges of the Redis server when TLS is enabled.
Affected Redis versions include releases prior to 6.2.24, 7.2.16, 7.4.11, 8.2.9, 8.4.6, 8.6.6, 8.8.2, and 8.10.1.
Although the RedisRaider-style intrusion path primarily abuses unauthenticated or improperly exposed instances rather than depending on this vulnerability, organizations should treat patching and configuration hardening as parallel priorities.
Fixed Redis releases include 8.2.9, 8.4.6, 8.6.6, 8.8.2, and 8.10.1 for affected branches.
Security teams should immediately search Redis logs for suspicious CONFIG SET dir, CONFIG SET dbfilename, BGSAVE, and SET activity, particularly where the configured path references cron locations.
They should also examine outbound connections from Redis hosts, unexpected xmrig processes, sustained CPU saturation, unauthorized cron files, and changes to redis.conf.
Redis instances should be removed from public exposure, protected with ACLs and strong authentication, restricted through host firewalls and cloud security groups, and run with the minimum filesystem permissions possible.
Organizations should also rotate credentials and investigate adjacent infrastructure if an exposed Redis server is confirmed compromised, because cryptomining may be only the visible payload of a broader infrastructure-abuse operation.
IOCs
| Indicator | Type | Role |
|---|---|---|
| 188.245[.]99.156 | IP | Operator host — rogue Redis endpoint, C2, payload staging |
| 188.245[.]99.156:10000 | IP:port | C2 callback endpoint |
| 188.245[.]99.156:16379–16385 | IP:port range | Rogue Redis replication ports |
| 45.155[.]102.89:10128 | IP:port | Local mining pool/proxy used by the operator’s own host |
| pool.moneroocean[.]stream:443 | Domain:port | Mining pool used by botnet-deployed XMRig |
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.
★ Learn 7 Metric-Gated AI SOC Deployment Phases – Download Free AI SOC Deployment Playbook 2026.
Mayura Kathirhttps://gbhackers.com/
Mayura Kathir is a cybersecurity reporter at GBHackers News, covering daily incidents including data breaches, malware attacks, cybercrime, vulnerabilities, zero-day exploits, and more.
Text extracted automatically; images, tables and formatting may be missing. Original: https://gbhackers.com/redis-cryptojacking-campaign/