Exposed Redis Instances Abused for Remote Code Execution, Cryptocurrency Mining

Click the icon to Follow me:- twitterTelegramRedditDiscord
DevOps 200x200 1

By David Fiser and Jaromir Horejsi (Threat Researchers)

Recently, we wrote an article about more than 8,000 unsecured Redis instances found in the cloud. In this article, we expound on how these instances can be abused to perform remote code execution (RCE), as demonstrated by malware samples captured in the wild. These malicious files have been found to turn Redis instances into cryptocurrency-mining bots and have been discovered to infect other vulnerable instances via their “wormlike” spreading capability.

Redis, which is intended to be used in trusted environments, has a protected mode configuration and is set to be updated to a new version, Redis 6.0, which will introduce new security features such as access-control lists (ACLs). However, as of now, Redis users with instances that don’t bear Transport Layer Security (TLS) encryption, password protection, or both are susceptible to having over 200 commands available once attackers get inside the environment. At present, Redis does not have authentication set by default. And even if a password is set, it’s important to keep in mind that the password should be strong enough in order to be resistant to brute-force attacks.

We’ve observed attackers using these scenarios in a honeypot we’ve set up to attract and monitor attackers in the wild:

Scenario 1: Abusing the config command

An attacker sets several keys on a Redis database file as cron tasks. The database values follow a specification of cron (a daemon that executes scheduled commands) and crontab (a file that is used to schedule the execution of programs) file formats.

fig1Figure 1. Setting keys as cron tasks

Using the config command, the attacker sets the directory to /var/spool/cron and the dbfilename to a username (e.g., root) and saves the database (with the file name root).fig2 1Figure 2. Saving the database to cron directories

The content of the root file name looks like the screenshot below — basically a few readable lines written in the cron file format in between binary data.

figure3 1

Figure 3. What the cron file name looks like

Despite the fact that the file has a partly binary format, when cron is installed, it finds a valid entry and executes a downloaded shell script at the attacker’s discretion — all caused by an unsecured Redis instance.

fig4 1

Figure 4. An example of an RCE attack performed on an exposed Redis instance using cron

Scenario 2: Abusing the slaveof feature

The second approach is based on the fact that Redis can be used as a distributed database. In this approach, an attacker first crafts a malicious Redis instance and compiles a malicious Redis module. The crafted Redis instance becomes a master server that sends the slaveof command to the vulnerable instance. The attacker then initiates a full resync from the master and sends the malicious Redis module. Afterward, the module load command is triggered, effectively loading a backdoor inside the vulnerable Redis module. This technique was discussed by Pavel Toporkov, a security researcher, in his “Redis Post-exploitation” presentation at the ZeroNights conference in 2018.

It should be noted that starting with Redis 5.0, which was released in October 2018, Redis no longer uses the word “slave” and uses the replicaof command instead. However, for backward compatibility, the slaveof command still works for earlier versions.

fig5 1Figure 5. An example of a malicious Redis module registering three commands

fig6Figure 6. An example of a malicious Redis module’s deployment and command call

The malicious Redis module in this case downloads a version of the Kinsing malware, which then downloads and executes the XMRig Monero cryptocurrency miner.fig7 1

Figure 7. XMRig cryptocurrency miner executed from Redis found to be consuming significant resources

An overview of observed malware samples

In this section, we highlight a few notable malware samples that have been distributed in exposed Redis instances via either of the aforementioned methods, and that have been caught by our honeypots.

Case 1: Multiplatform shell-based worm installing cryptocurrency-mining malware

The first in-the-wild malware we observed was a newer version of a piece of cryptocurrency-mining malware that was detected to have taken advantage of known vulnerabilities in the search engine Elasticsearch. This malware is a multiplatform worm: It has both Linux and Windows versions with a set of scripts written in shell and PowerShell, and some of its components are binaries written in Golang that have been compiled into executable files. The infection can be noticed in a modified cron file (as seen in Scenario 1) containing a link to an file.

