Rclone Wars: Transferring leverage in a ransomware attack

Ransomware has always been about leverage, and sometimes, just encrypting files is enough to get a payment. However, as organizations have gotten better about data backup and recovery practices—by implementing policies like the “3-2-1 rule,” for example—ransomware operators find themselves having to apply more and different kinds of leverage.

A so-called “double extortion” scheme, where an adversary encrypts files and threatens to leak stolen data, is one prominent example of this. In fact, the extortion side of these schemes is proving so effective that one prominent ransomware group recently announced that it would stop encrypting files and focus entirely on extortion moving forward.

While piling extortion on top of ransomware is an effective way of increasing leverage, it also adds conspicuous opportunities for detection in the form of illicit file transfer activity. This post offers some detection strategies that security teams can employ to detect malicious file transfer activity. Since we’re publishing this on Star Wars Day, we’d like to take you on an epic detection adventure. May the fourth be with you!

With the growing number of data backup solutions, it can be hard to decipher where ransomware operators might choose to store their newly stolen data. Detection can be a particular challenge when adversaries choose to use services that are common in enterprise environments, like Google Drive or Amazon S3. Luckily for us though, they very frequently use cloud storage services that aren’t normal in enterprise environments. And even when adversaries exfiltrate your data to seemingly normal cloud storage providers, they often do so with unusual file transfer utilities.

Red Canary has observed Mega.io used as an exfiltration destination in multiple incident response engagements this year. In these attacks, we’ve also witnessed adversaries leveraging legitimate file transfer utilities that Mega provides for free to its customers, making it easy for users to upload files. We’ve identified exfiltration to file sharing services via other tools as well, but we’re going to focus entirely on Mega-related tools, like MegaSync and MegaCmd, and on the open source, cross-platform utility Rclone.

Asking the right questions

Even if our focus is somewhat limited, the detection principles included in this article can be readily abstracted and applied to additional file transfer utilities and other legitimate tools that are being co-opted for evil. Simply alerting on the use of any of these tools is trivial, and we include various binary metadata below that you can use to accomplish just that. Unfortunately, our experience across many short term incident response engagements is that adversaries generally try to evade simple security controls by renaming these tools.

As such, you’ll need to understand the following:

The authorized file sharing services and utilities in your environment
The file sharing services and tools used in your environment, authorized or not
The normal installation file paths for these tools
The legitimate binary metadata associated with these tools
The behaviors typically associated with these tools, including if and where they make network connections

Executive Summary: 2024 Threat Detection Report

Learn more

Mega detection

Mega provides users with end-to-end encryption of files, a free basic storage tier, and a suite of tools used to transfer files remotely. Rather than hassling with hosting their own file sharing servers, adversaries would rather make use of already existing cloud storage, especially ones that allow semi-anonymous payment via cryptocurrency like Bitcoin. Simply blocking network connections to Mega-related IP addresses might be a viable security control in certain environments, but detecting the actual file transfer utilities that adversaries leverage will offer better defense-in-depth against illicit data transfer.

One such utility is Mega’s main client application MegaSync, which is designed for routine file transfers and operates similarly to other cloud storage software such as Google Drive and Dropbox. In addition to MegaSync, we’ve also observed adversaries using the interactive command line variant known as MegaCmd. This tool offers many of the same capabilities as MegaSync but from the command line.

Establishing the baseline

Under normal circumstances, you can expect MegaSync to have the following attributes:

Metadata attribute	Value
Metadata attribute : Process name	Value : `megasync.exe`
Metadata attribute : Process path	Value : `C:\Users\{user}\AppData\Local\MEGAsync\MEGAsync.exe`
Metadata attribute : Description	Value : MEGAsync
Metadata attribute : Internal name	Value : `MEGAsync.exe`
Metadata attribute : Product name	Value : MEGAsync

It’s important to understand these baseline attributes because adversaries rarely execute tools like MegaCmd or MegaSync under their original filename. In this way, successful detection requires that you are able to determine the true identity of a given process regardless of what it claims to be. In other words, you might achieve a good detection outcome by identifying processes based on metadata like their internal name and then alerting when the internal name and the presented process name do not match. Similarly, you may be able to achieve success by looking for file path deviations.

Overt use of Mega

Adversaries often rename MegaSync to circumvent application controls in environments where the utility is not approved for use. However, this isn’t always the case. Trend Micro has reported that the Nefilim ransomware simply drops MegaSync into its normal file path under its normal name. If MegaSync isn’t approved software in your environment, then you may be able to detect its use by looking for the execution of a process that is megasync.exe from a path that includes the following: \\AppData\\Local\\MEGAsync

On top of client applications such as those provided by Mega, many ransomware families may use other software or built-in operating system utilities to exfiltrate data. We’ll use Mega as the example here, but you could just as well replace mega.io with whatever service you want to look out for. Since blocking a domain outright is trivial, we’ll assume that you’re okay with web browsers making network connections to Mega but want to know when anything else does.

If that’s the case, you can look for execution of any process that is not chrome.exe, firefox.exe, safari.exe, opera.exe, iexplore.exe, microsoftedge.exe, microsoftedgecp.exe, browser_broker.exe, msedge.exe, or brave.exe initiating a network connection to the domains mega.io or mega.co.nz.

Abnormal installation paths

In some instances, adversaries will execute MegaSync under its real name but from an unusual installation path. A detection analytic for identifying relocated copies of MegaSync execution may look something like this:

Binary named megasync.exe
File execution path does not include AppData\\Local\\MEGAsync\\

If there are circumstances in which it’s acceptable for Megasync to run from an abnormal directory, then consider tuning your detection logic accordingly.

Renaming MegaSync

We’ve observed adversaries executing renamed instances of Mega during incident response engagements associated with ransomware families like Nefilim, Sodinokibi, Pysa, and Conti. Alerting on the use of renamed instances of MegaSync could help prevent or reduce the scope of similar incidents moving forward. The following pseudo-analytic should detect renamed instances of MegaSync:

Look for the execution of a process that is not named megasync.exe but that executes with any any of the following corresponding metadata:
- a binary internal name that is megasync.exe
- a binary product name that is MEGAsync
- a binary description that is MEGAsync

The following image shows the execution of meg.exe. However, examining binary metadata reveals that meg.exe was in fact a renamed instance of MegaSync.

Rclone detection

Shifting our focus away from Mega-specific tooling, it wouldn’t be a blog post about exfiltration if we didn’t shine a light on the cross-platform, open source file transfer utility known as Rclone. Once a ransomware operator has hooked an organization, Rclone helps them reel in their catch. Without the ability to cut the data loose, any attempts at double extortion go out the window.

So, what makes Rclone so special? Its versatility. Once an adversary drops it on an endpoint, modifying the exfiltration destination is trivial. Adversaries can also choose from a list of built-in command flags that will perform various actions, or they can opt to supply their own configuration file and avoid the need to execute with various command line flags. As an example, maybe using a cloud storage provider is not an option because of a technical control that disallows network connections to the adversary’s hosting provider of choice. Rclone makes it very simple to use file transfer protocols such as FTP or SFTP, effectively enabling adversaries to move files wherever they want. See the Appendix for a list of known and supported Rclone commands at the end of this report.