# Example Analysis of Multi-Component Malware **[cyren.com/blog/articles/example-analysis-of-multi-component-malware](https://www.cyren.com/blog/articles/example-analysis-of-multi-component-malware)** ## Cyren Security Blog July 13, 2022 The Cyren Security Blog is where Cyren engineers and thought leaders provide insights, research and analysis on a range of current cybersecurity topics. by Kervin Alintanahin 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](https://www.cyren.com/blog/articles/emotet-resurgence) 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](https://github.com/dnSpy/dnSpy/releases) 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](https://github.com/de4dot/de4dot) 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-b46a055fbb9ab683}”). 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 ” [email protected]@VGhyZWFk”. It will then](https://www.cyren.com/cdn-cgi/l/email-protection) 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_ DLL API ----- kernel32.dll ResumeThread kernel32.dll Wow64SetThreadContext kernel32.dll SetThreadContext kernel32.dll GetThreadContext kernel32.dll VirtualAllocEx kernel32.dll WriteProcessMemory ntdll.dll ZwUnmapViewOfSection kernel32.dll CreateProcessA kernel32.dll CloseHandle kernel32.dll ReadProcessMemory _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 Jul 12, 2022 | [Malware,](https://www.cyren.com/blog/articles/category/malware) [Security Research & Analysis](https://www.cyren.com/blog/articles/category/security-research) -----