At the beginning of the year we talked about a new evolution of cyber theft in the banking sector, and today, we are pleased to share a report that has been painstakingly prepared by the malware laboratory at Panda Security on the latest version of Dridex, a famous banking Trojan known for its sophistication and ability to go undetected on infected computers.

What is Dridex?

The present document gathers analysis of a new variant of harmful code called “Dridex”, specifically the fourth version.

Dridex is a banking Trojan famous for its sophistication and its ability to go undetected on the devices it infects. These devices, once infected, are incorporated onto a modular botnet, at which point malicious characteristics, whether external or their own, can be freely added to them, via modules or libraries (sold separately).

 

The first version appeared toward the end of 2014. At the beginning of 2015, a new, important update was launched, giving way to a second version. When looking at the earlier versions of Dridex, the most stable and resistant of them was the third, which was launched in April 2015 and was used in well-known cyberattacks up until the fourth version, the latest known version and subject of this report, which was found in February of 2017.

No new major updates for Dridex had been found since the dismantlement of important components of the botnet, carried out by government agencies in 2015.

This new variant of the banking Trojan incorporates new functionalities. One of these is called AtomBombing, a functionality whose aim is to inject code without calling suspicious APIs to avoid being detected by monitoring systems. It incorporates the DLL hijacking technique to achieve persistence. Finally, various cryptographic methods were optimized and used to obtain the configuration.

Characteristics of the Trojan

The following are some static properties of the analysed file.

The hash of the Trojan:

MD5 001fcf14529ac92a458836f7cec03896
SHA256 a6db7759c737cbf6335b6d77d43110044ec049e8d4cbf7fa9bd4087fa7e415c7

 

The internal date of creation of the analyzed sample is May 16, 2017. The file in question was compiled to be executed in 64 bit environments and, at the same time, simulate the legitimate dll of Microsoft.

Figure 1. File properties

Additionally, it is encrypted with a distinctive algorithm to avoid detection by antiviruses.

It has been observed that the executable has a fairly high number of sections, 11 in total, as we can see in Figure 2:

Figure 2. Static information of the analyzed binary

In the DATA section, we can observe that the entropy is at 7.799, and is a fairly large in size. It is in this section that the highly encrypted and packaged binary (which, once decrypted, becomes the real malicious code) can be found.

In the first decrypted layer, the executable stores memory in the process, then copies the code and, finally, summons it and runs it, as we see in Figure 3:

Figure 3. Jump to shellcode

The first thing the code does is to obtain the addresses of the functions that it will eventually be using. It does this with a dynamic search through the libraries downloaded by the program.

To carry out this task, it runs through the PEB_LDR_DATA structure and the LDR-MODULE structures to locate the base address of the loaded dlls. It proceeds to access the offset of the export table in order to run through all of the functions exported by the dll and find the address of the sought function in he computer’s memory.

Figure 4. Enumeration of loaded modules

The shellcode, in turn, checks to see whether there is a hook in the undocumented LdrLoadDll function, accessing its address and checking whether the first byte is the same as E9, the equivalent of a jmp assembler.

Figure 5. Hook Verification

If the previous verification was successful, it proceeds to demap the dll memory process with the name “snxhk.dll” which is an Avast and AVG library that creates hooks to monitor processes happening in the sandbox.

Figure 6. Library: snxhk.dll

Finally, the shellcode decrypts the executable found in the DATA section in the computer’s memory, copies it into the base image’s address, and then runs the new resulting executable.

Figure 7. Decrypted executable

In summary, the full process of the sample being unpacked can be seen in Figure 8, where it is detailed more schematically.

Figure 8. Complete unpacking process

Make sure to use advanced cybersecurity solutions like Adaptive Defense 360 that monitor the organization’s systems in real time, detecting and stopping any suspicious behavior that could be harmful to your business.

For more information, download the full report: