{
	"id": "bafdad37-adf7-447f-8af4-f820df8e7cc7",
	"created_at": "2026-04-06T00:08:54.418442Z",
	"updated_at": "2026-04-10T03:20:38.218253Z",
	"deleted_at": null,
	"sha1_hash": "d3295ede58dd63a3548784896391e114ce24dd77",
	"title": "FriedEx: BitPaymer ransomware the work of Dridex authors",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 210239,
	"plain_text": "FriedEx: BitPaymer ransomware the work of Dridex authors\r\nBy Michal Poslušný\r\nArchived: 2026-04-05 13:20:15 UTC\r\nDridex has been a nightmare for computer users, companies and financial institutions for several years now, so\r\nmuch so that for many, it has become the first thing that comes to mind when talking about banking trojans.\r\nRecent ESET research shows that the authors of the infamous Dridex banking trojan are also behind another high-profile malware family – a sophisticated ransomware detected by ESET products as Win32/Filecoder.FriedEx and\r\nWin64/Filecoder.FriedEx, and also known as BitPaymer.\r\nDridex\r\nThe Dridex banking trojan first appeared in 2014 as a relatively simple bot inspired by older projects, but the\r\nauthors quickly turned this bot into one of the most sophisticated banking trojans on the market. The development\r\nseems to be steady, with new versions of the bot including minor fixes and updates being released on a weekly\r\nbasis, with occasional breaks. From time to time, the authors introduce a major update that adds some crucial\r\nfunctionality or larger changes. The last major update from version 3 to version 4, released at the beginning of\r\n2017, gained attention for adopting the Atom Bombing injection technique, and later in the year also introducing a\r\nnew MS Word zero-day exploit, which helped spread the trojan to millions of victims.\r\nAs of this writing, the most recent version of Dridex is 4.80 and includes support for webinjects into Chrome\r\nversion 63. Dridex 4.80 was released on December 14th 2017.\r\nNote: Last year we released a tool that helps identify malicious hooks in popular web browsers. The tool is\r\ndesigned to help incident responders discover potential banking trojan infections, including Dridex.\r\nFriedEx\r\nInitially dubbed BitPaymer, based on text in its ransom demand web site, this ransomware was discovered in early\r\nJuly 2017 by Michael Gillespie. In August, it returned to the spotlight and made headlines by infecting NHS\r\nhospitals in Scotland.\r\nFriedEx focuses on higher profile targets and companies rather than regular end users and is usually delivered via\r\nan RDP brute force attack. The ransomware encrypts each file with a randomly generated RC4 key, which is then\r\nencrypted using a hardcoded 1024-bit RSA public key and saved in the corresponding .readme_txt file.\r\nIn December 2017, we took a closer look at one of the FriedEx samples and almost instantly noticed the\r\nresemblance of the code to Dridex. Intrigued by the initial findings, we dug deep into the FriedEx samples, and\r\nfound out that FriedEx uses the same techniques as Dridex to hide as much information as possible about its\r\nbehavior.\r\nhttps://www.welivesecurity.com/2018/01/26/friedex-bitpaymer-ransomware-work-dridex-authors/\r\nPage 1 of 7\n\nIt resolves all system API calls on the fly by searching for them by hash, stores all strings in encrypted form, looks\r\nup registry keys and values by hash, etc. The resulting binary is very low profile in terms of static features and it’s\r\nvery hard to tell what the malware is doing without a deeper analysis.\r\nThis prompted yet further analysis, which revealed a number of additional attributes that confirmed our initial\r\nsuspicions – the two malware families were created by the same developers.\r\nCode Similarities\r\nFigure 1. Comparison of GetUserID function present in both Dridex and FriedEx samples\r\nIn Figure 1, we can see a part of a function used for generating UserID that can be found across all Dridex\r\nbinaries (both loaders and bot modules). As we can see, the very same Dridex-specific function is also used in the\r\nFriedEx binaries. The function produces the same results – it generates a string from several attributes of the\r\nhttps://www.welivesecurity.com/2018/01/26/friedex-bitpaymer-ransomware-work-dridex-authors/\r\nPage 2 of 7\n\nvictim’s machine that serves as a unique identifier of the given victim, either in the botnet in the case of Dridex, or\r\nof the ransomware with FriedEx. Indeed, the screenshots would make for a good “Spot the difference” game!\r\nThis kind of similarity to Dridex is present throughout the FriedEx binaries and only very few functions that\r\nmostly correspond to the specific ransomware functionality are not found in the Dridex sample (i.e. the file\r\nencryption loop and creation of ransom message files).\r\nFigure 2. Comparison of function order in Dridex and FriedEx samples. Functions that are missing in the other\r\nsample are highlighted in the corresponding color\r\nAnother shared feature is the order of the functions in the binaries, which occurs when the same codebase or static\r\nlibrary is used in multiple projects. As we can see in Figure 2, while the FriedEx sample seems to be missing some\r\nof the functions present in the Dridex sample and vice versa (which is caused by the compiler omitting\r\nunreferenced/unused functions), the order remains the same.\r\nNote: Auto-generated function name pairs, based on code addresses (sub_CA5191 and sub_2A56A2, etc),\r\nobviously do not match, but the code they refer to does.\r\nIt’s also worth mentioning that both Dridex and FriedEx use the same malware packer. However, since the packer\r\nis very popular nowadays (probably due to its effectiveness in avoiding detection and hampering analysis) and\r\nused by other well-known families like QBot, Emotet or Ursnif, we don’t really consider that alone strong\r\nevidence.\r\nPDB paths\r\nhttps://www.welivesecurity.com/2018/01/26/friedex-bitpaymer-ransomware-work-dridex-authors/\r\nPage 3 of 7\n\nWhen building a Windows executable, the linker may include a PDB (Program Database) path pointing to a file\r\nthat contains debug symbols that help the developer with debugging and identifying crashes. The actual PDB file\r\nis almost never present in malware, because it’s a separate file that doesn’t get into distribution. However,\r\nsometimes even just the path, if included, can provide valuable information, because PDB files are located in the\r\nsame directory as the compiled executable by default and usually also have the same base name followed by the\r\n.pdb extension.\r\nAs one might guess, PDB paths are not included in malware binaries very often, as the attackers don’t want to\r\ngive away any information. Fortunately, some samples of both families do include PDB paths.\r\nFigure 3. List of all PDB paths found in the Dridex and FriedEx projects\r\nAs you can see in Figure 3, the binaries of both projects are being built in the same, distinctively named directory.\r\nBased on a search across all of our malware sample metadata, we have concluded that the path S:\\Work\\_bin\\ is\r\nunique to the Dridex and FriedEx projects.\r\nTimestamps\r\nWe found several cases of Dridex and FriedEx with the same date of compilation. This could, of course, be\r\ncoincidence, but after a closer look, we quickly ruled out the “just a coincidence” theory.\r\nNot only do the compilations with the same date have time differences of several minutes at most (which implies\r\nDridex guys probably compile both projects concurrently), but the randomly generated constants are also identical\r\nin these samples. These constants change with each compilation as a form of polymorphism, to make the analysis\r\nharder and to help avoid detection.\r\nThis might be completely randomized in each compilation or based on some variable like the current date.\r\nhttps://www.welivesecurity.com/2018/01/26/friedex-bitpaymer-ransomware-work-dridex-authors/\r\nPage 4 of 7\n\nFigure 4. GetAPIByHash function in Dridex samples with compilation time difference of 3 days. The highlighted\r\nconstant is different\r\nIn Figure 4, we have the comparison of two Dridex loader samples with a three-day difference between\r\ncompilation timestamps. While the loaders are almost identical with the only difference being their hardcoded\r\ndata, such as encryption keys and C\u0026C IPs, the constants are different, and so are all the hashes that are based on\r\nthem. On the other hand, in Figure 5, we can see the comparison of the FriedEx and Dridex loader from the same\r\nday (in fact, with timestamps just two minutes apart). Here, the constants are the same, meaning both were\r\nprobably built during the same compilation session.\r\nFigure 5. GetAPIByHash function in Dridex and FriedEx binaries compiled the same day. The highlighted\r\nconstant is the same in both samples\r\nCompiler information\r\nhttps://www.welivesecurity.com/2018/01/26/friedex-bitpaymer-ransomware-work-dridex-authors/\r\nPage 5 of 7\n\nThe compiler information only further supports all the evidence we found so far – the binaries of both Dridex and\r\nFriedEx are compiled in Visual Studio 2015. This is confirmed by both the linker version found in the PE Header\r\nand Rich Header data.\r\nFigure 6. Rich header data found in Dridex and FriedEx samples\r\nApart from the obvious similarities with Dridex, we came across a previously unreported 64-bit variant of the\r\nransomware. As the usual 32-bit version of the ransomware can target both x86 and x64 systems, we consider this\r\nvariant to be a bit of a curiosity.\r\nConclusion\r\nWith all this evidence, we confidently claim that FriedEx is indeed the work of the Dridex developers. This\r\ndiscovery gives us a better picture of the group’s activities – we can see that the group continues to be active and\r\nnot only consistently updates their banking trojan to maintain its webinject support for the latest versions of\r\nChrome and to introduce new features like Atom Bombing, but that it also follows the latest malware “trends”,\r\ncreating their own ransomware.\r\nWe can only guess what the future will bring, but we can be sure that the Dridex gang isn’t going anywhere\r\nanytime soon and that they will keep innovating their old project and possibly extend their portfolio with a new\r\npiece here and there.\r\nFor a long time, it was believed that the Dridex gang was a one-trick pony that kept their focus on their banking\r\ntrojan. We have now found that this is not the case and that they can easily adapt to the newest trends and create a\r\ndifferent kind of malware that can compete with the most advanced in its category.\r\nIoCs\r\nWin32/Dridex.BE C70BD77A5415B5DCF66B7095B22A0DEE2DDA95A0\r\nWin64/FriedEx.A CF1038C9AED9239B6A54EFF17EB61CAB2EE12141\r\nWin32/FriedEx.A 8AE1C1869C42DAA035032341804AEFC3E7F3CAF1\r\nhttps://www.welivesecurity.com/2018/01/26/friedex-bitpaymer-ransomware-work-dridex-authors/\r\nPage 6 of 7\n\nSource: https://www.welivesecurity.com/2018/01/26/friedex-bitpaymer-ransomware-work-dridex-authors/\r\nhttps://www.welivesecurity.com/2018/01/26/friedex-bitpaymer-ransomware-work-dridex-authors/\r\nPage 7 of 7",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA",
		"Malpedia"
	],
	"references": [
		"https://www.welivesecurity.com/2018/01/26/friedex-bitpaymer-ransomware-work-dridex-authors/"
	],
	"report_names": [
		"friedex-bitpaymer-ransomware-work-dridex-authors"
	],
	"threat_actors": [],
	"ts_created_at": 1775434134,
	"ts_updated_at": 1775791238,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/d3295ede58dd63a3548784896391e114ce24dd77.pdf",
		"text": "https://archive.orkl.eu/d3295ede58dd63a3548784896391e114ce24dd77.txt",
		"img": "https://archive.orkl.eu/d3295ede58dd63a3548784896391e114ce24dd77.jpg"
	}
}