Dridex: A History of Evolution

The Dridex banking Trojan, which has develop into a huge financial cyberthreat in the past years (in 2015, the harm carried out through the Trojan was once estimated at over $ forty million), stands except for other malware as a result of it has frequently evolved and turn into extra refined since it made its first appearance in 2011. Dridex has been in a position to flee justice for see you later by way of hiding its primary command-and-keep an eye on (C&C) servers in the back of proxying layers. on condition that outdated versions cease working when new ones seem and that every new improvement is another step ahead in the systematic development of the malware, it may be concluded that the same individuals had been involved in the Trojan’s building this entire time. beneath we provide a short overview of the Trojan’s evolution over six years, as well as some technical small print on its latest variations.

how it All started out

Dridex made its first look as an independent malicious program (below the title “Cridex”) round September 2011. An analysis of a Cridex pattern (MD5: 78cc821b5acfc017c855bc7060479f84) verified that, even in its early days, the malware could receive dynamic configuration information, use internet injections to steal cash, and used to be ready to infect USB media. This ability influenced the name underneath which the “zero” model of Cridex was detected — Worm.Win32.Cridex.

That version had a binary configuration file:

Sections named databefore, datainject, and dataafter made the web injections themselves appear just like the standard Zeus malware (there could have been a connection between this and the 2011 Zeus source code leak).

Cridex 0.77–zero.80

In 2012, a considerably modified Cridex variant (MD5: 45ceacdc333a6a49ef23ad87196f375f) was once released. The cybercriminals had dropped performance related to infecting USB media and replaced the binary format of the configuration file and packets with XML. Requests despatched by way of the malware to the C&C server regarded as follows:

The <message> tag was once the XML root element. The <header> tag contained information about the machine, bot identifier, and the version of the bot.

here is a sample configuration file:

aside from the foundation component <packet>, the Dridex zero.8 configuration file remained nearly unchanged until model 3.zero.

Dridex 1.10

The “zero” model was once maintained unless June 2014. a tremendous operation (Operation Tovar) to take down another common worm — Gameover Zeus — was performed that month. virtually as soon as Zeus used to be taken down, the “zero” model of Cridex stopped working and Dridex version 1.100 regarded virtually precisely one month later on (on June 22).

sample configuration file:

This pattern already has redirects for injected .js scripts which are attribute of Dridex.

here’s a comparability between Dridex and Gameover Zeus injections:

thus, the takedown of 1 popular botnet (Gameover Zeus) ended in a breakthrough in the building of some other, which had many robust resemblances to its predecessor.

We mentioned above that Dridex had begun to use PCRE, whereas its earlier versions used SLRE. Remarkably, the one other banking malware that additionally used SLRE used to be Trojan-Banker.Win32.Shifu. That Trojan used to be found out in August 2015 and was distributed thru unsolicited mail by the use of the same botnets as Dridex. moreover, both banking Trojans used XML configuration recordsdata.

We even have causes to imagine that, as a minimum in 2014, the cybercriminals in the back of Dridex were Russian audio system. this is supported through comments within the command & control server’s supply code:

And with the aid of the database dumps:

Dridex: from version 2 to model three

by early 2015, Dridex applied a roughly P2P community, which can be harking back to the Gameover Zeus Trojan. On that network, some friends (supernodes) had get entry to to the C&C and forwarded requests from other community nodes to it. The configuration file was once still saved in XML layout, but it obtained a new part, <nodes>, which contained an up-to-date peer checklist. additionally, the protocol used for communique with the C&C used to be encrypted.

Dridex: from version 3 to model four

one of the directors of the Dridex network used to be arrested on August 28, 2015. in the early days of September, networks with identifiers 120, 200, and 220 went offline. on the other hand, they came back online in October and new networks had been introduced: 121, 122, 123, 301, 302, and 303.

notably, the cybercriminals stepped up safety features at that time. particularly, they presented geo-filtering wherein an IP container regarded in C&C request packets, which was once then used to establish the peer’s u . s .. If it was once no longer on the list of goal international locations, the peer obtained an error message.

In 2016, the loader changed into extra sophisticated and encryption strategies were changed. A binary loader protocol was once introduced, along with a <settings> section, which contained the configuration file in binary structure.

Dridex four.x. back to the longer term

The fourth version of Dridex was once detected in early 2017. It has capabilities just like the 0.33 version, however the cybercriminals stopped the use of the XML layout within the configuration file and packets and went again to binary. The analysis of latest samples is rendered considerably harder by way of the truth that the loader now works for two days, at most. this is just like Lurk, with the exception of that Lurk’s loader was once simplest active for a few hours.

examining the Loader’s Packets

The packet structure within the fourth version is much like those within the late changes of the loader’s three.x versions. however, the names of the modules requested were replaced with hashes:

