IBM’s X-Force security team recently discovered an updated version of Dridex, called Dridex v4. Dridex is one of the most popular banking trojans. It was first spotted in 2014 when it was viewed as the successor of GameOver ZeuS (GoZ) because it uses GoZ-related techniques. An important improvement in Dridex v4 is that it evades detection antivirus software by introducing the AtomBoming technique for malicious code injection.
The AtomBoming technique is brought up by enSilo. By leveraging design flaws in Windows’ atom tables, AtomBoming writes malicious code into an atom table and then forces a legitimate application to retrieve such code and then execute it.
Sample Introduction
The sample is a 64-bit dynamic link library (DLL) file that leverages the AtomBombing technique to inject malicious code into explorer.exe for traffic hijacking. This sample sets the related registry key for automatic startup and then creates a scheduled task that executes every other hour.
Sample Analysis
Environment
| System | Windows 7, 64-bit |
| Tools | ProcessMonitor, Xuetr, Wireshark, x64dbg, IDA |
Results of Detection by TAC
File Structure
| File Name | MD5 | Function |
| 4599FCA4B67C9C216C6DEA42214FD1CE | 4599FCA4B67C9C216C6DEA42214FD1CE | Hijacking traffic on port 443 and sending the hijacked traffic to a remote server |
Version Information
Main Functions
The sample provides the following functions:
- Edits the local key set file by generating new keys to hijack HTTPS communications.
- Creates a scheduled task to run a legitimate application, and then hijacks the DLL file of the application to execute itself. Also, the sample sets an automatic startup item under HKCU\Software\Microsoft\Windows\CurrentVersion\Run for another legitimate application to run upon a startup, and then enables itself to run at the same time by hijacking the DLL file of the application.
- Creates .cmd files and runs one to add a rule to the firewall, allowing explorer.exe to listen on arbitrary ports that include local port 443.
- Hijacks traffic on port 443 and forwards the hijacked traffic to a remote server.
The following figure shows the workflow of the sample.
The following briefly describes functions of this sample by analyzing code segments:
1. Obtains the target thread.
The sample decrypts itself into a new DLL file.
Then the sample reads the process snapshot to locate the explorer process.
Obtains the import table data to be injected.
Functions in the import table are listed as follows:
To find a thread that can be woken up, the sample opens all threads (a total of 26) of explorer.exe for tests.
An event is created as follows:
The sample, via an NtQueueAPCThread API request, gets all threads of explorer.exe to execute ZwSetEvent.
Then the sample invokes WaitForMultipleObjects to select the first thread that executes ZwSetEvent.
2. Writes the import table and malicious code to the target thread.
The sample adds a string to a global atom table and checks whether the addition succeeds.
Then the sample, via the NtQueueAPCThread API, gets the target thread to invoke GlobalGetAtomW to retrieve data in the atom table and place it to the RW memory space of the ntdll module of the target thread. Note that once a segment of data is written, such data is deleted from the atom table and multiple rounds of data writing and deletion are involved.
The sample reads the data written into the target thread and compares it with the local original data to determine whether the data is successfully written into the target thread.
The sample sets a segment of memory with the RWE attribute in the target thread, and then writes the decrypted assembly code into the memory in the same way as it does the import table.
After writing, the sample changes the memory attribute to RE.
In the same way, the sample changes the content of the first seven bytes of the GlobalGetAtomNameA function in the target thread to the directive for shellcode execution.
The following figure shows the edited GlobalGetAtomNameA function:
The sample, via the NtQueueAPCThread API, gets the target thread to call the GlobalGetAtomA function. As the first seven bytes of this function are changed, shellcode will be executed.
The following shows shellcode execution:
The first seven bytes of the GlobalGetAtomA function are restored to the original data:
Certain decrypted data of the new DLL file mentioned previously is mapped to the memory and then copied to the newly applied local memory space.
The attribute of the newly applied memory is changed to RE (read and execute).
A new thread is created to execute the copied code included in the new DLL file. After that, the original target thread continues its work. The following is how the new thread works.
The thread obtains the import address table (IAT):
The thread maps all the data contained in the new DLL file to its own memory and then execute such data. The data in the DLL file contains a parameter that indicates the address where the copied data resides.
The thread checks whether the parameter value is valid:
If the parameter value is valid, another new thread is created:
The newly created thread edits the key set file by creating new key pairs. This operation lays a foundation for the subsequent HTTPS communication hijacking.
Newly created key pairs are as follows:
The new thread reads .exe files from C:\windows\System32.
The new thread picks out the target file for forgery from its import table, and then reads such file to the memory and view the export table of the file.
A PE file is created in a temporary folder. Actually, for the sake of DLL hijacking, this file is forged based on the export table of a legitimate DLL file.
Some .cmd files are created, one of which is to add a rule to the firewall to allow explorer.exe to listen on local ports.
Both the PE file and OptionalFeatures.exe are placed in a new folder named appwiz.cpl. After that, the sample sets a startup item for OptionalFeatures.exe in the registry. Note that OptionalFeatures.exe is the legitimate application that invokes appwiz.cpl for running. When appwiz.cpl is invoked, malicious sample will hijack it.
appwiz.cpl is created by the sample based on the file with the same file name. Note that appwiz.cpl is just an example here and which target file to select depends on the application that invokes it. The malicious sample is first hijacks appwiz.cpl, then obtains related execution privileges, and executes contents in the decrypted file.
Two similar folders for two applications exist in C:\Windows\System32: one application is set as an automatic startup item, and the other runs every other hour via a scheduled task in order to perpetually reside in memory.
The new thread sets the path to .cmd files under the registry entry, HKCU\Software\Classes\MSCFile\shell\open\command(Default):
The new thread, eventvwr.exe, is created to execute these .cmd files. As related registry entries are modified, the new process will run applications under HKCU\Software\Classes\MSCFile\shell\open\command, and then restore related registry entries. Once an application is executed, its registry entry is cleared.
After the preceding operations, the sample starts performing network functions.
Network Behaviors
When it comes to network functions, the sample hijacks traffic over port 443.
The sample listens on local port 443 and invokes the select() function indefinitely. If the select() function executes successfully, the sample invokes the accept() function.
After the connection simulation, the sample creates a new thread:
The new thread attempts to receive data:
After data is received, the thread invokes the connect() function (to connect the invalid IP address, 0.0.0.0):
After connection simulation, the thread is found to send the data that is received over port 443 to the newly connected server, and then repeat data receiving and sending operations.
Launch Mode
An automatic startup item is created like this: In the directory of a legitimate application, there is a DLL file required for the application to run. When the application runs, the DLL file will be hijacked for the sample to run automatically upon a startup.
Escape from Detection of Antivirus Software
The sample runs by hijacking a DDL file of a legitimate application, injects shellcode with the AtomBoming technique, then restores the original application environment after injection, and finally executes malicious code by creating threads. The whole process does not affect the normal running of the host application. The sample’s dynamic API obtaining makes itself more difficult to detect and analyze. Also, the sample sets the normal application as an automatic startup item by manipulating the registry, and then hijacks the DLL of the application for automatic startup. This makes it impossible to locate the sample. Besides, the sample executes .cmd files by using EVENTVWR.EXE and modifying the registry.
Solutions
- Detection by Customers
(1) Verify that there are two subdirectories under C:\Windows\System32\0485[random], either of which contains a .exe file and .dll or .cpl file that is necessary for the .exe file to run.
(2) Verify that the automatic startup item of one of the preceding .exe files is included in HKCU\Software\Microsoft\Windows\CurrentVersion\Run.
(3) Check the list of scheduled tasks to determine whether the sample creates a task for one of the .exe files.
(4) Verify that explorer.exe listens on port 443.
(5) Check whether files are modified under C:\Users\username\AppData\Roaming\Microsoft\Crypto\RSA\S-1-5-**.
(6) Check rules on firewalls. In the case of trojan infection, a rule named Core Networking – Multicast Listener Done (ICMPv4-In) exists for the application named C:\Windows\Explorer.EXE.
- NSFOCUS Solutions for Removing Trojans
(1) Short-term service: NSFOCUS engineers provide the onsite trojan backdoor removal service (manual services + NIPS + TAC + Kingsoft V8+ terminal security system) to ensure that risk points are immediately eliminated in the network and the event impact is minimized. After the handling, an event analysis report is provided.
(2) Mid-term service: NSFOCUS provides 3- to 6-month risk monitoring and preventive maintenance inspection (PMI) services (NIPS + TAC + manual services)
(3) Long-term service: NSFOCUS provides industry-specific risk mitigation solutions (threat intelligence + attack traceback + professional security service).
Statement
This advisory is only used to describe a potential risk. NSFOCUS does not provide any commitment or promise on this advisory. NSFOCUS and the author will not bear any liability for any direct and/or indirect consequences and losses caused by transmitting and/or using this advisory. NSFOCUS reserves all the rights to modify and interpret this advisory. Please include this statement paragraph when reproducing or transferring this advisory. Do not modify this advisory, add/delete any information to/from it, or use this advisory for commercial purposes without permission from NSFOCUS.
About NSFOCUS
NSFOCUS IB is a wholly owned subsidiary of NSFOCUS, an enterprise application and network security provider, with operations in the Americas, Europe, the Middle East, Southeast Asia and Japan. NSFOCUS IB has a proven track record of combatting the increasingly complex cyber threat landscape through the construction and implementation of multi-layered defense systems. The company’s Intelligent Hybrid Security strategy utilizes both cloud and on-premises security platforms, built on a foundation of real-time global threat intelligence, to provide unified, multi-layer protection from advanced cyber threats.
For more information about NSFOCUS, please visit:
http://www.nsfocusglobal.com.
NSFOCUS, NSFOCUS IB, and NSFOCUS, INC. are trademarks or registered trademarks of NSFOCUS, Inc. All other names and trademarks are property of their respective firms.