This is the starting or initialization script of the shell-based malware. The important function of this script is to uninstall, terminate, and kill various resource-intensive and competing processes. This script runs the following tasks:

  1. Uninstall the Alibaba Cloud service (an action that may have been inspired by this repository).
  2. Uninstall the Tencent agent (an action that may have been inspired by this repository).
  3. Delete various files and kill various processes and Docker instances.


  1. Kill processes that bear the same name as the modules used by this specific malware:
  • sysguerd
  • sh
  • sysupdata
  • networkservics
  1. If root, download and install malware files into /etc/, otherwise, use /tmp/. These files are miner, miner config, watchdog, update, and scanner.
  2. Add persistence through, which has the same contents as and is added to crontab.
  3. Install a new Secure Shell (SSH) authorized key into /root/.ssh/authorized_keys:


  1. Block outgoing traffic to ports 3333, 5555, 7777, and 9999 using the iptables command iptables -A OUTPUT -p tcp –dport ???? -j DROP.
  2. Clear bash history.
  3. For all hosts (public keys of previously accessed servers) in /root/.ssh/known_hosts, and if the /root/.ssh/ file exists (a file with the public key of a previously generated SSH key pair), SSH then tries to connect to all of these known hosts via ssh -oBatchMode=yes -oConnectTimeout=5 -oStrictHostKeyChecking=no. For each successfully connected instance, it will download and execute http://<server>/<path>/


  1. Download and execute http://<server>/<path>/ on the affected machine.

This is an installation script used for performing the following tasks:

  1. Kill the following running processes:
  • redisscan (a process that recursively scans the keyspace of Redis 2.8)
  • ebscan (a scan process that uses the masscan tool)
  • redis-cli (Redis’s command line interface, which allows the sending of commands to Redis and the reading of the server’s replies directly on the terminal)
  • barad_agent (a cloud-related service)
  • masscan (a mass IP port scanner)
  • .sr0
  • clay
  • udevs
  • .sshd (an OpenSSH server process that listens to incoming connections)
  • xig
  1. Install the required software via apt-get or yum package managers. The required software includes redis-tools, iptables, wget, curl, and unhide.
  2. Kill hidden processes.
  3. Download and install masscan and pnscan.
  4. Download and execute

This malicious, custom-made script is used to perform scans for Redis instances, with the following actions. Redis instances usually listen on port 6379. Two publicly available scanners are used for performing the Redis scanning task.

  1. Block all incoming traffic to port 6379 and allow only incoming traffic from the localhost using the iptables command.
  2. Create a .dat file that contains the following contents. This method was described in Scenario 1.


  1. Scan port 6379 with pnscan. In this method, pnscan sends bytes *1rn$4rninforn and looks for os:Linux in the response from the scanned machine.
  2. Scan port 6379 with masscan. The scan is run with the shard parameter to randomly choose one of 22,000 IP address subsets.
  3. Scan port 6379 with masscan. In this scan, IP addresses from ranges of private IP addresses and ranges belonging to Alibaba Cloud, Chinanet Shanghai, and China Unicom are used.
  4. Scan port 6379 with masscan and take known IP addresses from the current network interfaces (using the ip a command).
  5. For active Redis instances (found via the scanning tasks mentioned in 3 to 6), run:

redis-cli -h HOST -p PORT –raw -a PASSWORD –raw <content of .dat>

The list of weak passwords used include:

  • empty password
  • redis
  • root
  • oracle
  • password
  • [email protected]
  • abc123
  • abc123!
  • 123456
  • admin

After a successful connection to the newly found Redis instance, the script is executed via Scenario 1 and the whole infection process is repeated.

With the exception of the analyzed scripts above, this malware also uses a few binaries.

The watchdog process, which is a Golang-based compiled file, functions mainly to start four watchdog threads:

  • main_dog_protect_cron_thread

This checks persistence in cron, and if necessary, adds persistence.

  • main_dog_protect_process_thread

This checks if required processes are running, and if not, starts them.

  • main_dog_update_thread

If new versions are available, this updates the miner, config, scanner, and watchdog binaries.

  • main_dog_protect_cc_thread

This checks if a command-and-control (C&C) server is active. If it’s not, this looks for a hard-coded address via the Ethereum blockchain explorer.


The blockchain data is then transformed to the new C&C server address, which is a very useful feature especially when attackers lose their control of the current C&C servers. After a new C&C address is obtained, the thread checks if the server is active. If it is, the thread appends a hard-coded string with a URL path and downloads the or initialization scripts, and the whole infection process starts again from the beginning.

figrs7 2

As of the publication of this article, there are no transactions associated with the hard-coded Ethereum address.

figrs7 3

The scanner process, which is a Golang-based compiled executable, contains a set of exploits for various online services and devices.

The main_scan procedure calls the following scanning methods:

  • scan_exp_Cctv_exploit
  • scan_exp_Redis_exploit
  • scan_exp_Drupal_exploit
  • scan_exp_Hadoop_exploit
  • scan_exp_Spring_exploit
  • scan_exp_Thinkphp_exploit
  • scan_exp_Weblogic_exploit
  • scan_exp_Sqlserver_exploit
  • scan_exp_Elasticsearch_exploit

Alibaba Cloud Security made an analysis of the scanner module with a list of exploits that is almost identical to the list above, with the addition of a new CCTV exploit routine.

It’s important to note that there is also a version of Case 1 for Windows using PowerShell; the Task Scheduler is used for persistence, while netsh and net user are used for adding backup entries to the system.

Case 2: Kinsing malware

The Kinsing malware supports several commands and functions, and has capabilities for both scanning of vulnerable machines and backdoor features. The function main_getTask queries <server>/get/ and enables the execution of a task.

The function main_doTask then implements the following commands:



scan TCP scanner
update Downloads new bot version and runs it
exec Runs from command line
masscan Downloads and scans with masscan
exec_output Runs from command line; output is POSTed to <server>/o
Socks Socks proxy
backconnect Connects to another machine using TCP
request Performs HTTP request
tcp Performs TCP request
download_and_exec Downloads and executes
redis_brute Brute-forces Redis instances

The communication with a C&C server is encrypted with a hard-coded Rivest Cipher 4 (RC4) password, and the URL path depends on the type of request it sends:

  • /get = get task
  • /h = health
  • /getT = get targets
  • /l = log
  • /o = execute output
  • /r = result of the task
  • /s = send socks
  • /mg = get cryptocurrency miner’s process ID (PIC), e.g., {“Pid”:110}
  • /ms = send cryptocurrency miner’s PID

fig8 1

Figure 8. Decrypting of a received response to /get path

The function main_minerRunningCheck runs in sequence with main_getMinerPid, main_isMinerRunning, and main_minRun, which first kills a currently running process called kdevtmpfsi, and then drops and runs the miner. This malware installs the XMRig malware and names it kdevtmpfsi.

The function main_healthChecker regularly checks if a C&C server is present by sending the GET request to <server>/h. An RC4-encrypted response returns OK if everything is fine.

The function main_resultSender tries to POST the results of which tasks are completed to <server>/r. Communication is also RC4-encrypted.

Conclusion and security recommendations

Proper security measures should be taken, especially within the DevOps environment. Keeping Redis instances unsecured may lead to RCE, techniques for which are actively searched for and exploited in the wild by malicious actors. In this article, we discussed how exposed Redis instances can be abused for cryptocurrency mining, which is a relatively noisy process that uses a significant amount of resources in an affected device. However, this may not be the be-all and end-all of the possible abuse surrounding exposed Redis instances, as the ability to execute code is an attacker’s holy grail. Once RCE becomes possible, it can be the first big and detrimental step for malicious actors toward conducting stealthier and more targeted attacks.

For developers, here are several security recommendations for keeping environments better protected:

  • When running server-side software, make sure that it is not running under root Even when running containers, users must follow best practices and apply the principle of least privilege.
  • Keep your software updated to the latest version and use strong passwords. Don’t expose it to the internet without applying proper security measures.
  • If you are inspecting Redis logs, you can see ongoing attacks from its actual lines. In the screenshot below, pay attention to the full resynchronization request from the master. The replica received about 55 kB from the master, which is exactly the size of the malicious Redis module.


