Skip to content



Ransomware – a term that we were already aware of a few years ago but most of us rather took it as a “not-our-problem” kind of thing. However, cybercriminals didn’t see it the same way and it was just a matter of time before that kind of extortionate vermin came to do harm in our land, too. And even though the attacks on Benešov Hospital and OKD were not among the first ones, their coverage definitely raised awareness of the topic. Then, the emergence of coronavirus has actually created new opportunities of phishing and ransomware campaigns for cybercriminals; hugely supported by the massive transition of office workers to home office.
There have been many confirmed cyber attacks just in Czechia in the past three months (the real number of organizations that fell victim to a cyber attack in Czechia is likely to be higher but not all the information gets published): Prague Castle AdministrationUniversity Hospital BrnoPsychiatric Hospital Kosmonosy, Vltava River Basin Management and Prague 3 City District Administration. Recently, having its branches in Czechia, the medical company Fresenius has also been attacked.
Now that the topic of cybercriminals and the possibilities of protection against them gets more publicity, it could come in useful to refresh a few rules which may significantly minimize the risk of an attack on your infrastructure. I’m going to try to summarize them in this article without getting too technical and complex so that anybody can understand. Hopefully, successfully 🙂

Rule number 1
Don’t try to find a single solution to the whole area of cyber security – there’s nothing like a “Silver Bullet” or “Holy Grail” (i.e. a single “cover-it-all” or “save-it-all”) solution. Simply not. Just as in cars, with a lot of various features that increase the safety (the sole car construction ensures passive safety, then there are the safety belts, airbags, ABS and other electronic systems), it’s their combination that will make you more likely to survive an accident, or get away without getting injured. The same applies to cyber security – it takes various “layers” of security and their correct combination to ensure the maximum degree of protection.

Rule number 2
Use up-to-date versions of operating systems and update them regularly – those “once-in-a-blue-moon” updates leave enough space for an attacker to use unpatched flaws to penetrate your infrastructure. If, for some serious reason, you really have to use operating systems after they expire (i.e. their developer doesn’t issue updates anymore), at least reserve a separate segment in the network for such devices and take special care of them; however, it’s definitely better not to have such devices in the infrastructure at all. Don’t forget to regularly update any other software you use – as well as an out-of-date operating system this can also lead to the infection of your infrastructure.

Rule number 3
Use good-quality antivirus solution. Current antivirus software includes a lot of security mechanisms and their scope is rather vast so they will help you prevent plenty of problems. Nevertheless, the same rule as with operating systems applies here – update, update, update!

Rule number 4
Don’t trust the “experts” who claim that it’s enough to use common sense, not to open suspicious attachments and to behave sensibly “on the web” to prevent the infection – that’s not true anymore. Modern malware can exploit unpatched flaws not only in operating systems, but also in applications, etc., and it can use them to get into your infrastructure without you performing an action knowingly (such as opening an email attachment).

Rule number 5
Even your firewall and network elements deserve your attention and regular updates. After all, firewall or routers are also computers, i.e. hardware, which run some specialized software. And as it’s generally known and the experience has confirmed that there’s a flaw in every kind of software, it’s vital to update such devices regularly, too. If you don’t do so, you open yet another route into your infrastructure for attackers, just as we showed in practice at our conference GREYCORTEX DAY, where we demonstrated an attack on a typical network infrastructure live.

Rule number 6
Unless necessary, don’t work within the administrator account. It’s not really needed for regular work and if an attacker breaks through the security of the device you’re logged on as an admin (most probably unnecessarily), you’ll make their efforts much easier as well as their way to your data (and possibly money).

Rule number 7
If you use any kind of remote desktop at work, don’t leave it on, nor permanently open to the Internet, as it’s often the target of initial stages of an attack and you practically leave the door to your infrastructure open. In general, be careful how your colleagues or suppliers working remotely connect and which permissions they have, which parts of the infrastructure they can access and how their connection to internal tools is secured. All this is linked to the following rule:

Rule number 8
Use VPN only (Virtual Private Network) for external connection to the internal network. If you allow direct connection from the outside without using VPN, sooner or later, some attacker will abuse it. Don’t forget to cancel disused VPN accounts as there’s always the danger of abuse of a long-forgotten access. This applies in general – if you grant anyone access to anywhere and they don’t need it for work anymore, cancel it.