here is the function that implements C&C conversation and uses these hashes:

figuring out the packet structure in the previous version, you possibly can guess which hash pertains to which module with the aid of comparing packets from the 0.33 and fourth variations.

within the fourth model of Dridex, there are many locations the place the CRC32 hashing algorithm is used, including hashes used to seek for operate APIs and to take a look at packet integrity. it will make experience for hashes used in packets to be none rather then CRC32 of requested module names. This assumption can simply be confirmed by way of running the next Python code:

That’s proper – the hashes acquired this way are the same as those in this system’s code.

in relation to encryption of the loader’s packets, nothing has modified. As in Dridex version 3, the RC4 algorithm is used, with a key saved in encrypted type within the malicious program’s body.

yet another exchange presented in the fourth model is that a so much stricter loader authorization protocol is now used. A loader’s lifespan has been diminished to at some point, after which encryption keys are modified and old loaders turn into useless. The server responds to requests from all out of date samples with error 404.

prognosis of the Bot’s Protocol and Encryption

basically, the verbal exchange of Dridex model 4 with its C&C is based on the identical process as earlier than, with peers still acting as proxy servers and replacing modules. on the other hand, encryption and packet construction have changed considerably; now a packet seems like the <settings> part from the earlier Dridex version. No more XML.

the basic Packet era operate is used to create packets for conversation with the C&C and with peers. There are two types of packets for the C&C:

1. Registration and transfer of the generated public key
2. Request for a configuration file

The operate outputs the following packet:

A packet starts offevolved with the size of the RC4 key (74h) in an effort to be used to encrypt strings in that packet. that is followed with the aid of two parts of the important thing which might be the same dimension. the true key’s calculated by using performing XOR on these blocks. next comes the packet sort (00h) and encrypted bot identifier.

Peer-to-Peer Encryption

sample encrypted P2P packet:

The header of a P2P packet is a DWORD array, the sum of all elements by which is zero. The obfuscated data dimension is identical as in the previous version, but the knowledge is encrypted differently:

The packet begins with a 16-byte key, adopted by means of four bytes of information about the scale of knowledge encrypted with the previous key the use of RC4. subsequent comes a sixteen-byte key and knowledge that has been encrypted with that key using RC4. After decryption we get a packet compressed with gzip.

Peer to C&C Encryption

As ahead of, the malware makes use of a mixture of RSA, RC4 encryption, and HTTPS to be in contact with the C&C. in this case, friends work as proxy servers. An encrypted packet has the following construction: four-byte CRC, followed by using RSA_BLOB. After decrypting RSA (request packets cannot be decrypted without the C&C personal key), we get a GZIP packet.

Configuration File

we’ve got managed to acquire and decrypt the configuration file of botnet 222:

it is extremely identical in construction to the <settings> section from the earlier model of Dridex. It begins with a four-byte hash, which is adopted by the configuration file’s sections.

The sections are of the same types as in <settings>:

• 01h – HttpShots
• 02h – Formgrabber
• 08h – Redirects
• and so on.

the one thing that has modified is the encryption of strings within the configuration file – RC4 is now used.

RC4 used to be additionally used to encrypt knowledge in p2p packets.

Geographical Distribution

The builders of Dridex search for possible victims in Europe. Between January 1st and early April 2017, we detected Dridex job in a couple of European nations. the united kingdom accounted for more than 1/2 (virtually 60%) of all detections, followed with the aid of Germany and France. on the similar time, the malware never works in Russia, as the C&Cs discover the united states via IP address and don’t reply if the u . s . a . is Russia.

Conclusion

in the a couple of years that the Dridex family has existed, there had been a lot of unsuccessful attempts to dam the botnet’s task. the ongoing evolution of the malware demonstrates that the cybercriminals are not about to bid farewell to their brainchild, which is providing them with a steady revenue stream. for example, Dridex builders proceed to put in force new tactics for evading the person Account keep watch over (UAC) device. These ways allow the malware to run its malicious elements on home windows methods.

it may be surmised that the identical people, probably Russian audio system, are in the back of the Dridex and Zeus Gameover Trojans, however we have no idea this for a reality. The damage carried out by the cybercriminals can also be inconceivable to investigate competently. in response to a very rough estimate, it has reached a whole lot of tens of millions of greenbacks by using now. furthermore, given the way that the malware is evolving, it can be assumed that a significant part of the “cash” is reinvested into the banking Trojan’s building.

The analysis was carried out in response to the following samples:

Dridex4 loader: d0aa5b4dd8163eccf7c1cd84f5723d48
Dridex4 bot: ed8cdd9c6dd5a221f473ecf3a8f39933

Securelist – details about Viruses, Hackers and spam