Recently, there have been continuous attacks targeting domestic companies. Most of the malicious files collected from the companies’ breached systems have been dynamic library (DLL) files, but the files used in the attacks this time are different from general DLL files. The collected files had their normal libraries modified maliciously through a variety of methods.
It has not been found how the malicious files were created in the system and what the initial attack path was. Also, due to the nature of libraries which cannot be run on their own, they require trigger behaviors that run libraries, but this and the additional file information have not been confirmed. Still, the analysis of the files collected so far revealed clear characteristics of the recent attacks.
- Malicious files that modified (added, replaced, or changed) the export information of normal library (DLL) files
- The attacker requires valid arguments or data files to run malicious files
- The attacker can modularize or replace features through arguments or data files
Characteristics of Attacks that Use Library Files
The attacker created malicious files by newly adding export functions to normal library files, exchanging function formats, or changing codes of the existing functions. As most of the codes are normal, users are highly likely to judge files as being normal unless they inspect them carefully.
A valid argument or data file is needed to run the malicious files, which means there is limit to fully analyze the attack with just individual files. Even the automated analysis device was unable to produce meaningful execution results.
Attackers fragmented (modularized) features using arguments or data files, and depending on the input information, the codes run on memory or C&C address might change. If the system is dominated, the attacker can continuously change features in real-time.
Malicious File Types by Library Modification and Operation Method
The malicious library files collected from the companies’ breached systems can be categorized into four types based on modifications and operation methods. [Table 1] lists the normal library filenames assumed to be modified by the attacker, filenames of malicious library files at the time of collection, and DLL names stated in ‘Export Directory’ on the PE file format by type. Looking at the file features alone, the types do not seem to be directly related.
The collected malicious library files are modified forms of the original normal library files, but filenames are different. If filenames were the same, the attacker would have run the malware with the DLL Hijacking method of replacing library files. But because the additional information including the initial path of the attack is not yet ascertained, it is unknown whether the filenames were changed or the original library files were simply modified and disguised. In other words, it has not been confirmed how the malicious library files were run.
The collected malicious library filenames are different from the DLL names stated on the ‘Export Directory’ struct. Yet as DLL names of the ‘Export Directory’ struct do not affect the library when it is loaded, they do not have much significance. Still, one can expect that the attacker might have changed filenames when modifying the original library files.
|Type||Normal DLL Filename||Malicious DLL Filename||Export DLL name of Malicious DLL File|
[Type A] Adds malicious export function. Needs argument
The malicious export function glInitTexture was added to the normal libGLESv2 library file. Because a function was added, there is one more export function in the ‘Export Directory’ struct than the normal one. When the glInitTexture function is run, it checks the run argument condition of 32 characters. It processes internally using the argument and runs the malicious PE in memory. As valid argument information was not found, the team could not identify the features of the executed PE.
[Type B-1] Replaces normal function with malicious ServiceMain function. Needs ADS data
The DllMain function, the first export function of the normal libxml2 library file, was replaced with the malicious ServiceMain function. There is no change in the number of export functions. Being a ServiceMain function, it operates as a Windows service. When it is run, the malicious file reads the ADS (Alternate Date Streams) data. Using ADS, it hides the malicious data needed for the execution from the user. Zone and data stream are key data needed to decrypt encrypted data and passwords respectively. After processing internally, the file runs the malicious PE in memory. The executed malicious PE requires the rsrc stream data. Its final feature is the connection to C&C.
[Type B-2] Only malicious ServiceMain function exists. Needs ADS data
It is uncertain whether the normal library files exist at all. This file only has the Windows service ServiceMain function as the export function. Unlike other types, there is no file resource version information. Also, considering it does not have any export functions except the malicious ServiceMain function, the type may be a malicious library file that was solely created. There are some differences between codes, but the malicious file of this type has a feature similar to that of type B-1 malicious file and needs the ADS data named zone and data. As the stream data was not collected, the team could not know further features.
[Type C] Adds malicious functions besides ServiceMain. Needs data file
The malicious file of this type modified the NppExport library of the Notepad++ plugin. Four export functions not presented in the normal library were added. Besides ServiceMain and ServiceHandler to operate as a Windows Service, there are two other functions: AttachMove and DetachMove. The features of AttachMove and DetachMove functions are normal in terms of features, and the codes in the DllMain function in the normal library were moved. The malicious file calculates internally using the wmicc.dat data file existing in the fixed directory and runs the malicious PE in memory. The malicious PE that is run needs the wmicd.dat data file. Its final feature is to connect to C&C.
[Type D] Changes the existing function’s codes. Needs arguments. Creates and loads data file
The normal Dokan library was modified. This is the most unique type of modification. No export functions were added or changed. Only the binary code within the function was changed. Like previous types, it is not easy to confirm whether the library was modified or not with just the ‘Export Directory’ struct information. Also, because the file changed the entire code pattern by packing the previous VC++ file with Vmprotect, it is difficult to check its features and whether the code was changed. The changed code can be checked by unpacking Vmprotect and comparing by export function. DokanNotifyXAttrUpdate is the function that had its code changed.
When calling the malicious export function, it operates only when the valid argument starting with ‘-s’ is sent. When the argument is given, the type can create the VirtualStore.cab data file in the system %Temp% directory. If the argument fits the specific condition, it loads the data file. The Data file includes code running for C&C communication and the URL information. Multiple VirtualStore.cab data files were found in the breached systems. It appears that the attacker changed the C&C server in real-time.
For the entire code and more detailed explanation of features, check ATIP, ‘the next-generation threat intelligence platform.’