Example Analysis of Multi-Component Malware
By tetiana.vashchenko@data443.com
Published: 2022-07-12 · Archived: 2026-04-05 18:43:56 UTC
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.
https://www.cyren.com/blog/articles/example-analysis-of-multi-component-malware
Page 1 of 13

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.
https://www.cyren.com/blog/articles/example-analysis-of-multi-component-malware
Page 2 of 13

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
https://www.cyren.com/blog/articles/example-analysis-of-multi-component-malware
Page 3 of 13

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”
https://www.cyren.com/blog/articles/example-analysis-of-multi-component-malware
Page 4 of 13

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
https://www.cyren.com/blog/articles/example-analysis-of-multi-component-malware
Page 5 of 13

Figures 10.1 and 10.2. Decryption method with the AES key and IV, and aesCryptoServiceProvider 
https://www.cyren.com/blog/articles/example-analysis-of-multi-component-malware
Page 6 of 13

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.
https://www.cyren.com/blog/articles/example-analysis-of-multi-component-malware
Page 7 of 13

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
https://www.cyren.com/blog/articles/example-analysis-of-multi-component-malware
Page 8 of 13

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.
https://www.cyren.com/blog/articles/example-analysis-of-multi-component-malware
Page 9 of 13

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.
DLL API
kernel32.dll ResumeThread
kernel32.dll Wow64SetThreadContext
kernel32.dll SetThreadContext
kernel32.dll GetThreadContext
kernel32.dll VirtualAllocEx
https://www.cyren.com/blog/articles/example-analysis-of-multi-component-malware
Page 10 of 13

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.
https://www.cyren.com/blog/articles/example-analysis-of-multi-component-malware
Page 11 of 13

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
https://www.cyren.com/blog/articles/example-analysis-of-multi-component-malware
Page 12 of 13

Filename: Svcwmhdn.dll
Detection: W32/MSIL_Kryptik.HJL.gen!Eldorado
37ed1ba1aab413fbf59e196f9337f6295a1fbbf1540e76525b43725b1e0b012d
Description: final fileless payload
Filename: Jhufjcjrbgyyuktdl
Detection: W32/Formbook.F.gen!Eldorado
Source: https://www.cyren.com/blog/articles/example-analysis-of-multi-component-malware
https://www.cyren.com/blog/articles/example-analysis-of-multi-component-malware
Page 13 of 13