When we look at a prevalent malware family, we give credit to its authors regarding the established malicious infrastructure. New malicious activity is flowing smoothly, command-and-control servers appear, everything works like Swiss watch. Are there any weak points in such a construction?
To answer this question we may think about a race car. It’s a masterpiece crafted for maximum speed, however, the more speed it has, the less chances it has to make a sharp turn. Malware infrastructure has the same weakness of inertia. When every joint works fine, you should have a strong reason to change something in it.
We can use it for our benefit just like movie detectives do. Take a city map, mark the spots of previous crimes ─ and you will likely understand the pattern and even get a probable place of next crime activity, it will likely follow the determined template. In this research we show how to transform these actions to the world of malware. We take one of the most prevalent contemporary botnets called Dridex, mark its previous crime scenes, build the map and draw conclusions helping us to catch the next strike. We show evidence of success of such an approach measured in strict numbers and explain how to use this idea in other real world cases.
The Dridex Banking Trojan first appeared in 2014 and is still one of the most prevalent malware families. In March 2020, Dridex topped the list of most wanted malware.
Dridex was created by a cyber-crime group called “Evil Corp” which has caused an estimated damage of $100 million to the banking system worldwide. A lot of research has been issued already covering different aspects of the malware details and how the cyber-crime group functions.
In this article we provide a summary of key details known about Dridex to date. We explore pre-history of Dridex development, give an overview and show its key technical features and methods of spreading. We explain how we can intercept this malware at the earliest stages of the infection chain. We also provide graphs that show evidence of the success of our approach and how our customers are protected against this malware.
Dridex has a famous lineage. Let’s take a step back in history to find out more about the time period when its earliest version appeared.
The key names in this story:
Zeus is a Trojan Horse malware. Its capabilities include turning an infected machine into a botnet node, stealing banking credentials, downloading and executing separate malicious modules. The members of cyber crime group attempted to steal around 220 million USD worldwide utilizing ZeuS according to FBI investigation.
The timeline below shows key points in ZeuS evolution:
Figure 1 – Chronology of ZeuS evolution.
When ZeuS source code was leaked in 2011, various branches of this malware started to appear. It was very popular malware and gave rise to lots of different malware branches. ZeuS versions may be in a ZeuS online museum. At the time of this writing, ZeuS was associated with 29 different malware families, featuring around 490 versions in total.
In May 2014, the FBI issued a bulletin with description of Evgeniy Bogachev and the promised reward of 3 million USD “for information leading to the arrest and/or conviction.”
Figure 2 – Description of Evgeniy Bogachev on the FBI site.
After the botnets of direct ZeuS successors were taken down, Dridex’s time came. This malware is a result of Bugat evolution (which appeared in 2010). Bugat v5 was recognized as Dridex in 2014.
More names appear on the stage at this time.
More names connected to Dridex can be found in US treasury sanctions statement.
The timeline below shows some milestones in Dridex evolution:
Figure 3 – Chronology of Dridex evolution.
Dridex in turn gave rise to a number of ransomwares starting with Bitpaymer in 2017. This branch continued with DoppelPaymer, which was developed in 2019, and WastedLocker, which was developed in 2020.
In 2019, Dridex had at least 14 active botnets, some of which had already been spotted previously, and others newly developed. Botnets are differentiated by their ID numbers. These are among the most active at this time: 10111, 10222, 10444, 40200, 40300.
At the end of 2019, the FBI issued a bulletin with a description of the author of Dridex and a promised reward of 5 million USD (compared with 3 million USD previously for E. Bogachev).
Figure 4 – Description of Maksim Yakubets on the FBI site.
There is also evidence of Maksim’s luxurious lifestyle, undoubtedly due to income from his malicious activities.
Figure 5 – Cars, girls, money; the luxurious lifestyle of Maksim Yakubets.
To date, Maksim Yakubets has not been apprehended by law enforcement.
As mentioned previously, in 2020, Dridex topped the lists of the most prevalent malware families in the world.
Before we start the analysis of Dridex samples themselves, we want to understand the infrastructure behind the malware. How is it delivered? What are the targets? What is the initial detection rate of supporting files? We will find the answers to all of these questions below.
When the operators want to spread Dridex, they use established spambots from different cyber-crime groups to send malicious documents attached to handily crafted e-mails. At different times of the Dridex lifecycle, Necurs, Cutwail and Andromeda botnets have all been involved in spreading Dridex.
When a user downloads and opens such a document (it may be Word or Excel), the embedded macros are launched with the aim of downloading and executing the Dridex payload.
Figure 6 – Dridex infection chain execution flow.
Dridex targets different high-profile entities from various parts of the world:
To increase the successful rate at which Dridex is spread, malicious actors disguise their spam e-mails to look like legitimate ones. We can name examples of UPS, FedEx and DHL as companies whose logos and mailing style are used as bait in such e-mails.
Figure 7 – Examples of lures.
When the victim clicks the link, either the archive with the malicious document or the malicious document itself is opened.
When first seen in the wild, Dridex delivery files show a very low detection rate. In the screenshot below we see the initial detection rate of the Excel document which delivers Dridex:
Figure 8 – Initial detection rate of the Dridex delivery file.
The same is true for other delivery files.
The Dridex sample consists of the loader and the payload. We discuss key points of each part below.
The Dridex loader utilizes the OutputDebugStringW function to make malware analysis more difficult. Different loaders produce different outputs (with the “Installing…” string being very popular) but the idea is the same everywhere: making a long loop that contains a lot of meaningless debug messages. In the figure below, we see the example of such a loop with an iteration of around 200 million:
Figure 9 – Loop with 0xBEBBE7C (around 200 million) iterations calling OutputDebugStringW.
The output looks like this in the log:
Figure 10 – Dridex debug messages that overwhelm the analysis log.
The payload is heavily obfuscated; almost no function is called directly. Call resolutions are performed with the help of hash values identifying the library and the function it contains. An example of such a resolution is shown in the screenshot below:
Figure 11 – Example of the call resolution in the Dridex payload.
All the functions important for key Dridex’ tasks are called this way.
Figure 12 – Example of resolved calls to Internet functions.
We used the Labeless tool to resolve obfuscated function calls.
Strings in the malware are obfuscated using the RC4 algorithm and the decryption key stored inside the sample.
The main point of interest inside the payload is its configuration. It contains the following important details:
An example of the configuration:
Figure 13 – Example of the Dridex configuration inside the payload.
The bot ID in this example is 12333. The Command and Control servers are:
Dridex sends POST requests to the servers from the configuration to get further commands, waiting for 200 OK responses. Please note that these servers are not real C&C servers but rather proxies for connecting to the real ones.
Figure 14 – The Dridex botnet infrastructure.
The information which is sent by the malware to the C&C servers contains the following data:
This data is encrypted with the RC4 algorithm, the key for which is stored among encrypted strings inside the malware.
There are at least 6 different types of request; among them are the following ones:
The earlier the infection is caught, the better the chances of mitigation. To catch the infection as quickly as possible while spending the minimum amount of resources, we want to focus on the initial delivery stage.
However, detection is only one aspect. We may confidently say that something is malicious, but we also want to classify the threat. To do so, we have to be sure that this particular malware is indeed Dridex.
Let’s take a look at the Dridex infection chain again and determine the different stages which we can use for its detection and identification:
Figure 15 – Different stages of Dridex detection.
At different stages of the Dridex infection, we can use the following indicators for its detection.
We have seen a correlation between infrastructures and indicators of Dridex and other prevalent malware families such as Emotet and Ursnif. Malicious documents share common indicators when used for the delivery of all the malware mentioned above. Some C2 servers – or to be precise, proxy servers – are used both by Dridex and Emotet, though ports and connection types are different.
That’s why we have to analyze a lot of details before we draw a conclusion of what malware we’re dealing with. The more unique factors related to a particular botnet we have, the easier it is to say if another attack has the same patterns.
The ideal way to classify malware is of course getting and analyzing the final payload: if it’s Dridex, then everything that was launched before it is classified as Dridex as well. However, it may take some time (sometimes a significant amount after the initial malicious document is obtained) before the result is known. We can do the classification faster, with high confidence, by analyzing all the indicators we get at the earliest stages of infection chain.
Another interesting note is utilizing the same network for downloading Dridex samples. We analyzed domains used for this purpose, resolved their IPs and discovered that quite a few of them reside in the same network 188.8.131.52/22 with less than 1024 addresses available in total. Network belongs to Russian ASN Selectel that rarely takes down the malicious content or spam.
We saw the following IP addresses linked to Dridex domains in the 184.108.40.206/22 network (and other networks within the same ASN). Dates show the first time the Dridex domain pointed to the corresponding IPs:
While this factor alone is not enough to identify Dridex, this is a good auxiliary detail to refer to when dealing with Dridex IOCs.
The graphs below show Dridex spikes on different dates when we caught the incoming threats at its earliest stages.
Figure 16 – Dridex infection spike on June 29.
Figure 17 – Dridex infection spike between July 6 – July 8.
It is crucial to be able to intercept Dridex infection as early as possible. In many cases, if the spam is not being sent for several days consecutively, like it was between July 6 and July 8, the botnet activity slows down the next day and we do not get as many IOC matches as during its spike. Given that new infections appear at around afternoon UTC+3, we have less than 12 hours to react to the incoming threat.
Since July 22 we haven’t observed any fresh Dridex spam samples. Dridex made a re-appearance on September 7, showing a massive increase in its activity spike for 2 consecutive days:
Figure 18 – Recent September spike in Dridex activity.
Dridex operators updated the 1st stage of Dridex execution: they have added more URLs from where payload may be downloaded – as opposed to the single URL in the earliest versions of malicious documents. Now their number may be as high as 50 within the single document.
We’re constantly monitoring this botnet and detecting its payload at different stages of execution.
We hope this publication provided useful insights on different variants and methods to deal with this threat. We also believe that these methods may be applied when encountering other threats as well.
As cyber attacks become increasingly evasive, more controls are added, making security more complicated and tedious to the point that user workflows are affected. Until now.
Fueled by the Power of ThreatCloud, the Most Powerful Threat Intelligence and AI technologies to prevent unknown cyber threats
SandBlast Network provides the best zero-day protection while reducing security overhead and ensuring business productivity.
Below we list some of the indicators linked to Dridex. Please note that the list is not full by any means.
Dridex 1st layer proxy C&C servers:
Hashes (malicious documents):
Hashes (malware samples):