Example Analysis of Multi-Component Malware

Recently, we have received an increase in the number of malicious email samples with password-protected attachments. The recent waves of attacks with Emotet use a similar approach. In this blog we describe our analysis of another set of samples that used file archives (e.g. zip file) secured with passwords.

The authors of this attack inserted the file archive file into an HTML file.

Figures 1.1 and 1.2: Emails with initial malware component, an HTML attachment

Once the HTML file is opened, it will drop a file as if that file was downloaded by the user. The HTML page also displays the password for the dropped file.

Figure 2. the HTML attachment will drop a password-protected archive file named download.zip

Extracted File

One of the samples we analyzed contained a file named “IMG0457600xls.exe”. The authors tried to disguise the executable file as a Microsoft Office file by using XLS as part as its filename and using a WORD icon. This error by the perpetrators is a red flag for users.

Figure 3. PE executable with a WORD icon and double extension xls.exe

A quick static analysis of the Portable Executable file reveals that it is a .NET executable so we could use dnSpy to analyze its behavior. Reviewing its code, one of its methods contains a URL to a file named “IMG0457600xls.png”. The PNG file extension suggests that it might be an image file but it’s not. We downloaded the file so we could reverse engineer the code.

Figure 4. Excerpt code of the download behavior

Fileless Payloads

To identify what the PNG file truly is, we created a simple tool to reverse its contents. After reversing the content, the downloaded file is another Windows PE object, a DLL file to be exact. This file type is commonly known as a reverse EXE. The DLL payload will be loaded in memory using the AppDomain.CurrentDomain.Load method. It will then search if it has a member named “Dnypiempvyffgdjjm”. If found, it will invoke this member via the InvokeMember method that will execute the main code of the payload in memory.

Figure 5. Code excerpt of the loop searching for the member

Figure 6. EnableServer method which will be called once the member is found

Since we had a copy of the downloaded DLL payload (reverse EXE with PNG extension), we continued our static analysis on this component before debugging the initial Windows PE Executable file (IMG0457600xls.exe). Loading it in dnSpy, we could see valuable information about it. The DLL filename was “Svcwmhdn.dll”. It was also obfuscated using Smart Assembly. We used the de4dot tool to de-obfuscate and unpack the DLL component to make it easier to analyze. Once it was de-obfuscated and unpacked, it gave us a clue that part of the payload was also obfuscated by Fody/Costura.

Figure 7. File information of “Svcwmhdn.dll”

Figure 8. Fody/Costura embedded resources

Malware in action

Layers of Obfuscation

After getting clues with our static analysis, we debugged the malware components. We begin our analysis from the point when the DLL is loaded into memory. At the start of its execution, it will decompress two resources before starting the actual malicious behavior. It uses the AES algorithm to decrypt both resources. It will first decrypt the resource tagged as “{0235d35d-030c-4d50-b46a-055fbb9ab683}”. This resource contains the strings the malware uses. Next, it will decrypt “{8569c651-a5ff-4d2e-8dd8-aaa0f6904365}”. It is another Windows PE component, which will be loaded in memory. If the decryption fails, the DLL will try to drop a copy of the component and load it into memory via the LoadFile method.

Figure 9. The 2 encrypted resources

Figures 10.1 and 10.2. Decryption method with the AES key and IV, and aesCryptoServiceProvider 

Figure 11. Excerpt code of the decryption of one of the resources

Checking the information if we try to force it to drop the content, it is another executable component. It contains resources that were compressed using Fody/Costura as seen in our static analysis in Figure 8. It has several resources to decompress. One of them is the Protobuf-net module. These resources were also decrypted and then decompressed. Take note of the resource named “ _._.resources‎” (141363 bytes, Embedded, Public) which has a child resource “Jhufjcjrbgyyuktdl” as this will be accessed later.

Figure 12. Decompression code for Fody/Costura embedded resources

After the layers of obfuscation and related initializations, we will now move at the start of the malware. The method Dnypiempvyffgdjjm is where the main malware routine is located. At the start, it will initialize its settings. By looking at Figure 14, we can see the list of the possible actions it can take. Most of the settings were set to false. And by just analyzing it, we can assume that this malware only supports 32bit Operating Systems and will inject a payload in “MSBuild”.

Figure 13. Start of the main routine

Figure 14. Settings of the malware

Evasion

Aside from the 23 second delay set to evade sandboxes, it also checks if the username of the machine is equal to “JohnDoe” or the computer name\\\\hostname is equal to “HAL9TH”. If found true, it will terminate the execution. These strings are related to Windows Defender emulator.

Figure 15 shows the code for checking the username\\\\computer name. Each string is obfuscated and will be fetched from the decrypted resource (“{0235d35d-030c-4d50-b46a-055fbb9ab683}”). It will compute for the offset of the string by XORing the input integer and then subtracting 0xA6. The first byte of the located offset is the string size followed by the encoded string. The encoded string is then decoded using B64 algorithm. This approach of retrieving the string is used throughout the malware.

Figure 15. Excerpt code for the checking of username and computer name/hostname

Final Fileless Payload

Based on the settings, we assumed that it will inject an executable payload in MSBUILD.exe. So before it can proceed with the injection, it will need to retrieve the necessary API. Figure 18 shows the code that will try to dynamically resolve the API’s. The approach to retrieve the string is the same as mentioned earlier. The difference is that the API encoded strings have an “@” character randomly inserted. It needs to remove the “@” character before proceeding to use the B64 algorithm to decode it. Take a look at the example in the chart below. First, it will get the corresponding DLL where it will import the API. In this example, it is “kernel32”. Then it will retrieve the API string. After decoding the string using the same approach decoding the DLL string, it will be equal to ” UmV@zdW1l@VGhyZWFk”. It will then remove the “@” char before proceeding to decoding the string using B64 again.The final output will be equal to the API string “ResumeThread”. It will dynamically resolve a few more API’s. These API’s will be used in its process injection routine.

Table 16. Data structure of encrypted strings used by the malware

Table 17. List of APIs

Figure 18. The first API to be dynamically resolved is ResumeThread, imported from kernel32.dll

At this point, it just needs the payload it will inject to MSBuild.exe. It hides the payload in the resource named “Jhufjcjrbgyyuktdl”. The data is reversed and then unpacked using GZIP. The file is a copy of a Formbook malware. We detect this file as W32/Formbook.F.gen!Eldorado.

Figure 19. Start of the injection code.

The fileless payload Svcwmhdn.dll was created using Purecrypter. It is advertised as a file protector and available for sale. And as seen in the GUI interface, these options were available in the settings in Figure 14.

Figure 20. PureCrypter options GUI

Indicators of Compromise (IOCs)

SHA256

6f10c68357f93bf51a1c92317675a525c261da91e14ee496c577ca777acc36f3

• Description: email attachment
• Filename: IMG045760.html
• Detection: HTML/Dropper.A

9629934a49df20bbe2c5a76b9d1cc2091005dfef0c4c08dae364e6d654713e46

• Description: initial payload
• Filename: IMG0457600xls.exe
• Detection: W32/MSIL_Kryptik.GSO.gen!Eldorado

dc419e1fb85ece7894a922bb02d96ec812220f731e91b52ab2bc8de44726ce83

• Description: reverse PE fileless payload
• Filename: Svcwmhdn.dll
• Detection: W32/MSIL_Kryptik.HJL.gen!Eldorado

37ed1ba1aab413fbf59e196f9337f6295a1fbbf1540e76525b43725b1e0b012d

• Description: final fileless payload
• Filename: Jhufjcjrbgyyuktdl
• Detection: W32/Formbook.F.gen!Eldorado