Attackers increasingly using transfer.sh to host malicious code

For many years now, unsecured internet-facing Redis servers have been steadily getting co-opted by criminals to mine cryptocurrency, so the latest cryptojacking campaign spotted by Cado Labs researcher cannot be considered news. But one its elements points to a new trend: attackers have increasingly begun using the (legitimate) transfer.sh service to host malicious code.

They say their telemetry shows an uptick in the malicious use of the service since the beginning of 2023 and advise organizations’ defenders to implement detections for it.

The cryptojacking campaign

Redis is a popular open-source data structure store used as a distributed, in-memory database, cache and message broker.

Redis servers are meant to be accessed only by trusted clients inside trusted environments but, unfortunately, they are often getting exposed online – and attackers know it.

The ongoing cryptojacking campaign spotted by researchers is fairly unremarkable: The attackers are finding internet-exposed Redis API endpoints that don’t have authentication configured and use this security hole to remotely connect to the data store using the redis-cli command line tool.

“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,” they explained.

“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.”

The retrieved script prepares the target machine for covert cryptomining by performing actions such as disabling the SELinux kernel security module, configuring memory to free up RAM for the task, “killing” competing mining software, and clearing log files.

Finally, it retrieves XMRig (cryptomining software) and pnscan (network/port scanner) binaries from GitHub. Pnscan is often used for finding vulnerable Redis servers and propagating a copy of the script to them, and this whole process is, in this case, automatic.

Transfer.sh use

Whether organizations whose Redis servers start mining cryptocurrency after such a compromise will detect it or not depends on the target system and how much monitoring is enabled, Matt Muir, Threat Intelligence Researcher at Cado Security, told Help Net Security.

“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,” he explained.

But, more broadly, organizations need to be aware of attackers’ increasing use of transfer.sh for hosting malicious code.

“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,” Cado Security researchers noted, and pointed out that transfer.sh’s “emphasis on command line interactivity makes it a perfect candidate for hosting and delivery of malicious payloads.”

So, according to Muir, if you currently have a network-based detection for traffic to other suspicious file hosting domains (e.g., pastebin.com), you should supplement this detection with the transfer.sh domain.