What makes this threat interesting is the unusual implementations of the malicious macro and the malware. Moreover, the geographical distribution of some malware infections in the Middle East is quite interesting. Unfortunately, I can't share the exact countries publicly. (^_^)
Microsoft has given the malicious Word documents an own family name as TrojanDropper:W97M/Miskip. The malware hasn't an own signature yet and is only detected as generic malware by AV companies.
At the end of the article, I also provide a small Python script which can be used to extract the encrypted files (decoy document + payload) from the malicious Word documents.
Malicious Word Documents
The malicious Word documents are sent via emails to the targeted persons. After opening a document, a more or less professionally designed page appears which requests the victim to enable macros so the actual content can be seen. If someone falls trap to this, the document gets closed, deleted and instead a decoy will be shown. At the same time, the malware is installed in the background.
The following screenshots show the collected documents before and after the macro was enabled:
|Figure 1. "closing of borders for migrants by European Union countries.DOC" (Creation date: 2015/11/24)|
|Figure 2. "memo.doc" (Creation date: 2015/11/04)|
|Figure 3. Fake certificate of "memo.doc"|
|Figure 4. "Australian_students.doc" (Creation date: 2015/11/03)|
|Figure 5. "BUDGETARY PLAN 2016.DOC" (Creation date: 2015/11/03)|
|Figure 6. "Information-letter.DOC" (Creation date: 2015/11/03)|
|Figure 7. "CV Leila Musayeva.doc" (Creation date: 2015/04/15)|
|Figure 8. "Galileo project.doc" (Creation date: 2015/03/18)|
|Figure 9. "Invitation for Dl Vasile Soare (FIS 2015).DOC" (Creation date: 2015/03/18)|
|Figure 10. "Conference.doc" (Creation date: 2015/03/18)|
Sometimes, the decoy documents contain several pages of which only the first page is shown here. As you can see, one document is even signed with a fake certificate from the Swedish consulate of Honolulu.
There are two versions of the malicious macro which I categorize further as "old" and "new". In older versions, the macro only decrypts the older version of the malware which is appended to the document and executes it. In this case, the malware itself carries the decoy document and is responsible for opening it and delete the original document. In newer versions, the macro decrypts and starts the decoy document and the malware which are both appended to the document.
The malicious macro is implemented as a VBA module and uses the predefined names AutoOpen and AutoClose to automatically execute the functionality after the document was opened and closed. A live analysis of the source code is tricky to do, since after enabling the macro in order to debug it the original document gets deleted together with the macro. Furthermore, some old and all new versions of the macro have their strings obfuscated. Moreover, in some recent documents the macro is additionally password protected.
However, there are a few tools available to extract a VBA macro source from a Word document in order to statically analyse it. For example, I have used the olevba.py script from oletools which can extract the source code even if the macro is password protected.
An analysis of the old macro version was already done by Xavier Mertens and can be found here.
The deobfuscated source code of the new macro can be seen in the following code listing:
The macro takes the last 4 bytes of the document which is the size of the appended data and subtracts it from the document size to get the offset of the data. Starting from this offset, the decoy document and the malware will be decrypted, written to disk and executed. Each appended file contains a 1 byte checksum which will be compared to the calculated checksum after decryption. The following illustration shows the layout of a document:
|Figure 11. Layout of the malicious Word documents with the new macro|
The decoy document and malware payload will be extracted to the %USERPROFILE%\Documents folder as view.doc and view.exe. The file names and the target folder may vary in the new macros.
An overview of the collected documents along with their characteristics is given in the following table:
|Document file name||Creation date||Macro version||Macro obfuscated||Macro password protected|
|closing of borders for migrants by European Union countries||24.11.2015||new||yes||no|
|BUDGETARY PLAN 2016||03.11.2015||new||yes||no|
|CV Leila Musayeva||15.04.2015||old||no||no|
|Invitation for Dl Vasile Soare (FIS 2015)||18.03.2015||old||yes||no|
The custom made malware is a small backdoor which can download additional malware and upload files to the C&C server. Depending on the macro version, there are basically 3 variants involved in which the final malware will be dropped.
The custom malware evolved over time and has a modular design. It consists of one executable (EXE) and several libraries (DLL) for both Windows platforms, 32-bit and 64-bit. These files will be extracted into the following folder:
The functionality is divided into the different libraries, starting from a file named dws.exe (in recent versions). This file checks for the Windows version and chooses the appropriate library to further process. The 64-bit counterparts of the 32-bit components always have a "...60" suffix. The start module of the 64-bit malware version is named msi.exe. The following screenshot shows the the different modules of the malware:
|Figure 12. Modules of the custom made malware|
The following table gives an overview of the module functionalities:
|dws.exe||Starting point (32-bit); Decides whether to load x86 modules or to switch to x64 counterpart (msi.exe)|
|msi.exe||64-bit starting point; Loads x64 modules|
|msi.dll / msvci60.dll||Process injection module|
|msi32.dll / msi60.dll||Module managing and persistency module|
|msk.dll / msk60.dll||Command processing module|
|msp.dll / msp60.dll||Process searching module (target process strings encrypted)|
|mst.dll / mst60.dll||Networking module|
Sensitive strings are encrypted with the RC4 stream cipher and will be decrypted on-the-fly. For each malware always the same initial decryption key is used, but some modules change the key with the help of a small obfuscation trick. Essentially, the decryption key is altered by adding 0x3 to each byte of the key. However, this not instantly recognizable since the value 0x3 will be obtained using Windows API function calls:
|Figure 13. Code obfuscation trick to obtain value 0x3|
By using CreateFile() along with 0 as lpFileName parameter the function will always fail with the error code ERROR_PATH_NOT_FOUND (0x3). This error code is obtained with the help of GetLastError().
An example of the decrypted strings used in the 32-bit malware files dropped by the macro of "BUDGETARY PLAN 2016.doc" can be seen in the following listing:
A complete list of the extracted C&C servers from all malware files of the different documents can be found in the network indicators section at the end.
The use of VBA macros to infect victims cannot only be seen in malware mass distributions, but also in targeted attacks. Although this specific threat actor doesn't use any advanced techniques it can still pose a risk. The decision to split the malware into several modules on disk is a bit unusual. However, beside maintainability reasons this approach could have been chosen to bypass detection, since the single malicious functions are divided into several files.
Python script to extract the files from TrojanDropper:W97M/Miskip.(A/B): https://github.com/TheEnergyStory/malware_analysis/tree/master/Python/Miskip
Thanks to Anton Cherepanov