Cloud Incident Response Blog | Cado Security

Redis Miner Leverages Command Line File Hosting Service

Written by jbowen@cadosecurity.com | Mar 2, 2023 11:00:00 AM

Cado Labs researchers recently discovered a novel cryptojacking campaign targeting insecure deployments of Redis. Underpinning this campaign was the use of transfer.sh, a free and open source command line file transfer service. 

While the service has been in existence for some time - commits to the Github repository go back as far as 2014 - reports of it being used for malware distribution are rare. However, Cado Labs telemetry suggests that this is changing, with an uptick in use of the service since the beginning of 2023. 

It’s not clear what’s driving the move to transfer.sh. It’s possible that it’s an attempt at evading detections based on other common code hosting domains (such as pastebin.com). Equally, it could be that similar services have implemented additional measures to remove malicious code. Regardless of the reason, security professionals should be aware of this trend and implement detections accordingly.

transfer.sh

It’s worth stressing that, similar to Pastebin or any other file hosting service, transfer.sh is perfectly legitimate. However, its emphasis on command line interactivity makes it a perfect candidate for hosting and delivery of malicious payloads. 

Many of the cloud-focused malware campaigns analysed by Cado Labs rely on shell scripts, especially cryptojacking campaigns. Since these campaigns often retrieve payloads using common Linux data transfer utilities, transfer.sh seems like an ideal solution and potential replacement for services like Pastebin. 

Initial Access

Initial access for this campaign was achieved by exploiting an insecure deployment of Redis, writing a cron job to the data store and forcing Redis to save the database file to one of the cron directories. When the cron scheduler reads files in the directory, the database file is read and parsed as a cron job, resulting in arbitrary command execution. 
This is a common attack pattern that’s been covered in previous Cado Labs reports and is a favourite of cloud-focused threat groups, such as WatchDog and TeamTNT.


Example initial access Redis commands

As can be seen in the above example, Redis is exploited to register a simple cron job that is executed every second minute and runs a cURL command silently to retrieve a payload at https://transfer[.]sh/QQcudu/tmp[.]fDGJW8BfMC. This file is saved as .cmd and executed with bash. 

Executing the script by invoking bash directly ensures that the commands contained within the script won’t be written to the history file, acting as an anti-forensics measure.

Primary Payload

Since the malware’s main objective is to mine cryptocurrency on the target machine, the script begins with several preparatory actions to ensure the hardware can be effectively utilised. This includes typical system weakening steps, such as disabling SELinux and ensuring DNS requests can be resolved by public resolvers, along with removing existing cron jobs and the cron spool.

Memory Configuration

The script also uses the linux sync command to force the kernel to write data currently held in memory buffers to disk. Similarly, it writes the integer ‘3’ to the file /proc/sys/vm/drop_caches. This forces the kernel to drop slab objects such as dentries (memory-resident data structures representing directories) and inodes (memory-resident data structures representing files), both of which are used as a cache of filesystem resolutions by the kernel.

This is a novel technique which is assumed to aid the execution of XMRig by freeing up RAM as much as possible.

It should be noted that Linux kernel documentation recommends against the modification of the drop_caches file for this purpose, due to performance issues arising from recreation of the cached objects. Naturally, this is likely to wreak havoc on a production system.

Actions on Objective

The remainder of the script follows a standard pattern of clearing log files, configuring iptables, killing competing miners and installing additional packages. Once complete, the binaries for pnscan and XMRig are retrieved.


Retrieving additional payloads

A custom XMRig configuration is then written to disk, which registers the miner with the following mining pools:

  • xmr.pool.gntl.co.uk
  • pool.hashvault.pro
  • xmr-eu1.nanopool.org
  • monerohash.com
  • pool.supportxmr.com
  • ca.monero.herominers.com
  • xmrpool.eu
  • pool.xmrfast.com
  • pool.xmr.pt


Snippet of mining configuration

Propagation

As mentioned previously, the script retrieves the pnscan mass network scanning utility. This utility is often used for finding vulnerable Redis servers and propagating a copy of the script to them. This technique has been previously attributed to WatchDog, and uses an interesting combination of the Linux seq and sort commands to build up a list of IP addresses to target.


Example of pnscan commands to find Redis instances

Conclusion

Malware developers have long relied upon free file or code hosting services to host additional payloads. Such services offer a level of anonymity and availability that is difficult to overlook, if you are conducting opportunistic cyber attacks. Once services become known for malware distribution, detection products are quick to add alerts for traffic to such domains. Malware developers are fully aware of this and are quick to find alternatives. 

Although it is clear that the objective of this campaign is to hijack system resources for mining cryptocurrency, infection by this malware could have unintended effects. Reckless configuration of Linux memory management systems could quite easily result in corruption of data or the loss of system availability. Cryptojacking is typically seen as a low-impact cyber attack. Yet, if something goes wrong with the low-level changes implemented in order to prepare the system for mining, the impact could be much greater. 

Indicators of Compromise (IoCs)

Files SHA-256
.cmd 202ce93435f78009995f57eded544959884258f96d178173a54eee47f16e8834
.dat c43191f98eb5b5ef792e19089317e4ec411c696c3bf501b17f27bfad4b75eb1e

URLs
hxxps://transfer[.]sh/mtKUQC/run[.]sh
hxxps://transfer[.]sh/QQcudu/tmp[.]fDGJW8BfMC