Trend Micro’s cloud security solutions

  • The Trend Micro Hybrid Cloud Security solution simplifies security for organizations, allowing them to focus on security and compliance as they migrate to the cloud or adopt DevOps. It provides an all-in-one solution that has the breadth, depth, and innovation required by cloud security, and a single platform for visibility into leading environments like Amazon Web Services (AWS), Microsoft Azure, Google Cloud, and Docker.
  • The Trend Micro™Cloud One™ software-as-a-service (SaaS) platform provides organizations with real-time security for workloads, applications, containers, serverless environments, file storage systems, and networks, and a single-pane-of-glass view of their hybrid cloud environments.
  • The Cloud One platform also includes Cloud One – Conformity, which has automated controls for AWS ElasticCache, which is an in-memory data store for Redis. It ensures that Redis isn’t on the default portand has encryption for data while in transit and at rest.
  • For organizations looking for runtime workload and container security or container image security as software, the Deep Security™and Deep Security Smart Check solutions can scan container images during pre-deployment and at runtime.

Trend Micro™ Deep Security™ and Vulnerability Protection protect users via the following rules:

  • 1010231 – Redis Cron Remote Code Execution Vulnerability
  • 1009967 – Redis Unauthenticated Code Execution Vulnerability

Indicators of compromise

File Function


clean.bat Add user script 19967f6467f05f1ac286eb8b8bf7e251075b7d288fbe9b719b8de0b6330c8787
config.json Miner config 2c2438019c10352cc6678474072ce57a4191fd6ce54391d4975012f587bec1a0
init.ps1 Init script d0a28e1f768c524ed3ff962c36ab2861705cdd4fd83ee5b3dc8d897f2034cb05 Init script 3c7faf7512565d86b1ec4fe2810b2006b75c3476b4a5b955f0141d9a1c237d38 Install script 6faa026af253c784ef97ffec3a9953055d394061a9a1fbfdcc5b28445b73ffdc
kdevtmpfsi XMrig 24FDF5B1E1E8086031931F2678D874487316DC1E266581B328D6E34A1FD7748C
kinsingbRiXVrNDJc Bot d247687e9bdb8c4189ac54d10efd29aee12ca2af78b94a693113f382619a175b
networkservics Scanner ea55a206f7047f54a9e97cc3234848dfd3e49d0b5f9569b08545f1ad0e733286
networkservics.exe Scanner b6fc454e667081c2add1ffd5a54bafb428a82d8d8a3e34c61fc59075118f4afd Redis module 1fd17076800d993609a8110084f9652d06fe50cd3a279ab709c65a044076fe6d Redis spreader e2b982f9540304e31ca8d1cdafb253da7d216d1cc939a281a1a95baaa4be9b2d
sysguerd Watchdog bceee7d9ace363ef2bfb1494a9784a6377fe14c4c5fefa0c180fcec33a5d1716
sysguerd.exe Watchdog 37ecccdfc185615d4452b5c77b7313222b14776c3032c156846258c8f63185fe
sysupdata Miner e7446d595854b6bac01420378176d1193070ef776788af12300eb77e0a397bf7
sysupdata.exe Miner 559a8ff34cf807e508d32e3a28864c687263587fe4ffdcefe3f462a7072dcc74
updata.ps1 Update d0a28e1f768c524ed3ff962c36ab2861705cdd4fd83ee5b3dc8d897f2034cb05 Update 3c7faf7512565d86b1ec4fe2810b2006b75c3476b4a5b955f0141d9a1c237d38


Multiplatform worm C&C servers

  • http://178[.]157[.]26
  • http://45[.]137[.]106

Kinsing C&C servers

  • http://45[.]10[.]88.102
  • http://91[.]215[.]169.111
  • http://139[.]99[.]50.255
  • http://193[.]33[.]87.220
  • http://195[.]123[.]220.193





The post Exposed Redis Instances Abused for Remote Code Execution, Cryptocurrency Mining appeared first on .

Original Source