Tuesday, June 14, 2016

In recent years, the revival of malicious VBA macros has become quite popular among cyber criminals. At the beginning of last year, a new threat actor also started to send spear phishing emails with malicious Microsoft Word documents. During my research, I have found multiple malicious documents which indicate that this is a campaign of targeted attacks. The threat actor uses a custom made malware which hasn't been publicly disclosed yet.

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:

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.

Malicious Macro

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

memo

04.11.2015

new

yes

yes

Australian_students

03.11.2015

new

yes

yes

BUDGETARY PLAN 2016

03.11.2015

new

yes

no

Information-letter

03.11.2015

new

yes

no

CV Leila Musayeva

15.04.2015

old

no

no

Galileo project

18.03.2015

old

no

no

Invitation for Dl Vasile Soare (FIS 2015)

18.03.2015

old

yes

no

Conference

18.03.2015

old

yes

no

Custom Malware

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.

In the first variant, which is used when the old macro is involved, a self-extracting RAR archive will be dropped and executed. This file contains the decoy document, a JavaScript file and another self-extracting RAR file. The JavaScript file is responsible for deleting all dropped files after their execution including itself. The second self-extracting RAR file contains the files of the custom malware.

In the second variant, which is also used when the old macro is involved, a compiled executable will be dropped instead of a self-extracting RAR archive. This executable contains the decoy document, the JavaScript file and another dropper encrypted inside its .text section. The second dropper is also a compiled executable, but contains the custom malware files non-encrypted inside the .data section.

The last variant is used when the new macro is involved. As already mentioned, the appended decoy document and malware are dropped by the macro. The dropped file is again a self-extracting RAR archive which contains the custom malware files. The job of the JavaScript file is done by a batch file that will be decrypted by the final malware.

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:

%APPDATA%\Microsoft\VisualStudio\11.0

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:

File name

Description

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.

Conclusion

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.

Friday, May 27, 2016

Sometimes, when analysing a malware sample you think: "Wait a minute, I have seen this before". While it's already known that the author of Jolly Roger Stealer is also behind TreasureHunter, this person also wrote H1N1 Loader. When you take a look at the disassembly of Jolly Roger Stealer and H1N1 Loader it becomes clear that it's the same coding style. Also, the two malware use the same techniques to obfuscate strings, hashing API functions, using shellcode and patching Windows files to bypass UAC.

Comparison of Jolly Roger Stealer and H1N1 Loader (v2)

Jolly Roger Stealer comes in the form of a Visual Basic executable with the encrypted payload in the resource section. Interestingly, the decryption algorithm uses the PXOR instruction (MMX) along with the registers MM0 and MM1.

Figure 1: Decryption algorithm of Jolly Roger Stealer

Once decrypted into memory, it in turn decrypts the final payload from its .data section and stores it to the Windows registry. Moreover, it creates either a process of svchost.exe or wuauclt.exe and patches its entrypoint with a shellcode. This shellcode than loads the final payload from the registry into memory, unpacks (Upack) and executes it.

H1N1 Loader comes in the form of an executable with no imports. It carries the encrypted and Upack compressed payload in the .text section. To bypass UAC it uses a modified version of the Wusa.exe method which also includes the patching of a Windows file with a shellcode.

A comparison of both malware can be seen in the following flowchart:

Figure 2: Comparison of the functionalities of Jolly Roger Stealer and H1N1 Loader

As you can see, the final payload is always a DLL file which is compressed with Upack. Patching the entrypoint of Windows system files seems to be the preferred method of the author to bypass UAC. The final payload of Jolly Roger Stealer doesn't use any string obfuscation and API function hashing. One can think that it was only encrypted with the help of a crypter which was written by the H1N1 Loader. However, I think it's more likely that both malware are written by the same person, since also the advertises share some similarities. Moreover, I have neither seen nor read about any crypter which uses the described techniques.

As mentioned above, both malware use the same method to obfuscate sensitive strings:

Figure 3: Comparison of the string obfuscation techniques

And the almost identical hashing algorithm for API functions and library names:

Figure 4: Comparison of the hashing algorithms

Conclusion

Sometimes it happens that you can connect the dots between several malware. My theory is that the author first released Jolly Roger Stealer at the end of 2013, but dropped the project for some reasons. He went on with TreasureHunter which first appeared around one year after the first Jolly Roger Stealer samples were seen. Later, he started to write H1N1 Loader which is based on his former project Jolly Roger Stealer.

Due to a misconfigured C&C server which allowed a public directory listing, I was able to obtain over 1 GB of data from the victims. With this information, I can draw the geographical distribution of victims and present the top countries of infection.

The data

The C&C server contained several directories with text files named after the IP address of the victim. The earliest file dates back to 24. February 2016, so it stayed undetected for 2 months according to this data. Each file contains the following information:

- The CPU model
- A list of system drivers with path names
- The Network interfaces
- A list of processes along with the modules and their path names
- A list of installed programs
- A list of programs in the registry Run key
- A list of running Windows services with path names

It looks like the operators run different campaigns to spread their malware, because there are several directories which contain files with different creation date. For example, there is a directory named "1" which contains only victim data files created on 24. February 2016. Another folder named "2" contains only files created on 24., 25. and 26. February 2016 and so on.

Infection statistics

I assume the malware sends the information about a victim only once to the C&C server. Otherwise, you would have a ton of duplicate files from the same victim which would only differ in the volatile information (e.g. process list). Based on this assumption we have a total number of 15060 infected hosts during the period from 24. February - 26. April 2016.

The geographical distribution of the victims is presented in the following map:

Figure 1: Geolocation of Furtim infections

The markers on the map are based on the GeoLite databases which gives only an imprecise geolocation of IP addresses. For example, if there are multiple IP addresses located in and around a city, the geolocation results in the same coordinates. A lot of duplicate geolocations were therefore removed and thus not all of the 15060 victims are present in the map. However, the map should give a good overview of the distribution of victims.

The absolute numbers associated with countries are given in the following diagrams:

Figure 2: Top 30 countries of Furtim infections (logarithmic)

Figure 3: Top 30 countries of Furtim infections (linear)

Conclusion

Given the period of 2 months a total of 15060 victims were infected with Furtim. The malware is spread all over the world and the country with the highest infection rates is the Ukraine.

Friday, July 18, 2014

What I have learned over the years as a hobby malware analyst is whenever you think you are the first who discovered a new malware family, you can be sure at least a dozen people are already working on the threat. And I am not speaking about what you can later see in public...

As in the case of the recently discovered banker named Dyre this is no exception. While cleaning up my malware collection yesterday, I stumbled upon a malware threat which Anton Cherepanov and I briefly analyzed 3 months ago. After a quick search on the Internet, I realized that this sample which was first discovered by ESET and named Win32/Battdil.A respectively Win64/Battdil.A is the recently publicated threat named Dyre or Dyreza banker. You can read about this malware here:

I thought to give it a shot, since I have realized in my last article that reversing Java malware is quite funny, probably because it is easier and not that exhausting as looking over hundreds/thousands of lines of disassembled code. Unfortunately, the article doesn't give any hashes, just the file name of the malware sample which is named IMAG00953.zip.

Friday, June 20, 2014

It's friday afternoon, I had a bit of free time and stumbled across this tweet by PhysicalDrive0 (thx!) two hours ago and thought to give it a try to finally add a new article to this Blog (first of 2014):