Massive Redis Cryptojacking Campaign Hijacks Thousands of Linux Servers

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.