{
	"id": "bea2b1cc-335a-43c7-8c72-b8d025beb27c",
	"created_at": "2026-04-06T00:11:51.411844Z",
	"updated_at": "2026-04-10T13:11:53.619332Z",
	"deleted_at": null,
	"sha1_hash": "70ce53a0f0626a8a36a51e09b8e1ad3585a7c388",
	"title": "Rclone Wars: Transferring leverage in a ransomware attack",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 107700,
	"plain_text": "Rclone Wars: Transferring leverage in a ransomware attack\r\nBy susannah.matt@redcanary.com\r\nArchived: 2026-04-02 12:38:50 UTC\r\nTransferring leverage in a ransomware attack\r\nDefenders can sabotage double extortion ransomware schemes by detecting unusual file transfer utilities such as\r\nMega and Rclone.\r\nOriginally published May 4, 2021. Last modified July 19, 2024.\r\nRansomware has always been about leverage, and sometimes, just encrypting files is enough to get a payment.\r\nHowever, as organizations have gotten better about data backup and recovery practices—by implementing policies\r\nlike the “3-2-1 rule,” for example—ransomware operators find themselves having to apply more and different\r\nkinds of leverage.\r\nA so-called “double extortion” scheme, where an adversary encrypts files and threatens to leak stolen data, is one\r\nprominent example of this. In fact, the extortion side of these schemes is proving so effective that one prominent\r\nransomware group recently announced that it would stop encrypting files and focus entirely on extortion moving\r\nforward.\r\nWhile piling extortion on top of ransomware is an effective way of increasing leverage, it also adds conspicuous\r\nopportunities for detection in the form of illicit file transfer activity. This post offers some detection strategies that\r\nsecurity teams can employ to detect malicious file transfer activity. Since we’re publishing this on Star Wars Day,\r\nwe’d like to take you on an epic detection adventure. May the fourth be with you!\r\nWith the growing number of data backup solutions, it can be hard to decipher where ransomware operators might\r\nchoose to store their newly stolen data. Detection can be a particular challenge when adversaries choose to use\r\nservices that are common in enterprise environments, like Google Drive or Amazon S3. Luckily for us though,\r\nthey very frequently use cloud storage services that aren’t normal in enterprise environments. And even when\r\nadversaries exfiltrate your data to seemingly normal cloud storage providers, they often do so with unusual file\r\ntransfer utilities.\r\nRed Canary has observed Mega.io used as an exfiltration destination in multiple incident response engagements\r\nthis year. In these attacks, we’ve also witnessed adversaries leveraging legitimate file transfer utilities that Mega\r\nprovides for free to its customers, making it easy for users to upload files. We’ve identified exfiltration to file\r\nhttps://redcanary.com/blog/rclone-mega-extortion/\r\nPage 1 of 13\n\nsharing services via other tools as well, but we’re going to focus entirely on Mega-related tools, like MegaSync\r\nand MegaCmd, and on the open source, cross-platform utility Rclone.\r\nAsking the right questions\r\nEven if our focus is somewhat limited, the detection principles included in this article can be readily abstracted\r\nand applied to additional file transfer utilities and other legitimate tools that are being co-opted for evil. Simply\r\nalerting on the use of any of these tools is trivial, and we include various binary metadata below that you can use\r\nto accomplish just that. Unfortunately, our experience across many short term incident response engagements is\r\nthat adversaries generally try to evade simple security controls by renaming these tools.\r\nAs such, you’ll need to understand the following:\r\nThe authorized file sharing services and utilities in your environment\r\nThe file sharing services and tools used in your environment, authorized or not\r\nThe normal installation file paths for these tools\r\nThe legitimate binary metadata associated with these tools\r\nThe behaviors typically associated with these tools, including if and where they make network connections\r\nExecutive Summary: 2024 Threat Detection Report\r\nhttps://redcanary.com/blog/rclone-mega-extortion/\r\nPage 2 of 13\n\nLearn more\r\nhttps://redcanary.com/blog/rclone-mega-extortion/\r\nPage 3 of 13\n\nhttps://redcanary.com/blog/rclone-mega-extortion/\r\nPage 4 of 13\n\nMega detection\r\nMega provides users with end-to-end encryption of files, a free basic storage tier, and a suite of tools used to\r\ntransfer files remotely. Rather than hassling with hosting their own file sharing servers, adversaries would rather\r\nmake use of already existing cloud storage, especially ones that allow semi-anonymous payment via\r\ncryptocurrency like Bitcoin. Simply blocking network connections to Mega-related IP addresses might be a viable\r\nsecurity control in certain environments, but detecting the actual file transfer utilities that adversaries leverage will\r\noffer better defense-in-depth against illicit data transfer.\r\nOne such utility is Mega’s main client application MegaSync, which is designed for routine file transfers and\r\noperates similarly to other cloud storage software such as Google Drive and Dropbox. In addition to MegaSync,\r\nwe’ve also observed adversaries using the interactive command line variant known as MegaCmd. This tool offers\r\nmany of the same capabilities as MegaSync but from the command line.\r\nEstablishing the baseline\r\nUnder normal circumstances, you can expect MegaSync to have the following attributes:\r\nMetadata attribute Value\r\nMetadata attribute :\r\nProcess name\r\nValue :\r\nmegasync.exe\r\nMetadata attribute :\r\nProcess path\r\nValue :\r\nC:\\Users\\{user}\\AppData\\Local\\MEGAsync\\MEGAsync.exe\r\nMetadata attribute : Value :\r\nhttps://redcanary.com/blog/rclone-mega-extortion/\r\nPage 5 of 13\n\nMetadata attribute Value\r\nDescription MEGAsync\r\nMetadata attribute :\r\nInternal name\r\nValue :\r\nMEGAsync.exe\r\nMetadata attribute :\r\nProduct name\r\nValue :\r\nMEGAsync\r\nIt’s important to understand these baseline attributes because adversaries rarely execute tools like MegaCmd or\r\nMegaSync under their original filename. In this way, successful detection requires that you are able to determine\r\nthe true identity of a given process regardless of what it claims to be. In other words, you might achieve a good\r\ndetection outcome by identifying processes based on metadata like their internal name and then alerting when the\r\ninternal name and the presented process name do not match. Similarly, you may be able to achieve success by\r\nlooking for file path deviations.\r\nOvert use of Mega\r\nAdversaries often rename MegaSync to circumvent application controls in environments where the utility is not\r\napproved for use. However, this isn’t always the case. Trend Micro has reported that the Nefilim ransomware\r\nsimply drops MegaSync into its normal file path under its normal name. If MegaSync isn’t approved software in\r\nyour environment, then you may be able to detect its use by looking for the execution of a process that is\r\nmegasync.exe from a path that includes the following: \\\\AppData\\\\Local\\\\MEGAsync\r\nOn top of client applications such as those provided by Mega, many ransomware families may use other software\r\nor built-in operating system utilities to exfiltrate data. We’ll use Mega as the example here, but you could just as\r\nwell replace mega.io with whatever service you want to look out for. Since blocking a domain outright is trivial,\r\nwe’ll assume that you’re okay with web browsers making network connections to Mega but want to know when\r\nanything else does.\r\nIf that’s the case, you can look for execution of any process that is not  chrome.exe ,  firefox.exe ,\r\nsafari.exe , opera.exe , iexplore.exe , microsoftedge.exe , microsoftedgecp.exe ,\r\nbrowser_broker.exe , msedge.exe , or  brave.exe initiating a network connection to the domains mega.io or\r\nmega.co.nz .\r\nAbnormal installation paths\r\nIn some instances, adversaries will execute MegaSync under its real name but from an unusual installation path. A\r\ndetection analytic for identifying relocated copies of MegaSync execution may look something like this:\r\nBinary named  megasync.exe\r\nFile execution path does not include  AppData\\\\Local\\\\MEGAsync\\\\\r\nhttps://redcanary.com/blog/rclone-mega-extortion/\r\nPage 6 of 13\n\nIf there are circumstances in which it’s acceptable for Megasync to run from an abnormal directory, then consider\r\ntuning your detection logic accordingly.\r\nRenaming MegaSync\r\nWe’ve observed adversaries executing renamed instances of Mega during incident response engagements\r\nassociated with ransomware families like Nefilim, Sodinokibi, Pysa, and Conti. Alerting on the use of renamed\r\ninstances of MegaSync could help prevent or reduce the scope of similar incidents moving forward. The following\r\npseudo-analytic should detect renamed instances of MegaSync:\r\nLook for the execution of a process that is not named  megasync.exe but that executes with any any of the\r\nfollowing corresponding metadata:\r\na binary internal name that is  megasync.exe\r\na binary product name that is  MEGAsync  \r\na binary description that is  MEGAsync\r\nThe following image shows the execution of meg.exe . However, examining binary metadata reveals that\r\nmeg.exe was in fact a renamed instance of MegaSync.\r\nRclone detection\r\nShifting our focus away from Mega-specific tooling, it wouldn’t be a blog post about exfiltration if we didn’t\r\nshine a light on the cross-platform, open source file transfer utility known as Rclone. Once a ransomware operator\r\nhas hooked an organization, Rclone helps them reel in their catch. Without the ability to cut the data loose, any\r\nattempts at double extortion go out the window.\r\nhttps://redcanary.com/blog/rclone-mega-extortion/\r\nPage 7 of 13\n\nSo, what makes Rclone so special? Its versatility. Once an adversary drops it on an endpoint, modifying the\r\nexfiltration destination is trivial. Adversaries can also choose from a list of built-in command flags that will\r\nperform various actions, or they can opt to supply their own configuration file and avoid the need to execute with\r\nvarious command line flags. As an example, maybe using a cloud storage provider is not an option because of a\r\ntechnical control that disallows network connections to the adversary’s hosting provider of choice. Rclone makes\r\nit very simple to use file transfer protocols such as FTP or SFTP, effectively enabling adversaries to move files\r\nwherever they want. See the Appendix for a list of known and supported Rclone commands at the end of this\r\nreport.\r\nEstablishing the baseline\r\nAs was the case with MegaSync, understanding the binary metadata associated with Rclone is a necessary first\r\nstep if you want to detect adversaries who rename the tool. Under normal circumstances, you can expect rclone\r\nto have the following attributes:\r\nMetadata attribute Value\r\nMetadata attribute :\r\nProcess name\r\nValue :\r\nrclone.exe\r\nMetadata attribute :\r\nOriginal name\r\nValue :\r\nrclone.exe\r\nMetadata attribute :\r\nDescription\r\nValue :\r\nRsync for cloud storage\r\nMetadata attribute :\r\nInternal name\r\nValue :\r\nrclone\r\nhttps://redcanary.com/blog/rclone-mega-extortion/\r\nPage 8 of 13\n\nMetadata attribute Value\r\nMetadata attribute :\r\nCompany name\r\nValue :\r\nhttps://rclone.org\r\nMetadata attribute :\r\nProduct name\r\nValue :\r\nRclone\r\nOvert use of Rclone\r\nIf Rclone isn’t permitted in your environment, then you can simply look for the execution of a process named\r\nrclone.exe . It’s worth noting that there isn’t any standard path that Rclone executes from, so unfortunately we\r\ncannot pare things down further like we were able to with MegaSync.\r\nRenaming Rclone\r\nRed Canary has observed the execution of renamed versions of Rclone during IR engagements, in an attempt to\r\nbypass basic application controls. Taking this into account, we can begin creating detection analytics for renamed\r\ninstances of Rclone, just as we did with MegaSync.\r\nYou can do so by looking for the execution of a process that is not named rclone.exe but that executes with any\r\nof the following binary metadata:\r\na binary original name that is rclone.exe\r\na binary description that is “Rsync for cloud storage”\r\na binary internal name that is rclone\r\na binary company name that is https://rclone.org\r\na binary product name that is Rclone\r\nThe following image shows the execution of sihosts.exe . However, an examination of binary metadata\r\nrevealed that sihosts.exe was in fact a renamed instance of Rclone:\r\nhttps://redcanary.com/blog/rclone-mega-extortion/\r\nPage 9 of 13\n\nSuspicious command line flags\r\nIn the interest of building resilient detection analytics, it’s worth noting that metadata could be altered in some\r\nway for these binaries, enabling an adversary to circumvent some of the security controls mentioned above.\r\nConsidering that, it’s worth looking out for command line flags that are consistent with suspicious executions of\r\nrclone as well (see Appendix for the list of helpful command line perimeters).\r\nAny time you observe these command line flags in play, it might be time to get your magnifying lens out and dig\r\ninto how Rclone is being used in your environment. Of course, this can differ from one organization to the next. If\r\nyou have approved legitimate use cases for Rclone in your environment, then you may have to tune your analytics\r\naccordingly.\r\nWe’ve had success looking for command lines including one or more of the command line parameters: rclone ,\r\nlsd , remote: , ftp: , mega , --config , --auto-confirm , or   --multi-thread-streams and copy ,\r\nconfig , create , lsd , remote , mega , user , pass , --config , --progress , --no-check-certificate , --ignore-existing , --auto-confirm , --multi-thread-streams` , --transfers , ftp: ,\r\nremote: , or \\\\ .\r\nThe following image shows what some of these command line flags might look like in the wild:\r\nWhile this is a great place to start, the Rclone project is constantly being updated with new functionality, so\r\nkeeping an eye on the ChangeLog and Docs may be helpful when looking for new ways to identify the utility\r\nmoving forward.\r\nRemember: detect or do not detect. There is no try.\r\nhttps://redcanary.com/blog/rclone-mega-extortion/\r\nPage 10 of 13\n\nAppendix\r\nAs promised, the following table includes a list of Rclone commands that may be of particular interest.\r\nFlag Action\r\nFlag:\r\nsync\r\nAction :\r\nSync files to a destination\r\nFlag:\r\ncopy\r\nAction :\r\nCopy files to a destination\r\nFlag:\r\nconfig\r\nAction :\r\nSpecify a configuration file\r\nFlag:\r\ncreate\r\nAction :\r\nCreate a configuration file\r\nFlag:\r\nlsd\r\nAction :\r\nList directories\r\nFlag:\r\nremote\r\nAction :\r\nDefines a remote destination when building a configuration file\r\nhttps://redcanary.com/blog/rclone-mega-extortion/\r\nPage 11 of 13\n\nFlag Action\r\nFlag:\r\nmega\r\nAction :\r\nMega, the cloud provider, defined while building a configuration file\r\nFlag:\r\nuser\r\nAction :\r\nUsername to authenticate to a remote destination\r\nFlag:\r\npass\r\nAction :\r\nPassword to authenticate to a remote destination\r\nFlag:\r\n--config\r\nAction :\r\nSpecifies a configuration file to use in lieu of direct CLI commands\r\nFlag:\r\n--progress\r\nAction :\r\nLists the progress of files being transferred\r\nFlag:\r\n--no-check-certificate\r\nAction :\r\nSkips certificate checks when brokering a network connection\r\nFlag:\r\n--ignore-existing\r\nAction :\r\nIgnores any files that may already exist on a remote destination\r\nFlag:\r\n--auto-confirm\r\nAction :\r\nYes to all confirmation prompts\r\nFlag:\r\n--multi-thread-streams\r\nAction :\r\nDefine the maximum number of streams for transferring files\r\nFlag:\r\n--transfers\r\nAction :\r\nDefines the maximum number of concurrent transfers\r\nFlag: Action :\r\nhttps://redcanary.com/blog/rclone-mega-extortion/\r\nPage 12 of 13\n\nFlag Action\r\nftp: A predefined FTP destination, observed in direct CLI execution\r\nFlag:\r\nremote:\r\nAction :\r\nA predefined remote destination, observed in direct CLI execution\r\nFlag:\r\n\\\\\r\nAction :\r\nNot a flag, but a CLI option consistent with network shares\r\nRelated Articles\r\nSubscribe to our blog\r\nYou'll receive a weekly email with our new blog posts.\r\nSource: https://redcanary.com/blog/rclone-mega-extortion/\r\nhttps://redcanary.com/blog/rclone-mega-extortion/\r\nPage 13 of 13",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE",
		"ETDA"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://redcanary.com/blog/rclone-mega-extortion/"
	],
	"report_names": [
		"rclone-mega-extortion"
	],
	"threat_actors": [],
	"ts_created_at": 1775434311,
	"ts_updated_at": 1775826713,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/70ce53a0f0626a8a36a51e09b8e1ad3585a7c388.pdf",
		"text": "https://archive.orkl.eu/70ce53a0f0626a8a36a51e09b8e1ad3585a7c388.txt",
		"img": "https://archive.orkl.eu/70ce53a0f0626a8a36a51e09b8e1ad3585a7c388.jpg"
	}
}