Anatomy of a Redis mining worm

Published: 2018-05-18
Last Updated: 2018-05-18 11:58:11 UTC
by Remco Verhoef (Version: 1)
0 comment(s)

Public accessible Redis servers are being exploited for a while now, but we stumbled upon an interesting mining worm in one of our honeytraps. Within the past 5 days, we've seen 173 unique IP addresses that have been infected with this worm, whereof 88% of the infected servers are located in China, 4% in the US and 4% Hongkong.

The worm searches for open Redis servers (port 6379), configures cron to download itself every few minutes (using a file upload service), starts mining and finally looks for new targets. It will send the payload "*1\r\n$4\r\nINFO\r\n" and check the response for the string "os:Linux", to prevent replication to other operating systems. 

When the cron job executes, the worm will disable security, close the existing publicly open Redis port using iptables, disable SELinux and disable caching. If there are miners running, they will be killed and the cryptonight miner starts. The worm is taking advantage of public file hosting, in this case,, to replicate itself. removes files after 14 days, that's assumed to be the reason that a copy will be made on each replication.

The miner that is being downloaded (Virustotal) uses the cryptonight proof-of-work algorithm, this algorithm is CPU only, which makes it efficient to run on exploited servers. When reversing the binary we noticed the following configuration: 

 { algo": "cryptonight", "av": 0, "background": true, "colors": false, "cpu-affinity": null, "cpu-priority": null, "donate-level": 5,    "log-file": null, "max-cpu-usage": 50, "print-time": 60, "retries": 5, "retry-pause": 5, "safe": true, "threads": null,
"pools": [{ "url": "", "user": "N9emUy6baNTbNwFzZmjzzg7bntSr6TFYRiJy6oXuos HhQZamMFZXzpYENJcdXvC5cwN8oqCrXJ4YYgWRgBNXZk6a33wT7os", "pass": "x", "keepalive": true, "nicehash": true}],
"api": { "port": 0,  "access-token": null, "worker-id": null }}

Especially for a bash worm, it is careful to remove all kind of residue, like putting a bash trap to remove everything on script exit, removing logs, syncing and droping caches.

Script breakdown:

  • delete stale (older than +60 minutes) mutexes
  • add a mxff0 that will function as mutex, if it already exists it will quit. This prevents running multiple instances of the same script.
  • configure a trap handler, that will remove all scripts when the script is exited
  • disable SELinux
  • remove current crontab (which contained previous installs of the worm)
  • add the Google ( nameserver to /etc/resolv.conf
  • empty tmp folders
  • sync caches and then clear all Linux caches
  • update the security limits for file and processes
  • the worm disables access from the outside and enables loopback listening
  • it kills competitive miners, other processes, and scanning scripts
  • clean bash history, logs, mail spool and the tmp directory
  • check for Centos, RedHat, Fedora or Ubuntu, Debian, Mint or Knoppix to use apt or yum
  • installs Redis client tool and other tools
  • download and build pnscan
  • download the cryptominer binary and upload again to (virustotal)
  • rename the miner to .gpg and execute it
  • the worm will change its own script to upload a new script to prolong its existence
  • prepare .dat Redis script to exploit other servers
  • scans complete subnets for other open Redis servers, in random order within ranges to 
  • pnscan will send the payload and look for the "os:linux", output to .r.$x.$y.o (contains all open Redis servers)
  • filter out only Linux servers, output to .r.$x.$y.l
  • mass exploit using redis-cli 
  • repeat previous steps for next subnet
  • remove all evidence

If you're interested, you can find the source here.


  • sha256: 9756e66c168ec963c58b3d0ca5483927c14a64a99ba718fa9488a52d4d207ed6
  • ssdeep: 12288:s/d8Tu4RnpO4rFnRwIzUDAwtkgWRFV0+JvZNFIZcLA43LLXl4Aq1A:kH41I4rVRDUDAwGL/bIZcLx3x
  • (
  • filenames: .gpg, .dat, .mxff0


0 comment(s)


Diary Archives