Rule number 9
Divide the visitor (i.e. publicly accessible) and internal / production parts of infrastructure thoroughly and consistently. This doesn’t only apply on guest Wi-Fi, but any part of the infrastructure which can be freely accessed by unknown persons. A lot of attacks on internal infrastructure start by a “visit” of an unwelcome guest from the publicly accessible part of the network.

Rule number 10
Cybercriminals keep improving and coming up with new ways how to convey harmful code to you and your colleagues, so it’s useful to get informed regularly on new ways how someone might try to trick you (or make you do something that will spread the infection) and on new dangers. It’s definitely not a waste of time or money to take part in an interesting conference on such a topic or get regular training from companies that focus on prevention. You’d have to invest a lot more time and money in removing the consequences of actions of unknowing employees. Unfortunately, the human factor will always be the weakest link in the chain of cyber security, so it pays to regularly raise awareness of what may happen.

Rule number 11
If your colleagues work within your infrastructure on their own devices (so called BYOD, Bring Your Own Device), it’s necessary to count on the fact that you’ll have to apply all the mentioned rules on such devices, which is rather a big problem. One of the possible solutions is granting these devices access only to a certain segment of the infrastructure, secure it properly and monitor, which may obviously be quite strenuous.

Rule number 12
If I don’t understand something, I can’t deal with it. If you don’t have sufficient insight into the whole infrastructure and you don’t have the possibility to monitor what’s going on in it, the attacker is invisible to you and you’re practically blind (until the attack shows in its full extent, i.e. in case of ransomware data encryption). That’s why it’s convenient to use the NTA solution (Network Traffic Analysis), such as our solution GREYCORTEX MENDEL. These tools will not only allow you to see (to the tiniest detail) which devices there are in your network and what’s going on in them, but they will also enable you to get timely notifications in case there’s a suspicious and dishonest activity in the infrastructure thanks to the automatic analysis of the entire network performance and running event correlation (if you’re interested in more information, you’ll find it here). Obviously, it’s necessary to process such notifications and secure a remedy to the flaws found, but that’s well beyond this article. If there isn’t an internal department dealing with cyber security, you can get the SOC services (Security Operations Centre) at some of our partners and leave this burden with them. You’ll appreciate the NTA solution especially in case the attacker manages to disable your antivirus solution or to get through your firewall (e.g. by hiding illegitimate, harmful traffic inside the legitimate traffic and thus trick the firewall), as they can’t hide the signs of harmful behaviour from permanent analysis of network traffic. What’s more – the NTA solution will help you with forensic analysis, i.e. subsequent investigation, of where the attack came from or how the infection got inside your infrastructure, which will help you detect and remove weak spots in security.


  • It’s fully passive and it analyses the mirror of all your network traffic – it can basically monitor everything but at the same time it’s invisible to cybercriminals, they don’t know that you know about them and their activities.
  • It doesn’t send any data “home” for analysis (manual analysis by an army of analysts), but analyses everything using machine learning and other advanced methods.
  • Unlike us, people, it works 24/7/365 (plus one extra day in leap years) and it never gets tired.

You’ll find practical demos how GREYCORTEX MENDEL helps increase cyber security here.

Rule number 13
Back up, back up and back up again! Ideally, make backups on exchangeable media and take them physically away from your company’s premises (you’ll ensure continuity of work in case of fire, flood or mobilisation by doing so :), but mainly, you’ll make sure that in case of ransomware attack the backups in the same infrastructure won’t be encrypted. If, for some reason, it’s not possible or convenient to take away backups physically, make sure the servers with back-up copies aren’t connected to your infrastructure permanently and thus inaccessible to the attackers in time of an ongoing attack – otherwise they’ll encrypt even these backups and there won’t be anywhere to recover the data from.

And finally, the last rule: Even following all the above-mentioned rules may not ensure 100 % protection against an attack of your infrastructure as present cybercriminals are no “greasy teenagers” who want to prove themselves anymore, but professional groups with huge budgets and possibilities.

But if you stick to all of the above-mentioned, you’ll at least make their attempt to launch an attack immensely difficult, and because they know that the effort must be smaller than the possible profit (for their “business” to make sense), it’s highly probable they’ll attack somebody else instead, someone who’s an easier target not having followed the rules.

FriedEx: BitPaymer ransomware the work of Dridex authors

Dridex has been a nightmare for computer users, companies and financial institutions for several years now, so much so that for many, it has become the first thing that comes to mind when talking about banking trojans.

Recent 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 Win64/ Filecoder.FriedEx, and also known as BitPaymer.


The Dridex banking trojan first appeared in 2014 as a relatively simple bot inspired by older projects, but the authors quickly turned this bot into one of the most sophisticated banking trojans on the market. The development seems to be steady, with new versions of the bot including minor fixes and updates being released on a weekly basis, with occasional breaks. From time to time, the authors introduce a major update that adds some crucial functionality or larger changes. The last major update from version 3 to version 4, released at the beginning of 2017, gained attention for adopting the Atom Bombing injection technique, and later in the year also introducing a new MS Word zero-day exploit, which helped spread the trojan to millions of victims.

As of this writing, the most recent version of Dridex is 4.80 and includes support for webinjects into Chrome version 63. Dridex 4.80 was released on December 14th 2017.

Note: Last year we released a tool that helps identify malicious hooks in popular web browsers. The tool is designed to help incident responders discover potential banking trojan infections, including Dridex.


Initially dubbed BitPaymer, based on text in its ransom demand web site, this ransomware was discovered in early July 2017 by Michael Gillespie. In August, it returned to the spotlight and made headlines by infecting NHS hospitals in Scotland.

FriedEx focuses on higher profile targets and companies rather than regular end users and is usually delivered via an RDP brute force attack. The ransomware encrypts each file with a randomly generated RC4 key, which is then encrypted using the hardcoded 1024-bit RSA public key and saved in the corresponding .readme_txt file.

In December 2017, we took a closer look at one of the FriedEx samples and almost instantly noticed the resemblance of the code to Dridex. Intrigued by the initial findings, we dug deep into the FriedEx samples, and found out that FriedEx uses the same techniques as Dridex to hide as much information about its behavior as possible.

It resolves all system API calls on the fly by searching for them by hash, stores all strings in encrypted form, looks up registry keys and values by hash, etc. The resulting binary is very low profile in terms of static features and it’s very hard to tell what the malware is doing without a deeper analysis.

This prompted yet further analysis, which revealed a number of additional attributes that confirmed our initial suspicions – the two malware families were created by the same developers.

Code Similarities

Figure 1. Comparison of GetUserID function present in both Dridex and FriedEx samples

In Figure 1, we can see a part of a function used for generating UserID that can be found across all Dridex binaries (both loaders and bot modules). As we can see, the very same Dridex-specific function is also used in the FriedEx binaries. The function produces the same results – it generates a string from several attributes of the victim’s machine that serves as a unique identifier of the given victim, either in the botnet in the case of Dridex, or of the ransomware with FriedEx. Indeed, the screenshots would make for a good “Spot the difference” game!

This kind of similarity to Dridex is present throughout the FriedEx binaries and only very few functions that mostly correspond to the specific ransomware functionality are not found in the Dridex sample (i.e. the file encryption loop and creation of ransom message files).

 Figure 2. Comparison of function order in Dridex and FriedEx samples. 
Functions that are missing in the other sample are highlighted in the corresponding color

Another shared feature is the order of the functions in the binaries, which occurs when the same codebase or static library is used in multiple projects. As we can see in Figure 2, while the FriedEx sample seems to be missing some of the functions present in the Dridex sample and vice versa (which is caused by the compiler omitting unreferenced/unused functions), the order remains the same.

Note: Auto-generated function name pairs, based on code addresses (sub_CA5191 and sub_2A56A2, etc), obviously do not match, but the code they refer to does.

It’s also worth mentioning that both Dridex and FriedEx use the same malware packer. However, since the packer is very popular nowadays (probably due to its effectiveness in avoiding detection and hampering analysis) and used by other well-known families like QBot, Emotet or Ursnif, we don’t really consider that alone strong evidence.

PDB paths

When building a Windows executable, the linker may include a PDB (Program Database) path pointing to a file that contains debug symbols that help the developer with debugging and identifying crashes. The actual PDB file is almost never present in malware, because it’s a separate file that doesn’t get into distribution. However, sometimes even just the path, if included, can provide valuable information, because PDB files are located in the same directory as the compiled executable by default and usually also have the same base name followed by the .pdb extension.

