Analysis of the latest version of the Dridex malware for identity theft

I present to your attention a report on the latest version of Dridex, a well-known banking trojan that became famous for its complexity and ability to go unnoticed even on infected computers.

1. INTRODUCTION
')
Dridex is a banking Trojan known for its complexity and ability to go unnoticed on devices it infects. Being infected, these devices are embedded in a modular botnet, in which malicious characteristics (external or own) can be freely added to them via modules or libraries.

The first version appeared at the end of 2014. In early 2015, a major new update was released, giving life to the second version. When viewing earlier versions of Dridex, the third version, which appeared in April 2015 and was used in well-known cyber attacks until the fourth version, the last known version, which appeared in February 2017, became the most stable and stable.

No other major updates for Dridex since the dismantling of the main components of the botnet made by special services in 2015 have been discovered. [1]

This new version of the banking Trojan contains new functionality. One of them is called AtomBombing - this is a functionality designed to embed code without calling suspicious APIs in order to avoid detection by monitoring systems. It contains a DLL hacking technique to increase its “vitality”. Finally, various cryptographic methods used to obtain the configuration were optimized. [2]

2. CHARACTERISTICS OF TROYAN

Below are some static properties of the file being analyzed. Trojan hash:



The internal creation date of the analyzed sample is May 16, 2017. The file in question was compiled for execution in 64-bit environments in order to simulate a legal dll from Microsoft.


Figure 1. File properties

In addition, the file is encrypted using a unique algorithm, which allows it to remain unnoticed by antivirus programs.

It was found that the executable file has a fairly large number of sections (total - 11), which we can see in Figure 2:


Fig 2. Static information of the analyzed binary file

In the DATA section, we can see that the entropy is at the level of 7,799, and it is quite large. It is located exactly in the section where it is possible to find a hard-to-encrypted binary file (it becomes a real malicious code after decryption). In the first decrypted layer, the executable file stores memory in the process, then copies the code and eventually calls and runs it, as we can see in Figure 3:


Fig. 3. Transition to Shelco

The first thing the code does is get the addresses of the functions it will use. It does this using dynamic search through libraries loaded by the program. To perform this task, it is executed through the PEB_LDR_DATA structure and the LDR-MODULE structure to find the main address of the loaded dll. It refers to the starting address of the export table in order to perform all the functions exported by the dll and find the address of the function sought in the computer’s memory.


Fig. 4. Listing the loaded modules

The silk code, in turn, checks whether there is a “hook” in the undocumented function LdrLoadDll, referring to its address and checking if the first bit is the same as E9 (equivalent to jmp assembler).


Fig. 5. Hook Verification

If the previous verification was successful, it proceeds to unpacking the dll memory process with the name “snxhk.dll”, which is the Avast and AVG library creating “hooks” for monitoring processes occurring in the sandbox.


Fig. 6. Library: snxhk.dll

Finally, the shellcode decrypts the executable file in the DATA section in the computer's memory, copies it to the address of the base image, and then launches the new resulting executable file.


Fig. 7. Decrypted executable file

Thus, the complete process of sample unpacking can be seen in Figure 8, where it is presented more schematically.


Fig. 8. Complete unpacking process.

3. PROCESS OF INFECTION

3.1. Infection vectors
While it is not clear to the end, in what directions is the infection of the device. This can be via an exploit or as part of a spam campaign.

3.2. Interaction with the infected system
Once launched, the trojan checks if it is the only instance of the malware running on the device, and also checks if it has already been implemented in the explorer.exe process.

All this is done by creating and opening a mutex. In order to achieve this, he first builds together the device name and user name, and then calculates their MD5 hash.


Fig. 9. Calculate hash

Then, it adds square brackets at the beginning and end, and separates them with dashes, like a COM object.


Figure 10. Mutex created in the system

Using this algorithm, it is possible to develop a vaccine that creates these mutexes in the systems in order to avoid being infected with the Dridex Trojan. A malicious program that is not running creates a folder in% WINDOWS% \ system32 \ [0-9] {4]


Fig. 11. Created folder

The malicious program copies the legal .exe to the folder along with the corresponding .dll or .cpl. This .dll or .cpl is not legitimate - this is a trojan. After starting .exe from a folder, malicious .dll or .cpl is loaded using a technique known as hijacking.

It also programs a task with a random name (in our example in Figure 12 it is “Domitxtdoi”), which will run every 60 minutes.


Fig. 12. Creating a task

In this example, we see that tcmsetup.exe is launched, after which a malicious dll (TAPI32.dll) is loaded and the infection process begins.

After programming the task, a set of commands is launched and a rule is created in the firewall for explorer.exe:
netsh advfirewall firewall add rule name = "Core Networking - Multicast Listener Done (ICMPv4-In)" program = "C: \ Windows \ Explorer.EXE" dir = in action = allow protocol = TCP localport = any

Creating a malicious task

schtasks.exe / Create / F / TN "Utdcm" / SC minute / MO 60 / TR "C: \ Windows \ system32 \ 3007 \ tcmsetup.exe" / RL highest

During this process, the malicious .dll will be built into the explorer.exe process using AtomBombing techniques. Then it will wait for the moment when the user opens the browser (Internet Explorer, Firefox, Chrome, etc.).

At the moment when the user opens the browser, the new shellcode will be embedded from explorer.exe into the browser, using the same AtomBombing technique.

4. PRESENCE IN THE SYSTEM

To ensure its presence in the system, the following actions are performed. It creates a folder with four random numbers in C: \ Windows \ System32, inside which it copies the legitimate Windows executable file (not always the same) and the .dll, which should be loaded by this executable file. Just this .dll will be modified by malicious code.


Fig. 13. Presence in the system

This technique is known as DLL-hijacking. It uses a command that allows the system to search for the libraries / files that it is going to load / use. In the case of the picture above, the executable file “SystemPropertiesPerformance.exe” will load “SYSDM.CPL” among other libraries. By default, the search for the file "SYSDM.CPL" will first be carried out in the folder where the application was launched. In our example, this is C: \ Windows \ System32 \ 1365. If this file is not found there, then its search will be carried out in other folders depending on how the system has configured the search order for .dll files.

After the executable file and the modified .dll are copied to the same folder, now Dridex must do so as to cause as little suspicion as possible, so its malicious actions are carried out through a legitimate program.

To execute a file, it creates a scheduled task to launch it in a folder with random numbers (C: \ Windows \ System32 \ 1365) every hour, as shown in the previous chapter.


Fig. 14. Creating a programmed task

As already mentioned, the folder name contains four random numbers, and the executable file that it creates does not always have the same name as .dll, but the malware always knows which executable file which library loads, and it is always able to modify the specified library using malicious code.

Continuing our analysis, we see that it acts as follows:

1. It will list all executable files in "C: \ Windows \ System32 \"
2. It will shash the name of each executable file and compare it with the value that was saved earlier. If they match, he will continue working with this executable file.
3. It will read the IAT of the selected executable file and from there select the .dll for further modification.
4. It will read IAT .dll, selected in item 3.
5. It will create a copy of the malicious code (the .dll itself) and add a section with a random name at the end to copy the IAT obtained in Section 4.
6. It will copy the selected executable file (p. 3) and the modified malicious .dll (p. 5) to a random folder.

In this case, it receives a presence in the system and each time the executable file is executed, it will download a malicious .dll.

The malicious program will also create a copy of itself in an executable format along with the registry key in AppData \ Roaming \ [random folder name] with a route in “HKCU \ Software \ Microsoft \ Windows \ CurrentVersion \ Run”.


Fig. 15. Registry key

5. INTRODUCTION THROUGH ATOMBOMBING

Dridex uses the AtomBombing technique to write the shellcode to other processes without causing any suspicion. This is achieved through calls to APC and one of the most commonly used Windows Executive Objects called Atoms. Below are the different stages of implementation in another process.

5.1. Search for a target process

In this case, the target process is the explorer.exe process, and to integrate into it, it must first be available when listing the participating processes using the following functions:


Fig. 16. Enumeration of processes

Once it finds the explorer.exe process, it will call the OpenProcess function to begin listing the alertable threads.

5.2. Search alertable streams


Fig. 17. Alertable streams

At this stage, the malware will try to find any stream in the alertable state, since this will allow her to make APC calls to execute code in the target process.

To find the alertable stream, the trojan first obtains a handle for each thread in explorer.exe. It then runs the call to NtQueueApcThread as NtSetEvent, and waits for any of the threads to respond.

If everything works correctly, then it receives the first thread that answered the call, after which it starts to inject the code.

5.3. Insertion of silk code in the target process

First, the malicious .dll makes a call to GlobalAddAtomW and creates a new Atom with the content that it wants to embed in the target process (in this case, explorer.exe).

Secondly, the malicious .dll calls NtQueueApcThread, and then sends as a parameter a function that must be started by the explorer.exe process.

The first time this is done, the trojan makes a call to the memset to make sure that the zone where the shellcode will be written is at 0.


Fig. 18. Clear memory

It is important to point out that the zone that Dridex chose to copy the silk code is in ntdll, as we can see in R8. This is because ntdll is always loaded into the same starting number in all processes, regardless of ASLR.

In the next iterations, the function passed as the NtQueueApcThread parameter will become GlobalAtomGetAtomNameW, as a result of which the target process will receive the Atom that has just been created by the malicious .dll and write it to the specified zone so that will arouse any suspicion.

First, it will create an IAT for the shells.


Fig. 19. Creating IAT in explorer.exe

And after some iterations, it will completely copy the shellcode to explorer.exe.


Fig. 20. Shelcode in explorer.exe

5.4. Performing the shells in the target process

After the shellcode is copied to explorer.exe, it must be executed. To do this, Dridex modifies the GlobalAtomGetAtomNameA function in the same way as the shellcode was implemented using Atoms. Function source code:


Fig. 21. Initial function

Here's how the function was modified:


Fig. 22. Modified function

As you can see, when you call GlobalAtomGetAtomNameA in explorer.exe, the program will execute the shellcode. After modification of the malicious .dll, a call will be made to GlobalAtomGetAtomNameA using NtQueueApcThread.


Fig. 23. Remote execution of the silkcode

At this point, the shellcode will be executed. After that, GlobalAtomGetAtomNameA will return to its original state, so as not to cause any suspicion.

6. NETWORK CONNECTIONS

After the trojan has been deployed to the explorer.exe process, it opens port 443 (usually used for the HTTPS protocol) and waits for a certain connection.


Fig. 24. Open port 443

7. INDICATORS OF COMPROMATION

To check whether the computer has been compromised by this version of Dridex, consider the following points:

• The explorer.exe process listens on port 443, and the firewall has a rule that allows network traffic for this process.
• There are folders corresponding to the% SYSTEM% \ [0-9] {4} expression, which contain a legitimate executable file and a file with the extension .dll or .cpl.
• There are scheduled tasks that run the file from the% SYSTEM% \ [0-9] {4} folder every 60 minutes.

8. LINKS

[1] Inside the Dridex Malware Takedown

[2] Dridex v4 - AtomBombing and other surprises

[3] Dridex Banking Malware Sample Technical Analysis and Solution