BitPaymer (FriedEx) encoder was created by the authors of the banking Trojan Dridex

    Dridex has successfully attacked private users, companies and financial organizations for several years, becoming a household name for banking Trojans.

    A new ESET study proves that Dridex authors are behind another well-known malware family - the sophisticated BitPaymer encryption, which is detected by ESET's antivirus products like Win32 / Filecoder.FriedEx and Win64 / Filecoder.FriedEx.



    Dridex


    The banking Trojan Dridex was first discovered in 2014 and was a relatively simple bot based on older projects. However, the authors quickly turned it into one of the most complex banking Trojans on the market. It seems that development is ongoing - new versions of the bot with minor corrections and updates are released almost weekly. From time to time, major updates appear with new features or significant changes. The latest update from version 3 to version 4 was introduced at the beginning of 2017, the Atom Bombing injection technique was introduced in it . Later in 2017, the authors introduced a new 0-day exploit that exploits vulnerabilities in Microsoft Word, which has reached millions of victims.

    At the time of writing this post, the latest version of Dridex 4.80 includes support for web injections in Chrome version 63. Dridex 4.80 was released on December 14, 2017.

    Note: last year we released a tool to identify malicious hooks in popular web browsers. The tool is designed to help detect potential infections by banking trojans, including Dridex.

    Friedex


    Originally called BitPaymer (based on the text on the ransom site), the encoder was opened by Michael Gillespie in early July 2017 . In August, the malware attracted attention after a successful attack on the Scottish National Health Service.

    FriedEx is focused on high-level goals and companies, not ordinary users, and is usually delivered via RDP bruteforce. The program encrypts each file with a randomly generated RC4 key, which is then encrypted using a hard-coded 1024-bit RSA public key and stored in the corresponding file .readme_txt.

    In December 2017, we examined one of the FriedEx samples and almost immediately found code similarities with Dridex. Being interested in the find, we conducted a detailed study and found out that FriedEx uses the same methods of concealing information about behavior as Dridex.

    FriedEx “on the fly” recognizes all calls to the system’s API, looking for them using a hash, stores all strings in encrypted form, looks through registry keys and values ​​using a hash, etc. The resulting binary file is hardly noticeable in terms of static properties; finding out what malware does is problematic without a deeper analysis.

    For this reason, we conducted a further analysis, which revealed additional attributes that confirmed suspicions - two families of malware were created by the same developers.

    Code similarities



    Figure 1. Comparison of the GetUserID function in Dridex and FriedEx samples - find ten differences

    . Figure 1 shows part of the function used to generate the UserID, which can be found in all Dridex binaries (boot loaders and bot modules). A function specific to Dridex is also used in FriedEx binaries. The function’s task is the same - to generate a string of several attributes of the victim’s machine, which serves as a unique identifier - in the botnet, if we are talking about Dridex and for the encryptor in the case of FriedEx.

    This similarity with Dridex is present in all FriedEx binaries. Only a few functions do not coincide with the Dridex sample, as a rule related to the specific capabilities of the encoder (encryption cycle and creation of files with a ransom message).


    Figure 2. Comparison of the order of functions in Dridex and FriedEx samples. Functions that are not in another sample are highlighted in color.

    Another common feature is the sequence of functions in binary files, which occurs when the same code base or static library is used in several projects. As we can see in Figure 2, the FriedEx sample lacks some of the functions present in the Dridex sample, and vice versa, but the order remains unchanged.

    Note: Automatically generated a pair of function names, based on addresses in the code ( sub_CA5191and sub_2A56A2etc.), obviously not the same, but the same code to which they refer.

    It is worth mentioning that both Dridex and FriedEx use the same malicious packer. However, this packer is currently extremely popular, which is probably due to its effectiveness in preventing detection and complicating the analysis. It is used in other malware families, including QBot, Emotet, and Ursnif, so we do not consider its presence as conclusive evidence.

    PDB paths


    When creating a Windows executable, the linker may include a PDB (Program Database) path that points to a file that contains debug symbols to help the developer fix errors and identify failures. In fact, a PDB file is almost never present in malware, as it is a separate file that does not fit into the distribution.

    The path can provide valuable information because PDB files are located by default in the same directory as the compiled executable, and usually have the same base name followed by the .pdb extension. It is logical that the PDB path is usually not included in malware, because the authors do not want to disclose any information. Fortunately, some Dridex and FriedEx samples have a PDB path.


    Figure 3. All PDB paths found in Dridex and FriedEx projects

    As you can see in Figure 3, the binary files of both projects are collected in the same directory. Based on a search in the metadata of available malware samples, we came to the conclusion that the path S:\Work\_bin\is unique to the Dridex and FriedEx projects.

    Time stamps


    We have several instances of detecting Dridex and FriedEx with the same compilation date. This might be a coincidence, but after closer examination, we ruled out such a version.

    Not only do compilations with the same dates differ by a few minutes (it can be assumed that Dridex authors both compiled at the same time), but the randomly generated constants in these samples are also identical. Constants change in each compilation as a form of polymorphism to make analysis difficult and to help avoid detection. This can be completely randomized at each compilation or based on some variable, such as the current date.


    Figure 4. GetAPIByHash function in Dridex samples with a compilation time difference of three days. Selected constants vary

    In Figure 4, we compare two samples of the Dridex bootloader with a three-day compile-time difference. Loaders are almost identical, the only difference is hard-coded data, such as encryption keys and IP addresses of C & C servers. In this case, the constants are different, and therefore all hashes are based on them.

    On the other hand, in Figure 5 you can see a comparison of the Dridex and FriedEx bootloaders compiled in one day (the timestamp difference is two minutes). The constants are the same, which indicates that both samples were created during the same compilation session.


    Figure 5. The GetAPIByHash function in the Dridex and FriedEx binaries compiled in one day. The selected constants are identical in both samples.

    Compiler Information


    The compiler information confirms the evidence listed earlier — the Dridex and FriedEx binaries were compiled in Visual Studio 2015. This confirms the version of the linker found in the PE header and the Rich Header data.


    Figure 6. Rich header data in Dridex and FriedEx samples

    In addition to the obvious similarities with Dridex, we came across a previously undocumented 64-bit version of the encoder. Since the regular 32-bit version can be oriented to x86 and x64 systems, this sample is quite interesting.

    Conclusion


    Based on the above evidence, we believe that FriedEx is the work of the creators of Dridex. This discovery gives us a more complete picture of the activities of the cyber group - we found out that hackers remain highly active and not only constantly update the banking trojan (support for web injection for the latest versions of Chrome or the introduction of new features, including Atom Bombing), but also follow the latest trends by creating your own encoder.

    It is difficult to predict the future, but we believe that the Dridex group is not going to curtail its activities in the near future, will continue to support the old project and, possibly, expand the portfolio with the help of new samples.

    For a long time, Dridex was considered a “single-role actor,” focused on its banking Trojan. Today we found out that this is not so; hackers easily adapt to new trends and create other types of malware that can compete with the most advanced in their category.

    Compromise indicators


    Win32/Dridex.BE C70BD77A5415B5DCF66B7095B22A0DEE2DDA95A0
    Win64/FriedEx.A CF1038C9AED9239B6A54EFF17EB61CAB2EE12141
    Win32/FriedEx.A 8AE1C1869C42DAA035032341804AEFC3E7F3CAF1

    Also popular now: