BitPaymer (FriedEx) coder created by Dridex banker trojan authors
Dridex successfully attacked private users, companies and financial institutions for several years, becoming a nominal category of banking Trojans.
The new ESET study proves that the authors of Dridex are behind another well-known malware family — BitPaymer’s sophisticated coder, which is detected by ESET antivirus products like Win32 / Filecoder.FriedEx and Win64 / Filecoder.FriedEx.
')
The Dridex banking trojan was first discovered in 2014 and was a relatively simple bot created on the basis of older projects. However, the authors quickly turned it into one of the most sophisticated banking Trojans on the market. It seems that the development continues - new versions of the bot with minor corrections and updates are released almost weekly. From time to time there are major updates with new features or significant changes. The latest update from version 3 to version 4 was introduced in early 2017, with the Atom Bombing injection technique introduced. Later in 2017, the authors introduced a new 0-day exploit using a vulnerability in Microsoft Word, which made it possible to cover millions of victims.
At the time of writing this post, the newest version of Dridex 4.80 includes support for web injects 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 banker Trojans, including Dridex.
Originally named BitPaymer (based on text on the site with a ransom demand), the encoder was discovered in early July 2017 by Michael Gillespie . In August, Malvar attracted attention after a successful attack on the institutions of the National Health Service of Scotland.
FriedEx is focused on high-ranking targets and companies, rather than ordinary users, and is usually delivered via RDP brute force. The program encrypts each file using a randomly generated RC4 key, which is then encrypted using a hard-coded 1024-bit RSA public key and stored in the appropriate
In December 2017, we reviewed one of the FriedEx samples and almost immediately found similarities with Dridex. Interested in the discovery, we conducted a detailed study and found out that FriedEx uses the same methods of hiding information about behavior as Dridex.
FriedEx recognizes all system API calls on the fly, searching for them with a hash, stores all strings in an encrypted form, scans keys and registry values ​​with a hash, etc. The resulting binary file is hardly noticeable from the point of view of static properties; finding out what malware does without a more in-depth analysis is problematic.
For this reason, we conducted a further analysis that revealed additional attributes that confirmed suspicions - two families of malicious programs were created by the same developers.
Figure 1. Comparison of the GetUserID function in the Dridex and FriedEx samples - find ten differences
Figure 1 shows the part of the function used to generate the UserID, which can be found in all Dridex binary files (bootloaders and bot modules). The function specific to Dridex is also used in FriedEx binary files. The task of the function is the same - to generate a string from 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 encoder in the case of FriedEx.
Such similarity with Dridex is present in all binary files FriedEx. Only a few functions do not match the Dridex pattern, usually associated with the specific capabilities of the encoder (the encryption cycle and the creation of files with the message of redemption).
Figure 2. Comparison of the order of functions in the Dridex and FriedEx samples. Functions missing 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, in the FriedEx sample some of the functions that are present in the Dridex sample are missing and vice versa, but the order remains the same.
Note: automatic generated pairs of function names based on addresses in the code (
It is worth mentioning that both the 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 to be conclusive evidence.
When creating a Windows executable file, the linker may include a PDB (Program Database) path pointing to a file that contains debugging symbols to help the developer fix bugs and identify failures. In fact, a PDB file is almost never present in malware, since it is a separate file that does not fall into the distribution.
The path can provide valuable information, because PDB files are located by default in the same directory as the compiled executable file, and usually have the same base name followed by the .pdb extension. Logically, the PDB path is usually not included in malware, because the authors do not want to disclose any information. Fortunately, in some samples of Dridex and FriedEx there is a PDB path.
Figure 3. All PDB paths found in the 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 the available malware samples, we concluded that the path
We have several cases of detecting Dridex and FriedEx with the same compilation date. This could be a coincidence, but after closer examination, we excluded such a version.
Moreover, compilations with the same dates differ by several minutes (it can be assumed that the authors of Dridex compiled both projects 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 more 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. The GetAPIByHash function in Dridex samples with a compilation time difference of three days. Selected constants differ
In Figure 4, we compare two Dridex samples 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 the hashes are based on them.
On the other hand, in Figure 5 you can see a comparison of Dridex and FriedEx bootloaders compiled on the same day (the difference in timestamps is two minutes). The constants are the same; this indicates that both samples were created during the same compilation session.
Figure 5. The GetAPIByHash function in binary Dridex and FriedEx files compiled on the same day. Selected constants are identical in both samples.
The compiler information confirms the proofs listed earlier - the Dridex and FriedEx binary files are compiled in Visual Studio 2015. This is confirmed by the linker version 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 similarity with Dridex, we are faced with a previously undocumented 64-bit version of the encoder. Since the usual 32-bit version can be focused on x86 and x64 systems, this sample seems to be quite interesting.
In view of 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 that hackers remain highly active and not only constantly update the banking Trojan (web injection support 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 activities in the near future, will continue to support the old project and, possibly, expand the portfolio with new samples.
For a long time, the Dridex group was considered an “actor of one role” focused on its banking Trojan. Today we found out that this is not the case; hackers easily adapt to new trends and create other types of malware that can compete with the most advanced in their category.
The new ESET study proves that the authors of Dridex are behind another well-known malware family — BitPaymer’s sophisticated coder, which is detected by ESET antivirus products like Win32 / Filecoder.FriedEx and Win64 / Filecoder.FriedEx.
')
Dridex
The Dridex banking trojan was first discovered in 2014 and was a relatively simple bot created on the basis of older projects. However, the authors quickly turned it into one of the most sophisticated banking Trojans on the market. It seems that the development continues - new versions of the bot with minor corrections and updates are released almost weekly. From time to time there are major updates with new features or significant changes. The latest update from version 3 to version 4 was introduced in early 2017, with the Atom Bombing injection technique introduced. Later in 2017, the authors introduced a new 0-day exploit using a vulnerability in Microsoft Word, which made it possible to cover millions of victims.
At the time of writing this post, the newest version of Dridex 4.80 includes support for web injects 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 banker Trojans, including Dridex.
FriedEx
Originally named BitPaymer (based on text on the site with a ransom demand), the encoder was discovered in early July 2017 by Michael Gillespie . In August, Malvar attracted attention after a successful attack on the institutions of the National Health Service of Scotland.
FriedEx is focused on high-ranking targets and companies, rather than ordinary users, and is usually delivered via RDP brute force. The program encrypts each file using a randomly generated RC4 key, which is then encrypted using a hard-coded 1024-bit RSA public key and stored in the appropriate
.readme_txt file.In December 2017, we reviewed one of the FriedEx samples and almost immediately found similarities with Dridex. Interested in the discovery, we conducted a detailed study and found out that FriedEx uses the same methods of hiding information about behavior as Dridex.
FriedEx recognizes all system API calls on the fly, searching for them with a hash, stores all strings in an encrypted form, scans keys and registry values ​​with a hash, etc. The resulting binary file is hardly noticeable from the point of view of static properties; finding out what malware does without a more in-depth analysis is problematic.
For this reason, we conducted a further analysis that revealed additional attributes that confirmed suspicions - two families of malicious programs were created by the same developers.
Code similarities
Figure 1. Comparison of the GetUserID function in the Dridex and FriedEx samples - find ten differences
Figure 1 shows the part of the function used to generate the UserID, which can be found in all Dridex binary files (bootloaders and bot modules). The function specific to Dridex is also used in FriedEx binary files. The task of the function is the same - to generate a string from 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 encoder in the case of FriedEx.
Such similarity with Dridex is present in all binary files FriedEx. Only a few functions do not match the Dridex pattern, usually associated with the specific capabilities of the encoder (the encryption cycle and the creation of files with the message of redemption).
Figure 2. Comparison of the order of functions in the Dridex and FriedEx samples. Functions missing 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, in the FriedEx sample some of the functions that are present in the Dridex sample are missing and vice versa, but the order remains the same.
Note: automatic generated pairs of function names based on addresses in the code (
sub_CA5191 and sub_2A56A2 , etc.) are obviously not the same, but the code to which they refer is the same.It is worth mentioning that both the 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 to be conclusive evidence.
PDB paths
When creating a Windows executable file, the linker may include a PDB (Program Database) path pointing to a file that contains debugging symbols to help the developer fix bugs and identify failures. In fact, a PDB file is almost never present in malware, since it is a separate file that does not fall into the distribution.
The path can provide valuable information, because PDB files are located by default in the same directory as the compiled executable file, and usually have the same base name followed by the .pdb extension. Logically, the PDB path is usually not included in malware, because the authors do not want to disclose any information. Fortunately, in some samples of Dridex and FriedEx there is a PDB path.
Figure 3. All PDB paths found in the 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 the available malware samples, we concluded that the path
S:\Work\_bin\ is unique for the Dridex and FriedEx projects.Timestamps
We have several cases of detecting Dridex and FriedEx with the same compilation date. This could be a coincidence, but after closer examination, we excluded such a version.
Moreover, compilations with the same dates differ by several minutes (it can be assumed that the authors of Dridex compiled both projects 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 more 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. The GetAPIByHash function in Dridex samples with a compilation time difference of three days. Selected constants differ
In Figure 4, we compare two Dridex samples 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 the hashes are based on them.
On the other hand, in Figure 5 you can see a comparison of Dridex and FriedEx bootloaders compiled on the same day (the difference in timestamps is two minutes). The constants are the same; this indicates that both samples were created during the same compilation session.
Figure 5. The GetAPIByHash function in binary Dridex and FriedEx files compiled on the same day. Selected constants are identical in both samples.
Compiler info
The compiler information confirms the proofs listed earlier - the Dridex and FriedEx binary files are compiled in Visual Studio 2015. This is confirmed by the linker version 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 similarity with Dridex, we are faced with a previously undocumented 64-bit version of the encoder. Since the usual 32-bit version can be focused on x86 and x64 systems, this sample seems to be quite interesting.
Conclusion
In view of 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 that hackers remain highly active and not only constantly update the banking Trojan (web injection support 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 activities in the near future, will continue to support the old project and, possibly, expand the portfolio with new samples.
For a long time, the Dridex group was considered an “actor of one role” focused on its banking Trojan. Today we found out that this is not the case; hackers easily adapt to new trends and create other types of malware that can compete with the most advanced in their category.
Indicators of compromise
Win32/Dridex.BE C70BD77A5415B5DCF66B7095B22A0DEE2DDA95A0
Win64/FriedEx.A CF1038C9AED9239B6A54EFF17EB61CAB2EE12141
Win32/FriedEx.A 8AE1C1869C42DAA035032341804AEFC3E7F3CAF1Source: https://habr.com/ru/post/348364/
All Articles