# Malware Report ## “Dridex Version 4” **SIN CLASIFICAR** ----- ### August, 2017 #### CONTENTS **1.** **EXECUTIVE SUMMARY ............................................................................................................ 2** **2.** **CHARACTERISTICS OF THE TROJAN ....................................................................................... 3** **3.** **INFECTION PROCESS .............................................................................................................. 6** 3.1. Infection Vectors.............................................................................................................. 6 3.2. Interactions with the Affected System ........................................................................ 6 **4.** **PERSISTENCE IN THE SYSTEM ................................................................................................... 7** **5.** **INJECTION VIA ATOMBOMBING ........................................................................................... 9** 5.1. Search for the target process ....................................................................................... 9 5.2. Search for alertable threads ....................................................................................... 10 5.3. Injection of shellcode in the target process ............................................................. 10 5.4. Execution of the shellcode in the target process ................................................... 12 **6.** **NETWORK CONNECTIONS .................................................................................................... 13** **7.** **IOCS ....................................................................................................................................... 14** **8.** **REFERENCIAS ......................................................................................................................... 14** #### 1. Executive Summary The present document gathers analysis of a new variant of harmful code called “Dridex”, specifically the fourth version. 2 ##### SIN CLASIFICAR ----- 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. 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. [1] 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. [2] #### 2. 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: 3 ##### SIN CLASIFICAR |MD5|001fcf14529ac92a458836f7cec03896| |---|---| |SHA256|a6db7759c737cbf6335b6d77d43110044ec049e8d4cbf7fa9bd4087fa7e415c7| ----- **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 LDRMODULE 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** 4 ##### SIN CLASIFICAR ----- 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** 5 ##### SIN CLASIFICAR ----- #### 3. INFECTION PROCESS 3.1. Infection Vectors The infection of the device is not clearly understood. It may come by way of an exploit kit or spam campaign. #### 3.2. Interactions with the Affected System Once it is run, the Trojan will proceed to verify if it is the only instance of malware running on the device, as well as to verify if it has already been injected in the explorer.exe process. All of this is carried out by creating and opening a mutex. In order to achieve this, it first strings together the device name and the username, then calculates its MD5 hash. **Figure 9. Hash calculation** Next, it adds brackets to the beginning and the end, and separates it with hyphens, similar to a COM object. **Figure 10. Mutex created in the system** Using this algorithm, it may be possible to develop a vaccine that creates these mutexes in systems to avoid infection by Dridex. Malware that is not running creates a folder in %WINDOWS%\system32\[0-9]{4] 6 ##### SIN CLASIFICAR ----- **Figure 11. Created folder** The malware copies a legitimate .exe into the folder along with an associated .dll or .cpl. This .dll or .cpl is not legitimate — it’s a Trojan. Upon running the .exe from the folder, the malicious .dll or .cpl will load via a technique known as hijacking. It also programs a task with a randomized name (“Domitxtdoi” in our example in Figure 12), which will run every 60 minutes. **Figure 12. Creation of task** In this example, we see that the tcmsetup.exe runs so that the malicious .dll, TAPI32.dll, loads, thus beginning the infection process. After programming the task, it launches a series of commands: it creates a rule in the firewall for explorer.exe, which is where it will be injected: ``` 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 ``` **Creation of the 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 have been injected into the explorer.exe process using the AtomBombing technique. It will then wait for the user to open a browser like Internet Explorer, Firefox, Chrome, etc. The moment the user opens a browser, a new shellcode will be injected from explorer.exe to the browser using the same AtomBombing technique. #### 4. PERSISTENCE IN THE SYSTEM To ensure its persistence in the system, it carries out the following actions. It creates a folder with four random numbers on C:\Windows\System32, inside of which it copies a legitimate Windows executable (not always the same one) and a .dll that it knows will be loaded by the executable. This .dll will be modified with the harmful code. 7 ##### SIN CLASIFICAR ----- **Figure 13. Persistence in the system** This technique is known as DLL hijacking. It takes advantage of the command that allows the system to search libraries/files that it’s going to load/use. In the case of the image above, the executable "SystemPropertiesPerformance.exe" will load "SYSDM.CPL" among other libraries. By default, the first place that it will search for the "SYSDM.CPL" file will be in the directory where the application is running, in this case C: \ Windows \ System32 \ 1365. If it does not find it, it will look it up on other routes depending on how the search order of .dlls in the system is set. When it copies an executable and a modified .dll in the same directory, Dridex’s aim is to raise as little suspicion as possible, since its malicious actions are carried out by way of a legitimate program. To execute the file, it creates a scheduled task to run it in the random number folder (C: \ Windows \ System32 \ 1365) every hour, as indicated in the previous section. **Figure 14. Creation of the programmed task** As already mentioned, the folder is composed of four random numbers, and the executable it creates is not always the same, just like the .dll, so it is aware of which executable loads which library at all times, and is able to modify said library with harmful code. Going further in our analysis, we see that it acts in the following manner: 1. It will list all executables in the folder "C: \ Windows \ System32 \" 2. It will hash the name of each executable and compare it with a value that has been previously saved. If it matches, it will remain with that executable (in each execution that the hash is different). 3. It will read the IAT of the selected executable and from there choose a .dll for eventual hijacking. 8 ##### SIN CLASIFICAR ----- 4. It will read the IAT of the .dll selected in point 3. 5. It will make a copy of the malicious code (the .dll itself) and add a section at the end with a random name to copy the IAT obtained in point 4. 6. It will copy both the selected executable (3) and the modified malicious .dll (5) into a random folder. In this way it obtains persistence in the system and every time that file is executed it will load the malicious .dll. The malware will also create a copy of itself in executable format along with a registry key in the AppData\Roaming\[random folder name] with the route in "HKCU\Software\Microsoft\Windows\CurrentVersion\Run". **Figure 15. Registry key** #### 5. INJECTION VIA ATOMBOMBING Dridex uses the AtomBombing technique to write a shellcode in other processes without raising suspicions. It achieves this through APC calls and one of the most used Windows Executive Objects, called Atoms. Below are the different phases of injection into another process. #### 5.1. Search for the target process 9 ##### SIN CLASIFICAR ----- The target process in this case is explorer.exe, and to inject into it, it must first be accessed in order to perform an enumeration of the processes involved, making use of functions such as the following: Once it finds the process explorer.exe, it calls the OpenProcess function to begin enumerating alertable threads. #### 5.2. Search for alertable threads At this point, the malware will try to find some thread in an alertable state, as this will allow it to make APC calls in order to execute code in the target process. To find an alertable thread, it first obtains a handle for each thread in explorer.exe. It will then launch a call to NtQueueApcThread as NtSetEvent and wait for any of the threads to respond. If it works correctly, it will obtain the first thread that answers the call and start with the injection. #### 5.3. Injection of shellcode in the target process First, the malicious .dll makes a call to GlobalAddAtomW and creates a new Atom with the content it wishes to inject in the target process, in this case explorer.exe. Second, the malicious .dll calls the NtQueueApcThread and sends as a parameter the function to be run by explorer.exe. 10 ##### SIN CLASIFICAR ----- The first time this is done, it makes a call to memset to make sure that the zone where it will write the shellcode is at 0. **Figure 19. Memory wipe** It is important to indicate that the zone that Dridex has chosen for copying the shellcode is in ntdll as we can see in R8. This is because ntdll is always loaded on the same offset in all processes, regardless of the ASLR. In the following iterations the function passed as parameter of NtQueueApcThread will be GlobalAtomGetAtomNameW, which will cause the target process to get the Atom that just created the malicious .dll and write it in the indicated zone, in such a way that it will write its contents inside the explorer.exe without raising suspicions. First it will create an IAT for the shellcode. **Figure 20. IAT creation in explorer.exe** And after several iterations it will copy the shellcode in explorer.exe completely. 11 ##### SIN CLASIFICAR ----- **Figure 21. Shellcode in explorer.exe** #### 5.4. Execution of the shellcode in the target process Once the shellcode is copied to the explorer, it must be executed. To do this, Dridex modifies the GlobalAtomGetAtomNameA function in the same way that it has injected the shellcode, using Atoms. Original code of the function: **Figure 22. Original function** 12 ##### SIN CLASIFICAR ----- Here's how the function has been modified: **Figure 23. Modified function** As you can see, when you call GlobalAtomGetAtomNameA in explorer.exe the program will execute the shellcode. After the modification, from the malicious .dll, a call will be made to GlobalAtomGetAtomNameA using NtQueueApcThread. **Figure 24. Remote execution of the shellcode** At this point the shellcode will start executing. After this, GlobalAtomGetAtomNameA is returned to its original state, to avoid suspicion. #### 6. NETWORK CONNECTIONS The Trojan, once it has been injected into the explorer.exe process, opens port 443 (usually used for the HTTPS protocol) and waits for some connection. 13 ##### SIN CLASIFICAR ----- **Figure 25. Port 443 opened** #### 7. IOCs To check if a computer has been compromised by this version of Dridex, the following points should be considered: - The explorer.exe process has port 443 listening and there is a firewall rule in place allowing network traffic for that process. - Directories that match the expression %SYSTEM%\[0-9] {4}, and contain a legitimate executable next to a .dll or .cpl file. - Scheduled tasks that execute a file in path %SYSTEM%\[0-9] {4} in periods of 60 minutes. #### 8. REFERENCIAS **Inside the Dridex Malware Takedown** [1] Link: [http://www.bankinfosecurity.com/dridex-botnet-disruption-lessons-](http://www.bankinfosecurity.com/dridex-botnet-disruption-lessons-learned-a-8594) [learned-a-8594](http://www.bankinfosecurity.com/dridex-botnet-disruption-lessons-learned-a-8594) **Dridex v4 - AtomBombing and other surprises** [2] Link: https://www.virusbulletin.com/conference/vb2017/abstracts/dridex-v4 atombombing-and-other-surprises/ **Dridex Banking Malware Sample Technical Analysis and Solution** [3] Link: [http://blog.nsfocus.net/dridex-banking-malware-sample-technical-](http://blog.nsfocus.net/dridex-banking-malware-sample-technical-analysis-solution/) [analysis-solution/](http://blog.nsfocus.net/dridex-banking-malware-sample-technical-analysis-solution/) 14 ##### SIN CLASIFICAR |[1]|Inside the Dridex Malware Takedown Link: http://www.bankinfosecurity.com/dridex-botnet-disruption-lessons- learned-a-8594| |---|---| |[2]|Dridex v4 - AtomBombing and other surprises Link: https://www.virusbulletin.com/conference/vb2017/abstracts/dridex-v4- atombombing-and-other-surprises/| |[3]|Dridex Banking Malware Sample Technical Analysis and Solution Link: http://blog.nsfocus.net/dridex-banking-malware-sample-technical- analysis-solution/| -----