As one might guess, PDB paths are not included in malware binaries very often, as the attackers don’t want to give away any information. Fortunately, some samples of both families do include PDB paths.

Figure 3. List of all PDB paths found in the Dridex and FriedEx projects

As you can see in Figure 3, the binaries of both projects are being built in the same, distinctively named directory. Based on a search across all of our malware sample metadata, we have concluded that the path S:Work_bin is unique to the Dridex and FriedEx projects.


We found several cases of Dridex and FriedEx with the same date of compilation. This could, of course, be coincidence, but after a closer look, we quickly ruled out the “just a coincidence” theory.

Not only do the compilations with the same date have time differences of several minutes at most (which implies Dridex guys probably compile both projects concurrently), but the randomly generated constants are also identical in these samples. These constants change with each compilation as a form of polymorphism, to make the analysis harder and to help avoid detection.

This might be completely randomized in each compilation or based on some variable like the current date.

Figure 4. GetAPIByHash function in Dridex samples with compilation time difference of 3 days. The highlighted constant is different

In Figure 4, we have the comparison of two Dridex loader samples with a three-day difference between compilation timestamps. While the loaders are almost identical with the only difference being their hardcoded data, such as encryption keys and C&C IPs, the constants are different, and so are all the hashes that are based on them. On the other hand, in Figure 5, we can see the comparison of the FriedEx and Dridex loader from the same day (in fact, with timestamps just two minutes apart). Here, the constants are the same, meaning both were probably built during the same compilation session.

Figure 5. GetAPIByHash function in Dridex and FriedEx binaries compiled the same day. 
The highlighted constant is the same in both samples

Compiler information

The compiler information only further supports all the evidence we found so far – the binaries of both Dridex and FriedEx are compiled in Visual Studio 2015. This is confirmed by both the linker version found in the PE Header and Rich Header data.

Figure 6. Rich header data found in Dridex and FriedEx samples

Apart from the obvious similarities with Dridex, we came across a previously unreported 64-bit variant of the ransomware. As the usual 32-bit version of the ransomware can target both x86 and x64 systems, we consider this variant to be a bit of a curiosity.


With all this evidence, we confidently claim that FriedEx is indeed the work of the Dridex developers. This discovery gives us a better picture of the group’s activities – we can see that the group continues to be active and not only consistently updates their banking trojan to maintain its webinject support for the latest versions of Chrome and to introduce new features like Atom Bombing, but that it also follows the latest malware “trends”, creating their own ransomware.

We can only guess what the future will bring, but we can be sure that the Dridex gang isn’t going anywhere anytime soon and that they will keep innovating their old project and possibly extend their portfolio with a new piece here and there.

For a long time, it was believed that the Dridex gang was a one-trick pony that kept their focus on their banking trojan. We have now found that this is not the case and that they can easily adapt to the newest trends and create a different kind of malware that can compete with the most advanced in its category.


Win32/Dridex.BE C70BD77A5415B5DCF66B7095B22A0DEE2DDA95A0

Win64/FriedEx.A CF1038C9AED9239B6A54EFF17EB61CAB2EE12141

Win32/FriedEx.A 8AE1C1869C42DAA035032341804AEFC3E7F3CAF1

About Version 2 Limited
Version 2 Limited is one of the most dynamic IT companies in Asia. The company develops and distributes IT products for Internet and IP-based networks, including communication systems, Internet software, security, network, and media products. Through an extensive network of channels, point of sales, resellers, and partnership companies, Version 2 Limited offers quality products and services which are highly acclaimed in the market. Its customers cover a wide spectrum which include Global 1000 enterprises, regional listed companies, public utilities, Government, a vast number of successful SMEs, and consumers in various Asian cities.

About ESET
For 30 years, ESET® has been developing industry-leading IT security software and services for businesses and consumers worldwide. With solutions ranging from endpoint security to encryption and two-factor authentication, ESET’s high-performing, easy-to-use products give individuals and businesses the peace of mind to enjoy the full potential of their technology. ESET unobtrusively protects and monitors 24/7, updating defenses in real time to keep users safe and businesses running without interruption. Evolving threats require an evolving IT security company. Backed by R&D facilities worldwide, ESET became the first IT security company to earn 100 Virus Bulletin VB100 awards, identifying every single “in-the-wild” malware without interruption since 2003.