The IT Nerd

Matt Muir, Threat Intelligence Researcher at Cado Security, recently discovered a novel crypto jacking campaign targeting insecure deployments of Redis that leverages transfer.sh, a free, open-source command line file transfer service. 

This research has been published and analyzes initial access achieved by an exploit that’s a favourite of threat actor groups WatchDog & TeamTNT, why this a novel technique through exploring its primary payload (memory configuration, actions on objective, and propagation), and IoCs.

Although reports of this service being used for malware distribution have been rare, Cado Labs telemetry suggests that this is changing as researchers are seeing an uptick since the beginning of this year.

You can read the research here. But I also have a Q&A with Matt Muir, Threat Intelligence Researcher at Cado Security:

1. The attackers compromise Redis insecure instances (do you know how?)

• Redis exposes an API endpoint that allows developers to interact with the data store via the redis-cli command line tool
• In more recent versions, they introduced authentication for this API endpoint (ignoring requests from unauthenticated clients)
• Despite this, Redis’ security documentation states that DBAs should avoid exposing this endpoint to the internet
• If the API endpoint is exposed to the internet, and authentication isn’t configured (or available), it’s possible for an attacker to remotely connect to the data store using redis-cli
• Attackers use tools like pnscan (such as in this campaign) to conduct mass scanning of the internet, looking for nodes with the Redis default port open
• If they find such nodes, they attempt to connect to Redis in an opportunistic manner

2. Write a cron job that will trigger the reading of a file (exploit?) that allows them to execute code

• Once connected to the data store, it’s possible to write values to specific keys
• One such value could be a string representing a cron job
• It’s also possible to use redis-cli to save a version of the database to disk
• Once a string with cron syntax is written to a key, you can then use redis-cli to set the working directory to a cron directory
• Saving the contents of the database to disk saves a binary file (representing the database) with the cron job embedded as a string
• Crond then parses the database file as if it were a plaintext file containing a cronjob and registers the job
• Execution is then determined by the syntax of the job
• In this case, the job can be seen in the ‘command’ section of the first screenshot of the blog
• It retrieves a script (analysis of which forms the bulk of the blog) from transfer.sh, saves it as .cmd and executes it via bash at an interval of every second minute

3. The (same?) cron job executes every second minute and runs a cURL command to retrieve a payload from transfer.sh, which is saved as a .cmd file, which is executed and:

• Correct, see above

4. Prepares the targeted host for cyptomining (how “noisy” are these measures?)

• This depends on the target system and how much monitoring is enabled
• A lot of the host configuration would appear in audit daemon logs but these aren’t enabled by default
• SELinux interaction appears in /var/log/avc.log (for some distros)
• Configuration of drop_caches would be logged to /var/log/messages or /var/log/syslog depending on host settings

5. Finally, the script retrieves the pnscan and XMRig binaries (also from transfer.sh?)

• These tools are open source and are hosted on Github

6. While XMRig starts mining, the script uses pnscan to find vulnerable Redis servers and propagate a copy of the script to them (Only Redis servers on the same network, or? Which weaknesses does it exploit to gain access to them and execute the script? How is the script delivered? Is this whole process automatic? If yes, could this be considered worm-like behavior?)

• Propagation is conducted via the method described above
• Pnscan is used for internet-wide scanning, so distribution is not limited to the local network
• Which weaknesses does it exploit to gain access to them and execute the script?
  • Unauthenticated Redis file write, as mentioned above
• How is the script delivered?
  • using the unauthenticated Redis file write method to write a cron job
• Is this whole process automatic? If yes, could this be considered worm-like behavior?
  • yes and yes

– When you say “Security professionals should be aware of [the trend of criminals using transfer.sh] and implement detections accordingly,” what do you specifically mean?

• If you currently have a network-based detection for traffic to other suspicious file hosting domains (e.g. pastebin.com), supplement this detection with the domain transfer.sh
• transfer.sh wasn’t previously known to host malware, now there’s evidence that it is being used to host malware