SINGAPORE, 29 January 2018 – 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.
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 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.
Dridex
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.
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.
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.
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.
FriedEx
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.
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.
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, thanks to our long-term research of its developments. 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.
of the FriedEx samples and almost instantly noticed the resemblance of the code
to Dridex, thanks to our long-term research of its developments. 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.
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.
revealed a number of additional attributes that confirmed our initial
suspicions – the two malware families were created by the same developers.
Code
Similarities
Similarities
Figure 1. Comparison
of GetUserID function present in both Dridex and FriedEx samples
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.
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!
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).
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.
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.
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.
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.
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
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.
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.
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
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.
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.
Timestamps
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.
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.
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.
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.
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.
GetAPIByHash function in Dridex and FriedEx binaries compiled the same day. The
highlighted constant is the same in both samples.
Compiler
information
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.
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
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.
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.
Conclusion
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.
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.
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.
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.
###
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 and mobile security, to encryption and two-factor authentication,
ESET’s high-performing, easy-to-use products give consumers 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 centers worldwide,
ESET becomes the first IT security company to earn 100 Virus Bulletin VB100 awards,
identifying every single “in-the-wild” malware without interruption since 2003.
For more information visit www.eset.com or follow us on LinkedIn, Facebook and Twitter.
services for businesses and consumers worldwide. With solutions ranging
from endpoint and mobile security, to encryption and two-factor authentication,
ESET’s high-performing, easy-to-use products give consumers 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 centers worldwide,
ESET becomes the first IT security company to earn 100 Virus Bulletin VB100 awards,
identifying every single “in-the-wild” malware without interruption since 2003.
For more information visit www.eset.com or follow us on LinkedIn, Facebook and Twitter.
For the LATEST tech updates,
FOLLOW us on our Twitter
LIKE us on our FaceBook
SUBSCRIBE to us on our YouTube Channel!
