{
	"id": "7cac95fa-82a9-4fff-b0b4-aa70414168c8",
	"created_at": "2026-04-06T00:15:50.046908Z",
	"updated_at": "2026-04-10T03:21:18.062031Z",
	"deleted_at": null,
	"sha1_hash": "14d2852629b7ffabc3a2fcb6c30a31b63a60c74a",
	"title": "Example Analysis of Multi-Component Malware",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 123852,
	"plain_text": "Example Analysis of Multi-Component Malware\r\nBy tetiana.vashchenko@data443.com\r\nPublished: 2022-07-12 · Archived: 2026-04-05 18:43:56 UTC\r\nRecently, we have received an increase in the number of malicious email samples with password-protected\r\nattachments. The recent waves of attacks with Emotet use a similar approach. In this blog we describe our analysis\r\nof another set of samples that used file archives (e.g. zip file) secured with passwords.\r\nhttps://www.cyren.com/blog/articles/example-analysis-of-multi-component-malware\r\nPage 1 of 13\n\nFigures 1.1 and 1.2: Emails with initial malware component, an HTML attachment\r\nOnce the HTML file is opened, it will drop a file as if that file was downloaded by the user. The HTML page also\r\ndisplays the password for the dropped file.\r\nhttps://www.cyren.com/blog/articles/example-analysis-of-multi-component-malware\r\nPage 2 of 13\n\nFigure 2. the HTML attachment will drop a password-protected archive file named download.zip\r\nExtracted File\r\nOne of the samples we analyzed contained a file named “IMG0457600xls.exe”. The authors tried to disguise the\r\nexecutable file as a Microsoft Office file by using XLS as part as its filename and using a WORD icon. This error\r\nby the perpetrators is a red flag for users.\r\nFigure 3. PE executable with a WORD icon and double extension xls.exe\r\nA quick static analysis of the Portable Executable file reveals that it is a .NET executable so we could use dnSpy\r\nto analyze its behavior. Reviewing its code, one of its methods contains a URL to a file named\r\n“IMG0457600xls.png”. The PNG file extension suggests that it might be an image file but it’s not. We\r\ndownloaded the file so we could reverse engineer the code.\r\nFigure 4. Excerpt code of the download behavior\r\nFileless Payloads\r\nTo identify what the PNG file truly is, we created a simple tool to reverse its contents. After reversing the content,\r\nthe downloaded file is another Windows PE object, a DLL file to be exact. This file type is commonly known as a\r\nreverse EXE. The DLL payload will be loaded in memory using the AppDomain.CurrentDomain.Load method. It\r\nhttps://www.cyren.com/blog/articles/example-analysis-of-multi-component-malware\r\nPage 3 of 13\n\nwill then search if it has a member named “Dnypiempvyffgdjjm”. If found, it will invoke this member via the\r\nInvokeMember method that will execute the main code of the payload in memory.\r\nFigure 5. Code excerpt of the loop searching for the member\r\nFigure 6. EnableServer method which will be called once the member is found\r\nSince we had a copy of the downloaded DLL payload (reverse EXE with PNG extension), we continued our static\r\nanalysis on this component before debugging the initial Windows PE Executable file (IMG0457600xls.exe).\r\nLoading it in dnSpy, we could see valuable information about it. The DLL filename was “Svcwmhdn.dll”. It was\r\nalso obfuscated using Smart Assembly. We used the de4dot tool to de-obfuscate and unpack the DLL component\r\nto make it easier to analyze. Once it was de-obfuscated and unpacked, it gave us a clue that part of the payload\r\nwas also obfuscated by Fody/Costura.\r\nFigure 7. File information of “Svcwmhdn.dll”\r\nhttps://www.cyren.com/blog/articles/example-analysis-of-multi-component-malware\r\nPage 4 of 13\n\nFigure 8. Fody/Costura embedded resources\r\nMalware in action\r\nLayers of Obfuscation\r\nAfter getting clues with our static analysis, we debugged the malware components. We begin our analysis from the\r\npoint when the DLL is loaded into memory. At the start of its execution, it will decompress two resources before\r\nstarting the actual malicious behavior. It uses the AES algorithm to decrypt both resources. It will first decrypt the\r\nresource tagged as “{0235d35d-030c-4d50-b46a-055fbb9ab683}”. This resource contains the strings the malware\r\nuses. Next, it will decrypt “{8569c651-a5ff-4d2e-8dd8-aaa0f6904365}”. It is another Windows PE component,\r\nwhich will be loaded in memory. If the decryption fails, the DLL will try to drop a copy of the component and\r\nload it into memory via the LoadFile method.\r\nFigure 9. The 2 encrypted resources\r\nhttps://www.cyren.com/blog/articles/example-analysis-of-multi-component-malware\r\nPage 5 of 13\n\nFigures 10.1 and 10.2. Decryption method with the AES key and IV, and aesCryptoServiceProvider \r\nhttps://www.cyren.com/blog/articles/example-analysis-of-multi-component-malware\r\nPage 6 of 13\n\nFigure 11. Excerpt code of the decryption of one of the resources\r\nChecking the information if we try to force it to drop the content, it is another executable component. It contains\r\nresources that were compressed using Fody/Costura as seen in our static analysis in Figure 8. It has several\r\nresources to decompress. One of them is the Protobuf-net module. These resources were also decrypted and then\r\ndecompressed. Take note of the resource named “ _._.resources” (141363 bytes, Embedded, Public) which has a\r\nchild resource “Jhufjcjrbgyyuktdl” as this will be accessed later.\r\nhttps://www.cyren.com/blog/articles/example-analysis-of-multi-component-malware\r\nPage 7 of 13\n\nFigure 12. Decompression code for Fody/Costura embedded resources\r\nAfter the layers of obfuscation and related initializations, we will now move at the start of the malware. The\r\nmethod Dnypiempvyffgdjjm is where the main malware routine is located. At the start, it will initialize its settings.\r\nBy looking at Figure 14, we can see the list of the possible actions it can take. Most of the settings were set to\r\nfalse. And by just analyzing it, we can assume that this malware only supports 32bit Operating Systems and will\r\ninject a payload in “MSBuild”.\r\nFigure 13. Start of the main routine\r\nhttps://www.cyren.com/blog/articles/example-analysis-of-multi-component-malware\r\nPage 8 of 13\n\nFigure 14. Settings of the malware\r\nEvasion\r\nAside from the 23 second delay set to evade sandboxes, it also checks if the username of the machine is equal to\r\n“JohnDoe” or the computer name\\\\\\\\hostname is equal to “HAL9TH”. If found true, it will terminate the\r\nexecution. These strings are related to Windows Defender emulator.\r\nFigure 15 shows the code for checking the username\\\\\\\\computer name. Each string is obfuscated and will be\r\nfetched from the decrypted resource (“{0235d35d-030c-4d50-b46a-055fbb9ab683}”). It will compute for the\r\noffset of the string by XORing the input integer and then subtracting 0xA6. The first byte of the located offset is\r\nthe string size followed by the encoded string. The encoded string is then decoded using B64 algorithm. This\r\napproach of retrieving the string is used throughout the malware.\r\nhttps://www.cyren.com/blog/articles/example-analysis-of-multi-component-malware\r\nPage 9 of 13\n\nFigure 15. Excerpt code for the checking of username and computer name/hostname\r\nFinal Fileless Payload\r\nBased on the settings, we assumed that it will inject an executable payload in MSBUILD.exe. So before it can\r\nproceed with the injection, it will need to retrieve the necessary API. Figure 18 shows the code that will try to\r\ndynamically resolve the API’s. The approach to retrieve the string is the same as mentioned earlier. The difference\r\nis that the API encoded strings have an “@” character randomly inserted. It needs to remove the “@” character\r\nbefore proceeding to use the B64 algorithm to decode it. Take a look at the example in the chart below. First, it\r\nwill get the corresponding DLL where it will import the API. In this example, it is “kernel32”. Then it will retrieve\r\nthe API string. After decoding the string using the same approach decoding the DLL string, it will be equal to ”\r\nUmV@zdW1l@VGhyZWFk”. It will then remove the “@” char before proceeding to decoding the string using\r\nB64 again.The final output will be equal to the API string “ResumeThread”. It will dynamically resolve a few\r\nmore API’s. These API’s will be used in its process injection routine.\r\nDLL API\r\nkernel32.dll ResumeThread\r\nkernel32.dll Wow64SetThreadContext\r\nkernel32.dll SetThreadContext\r\nkernel32.dll GetThreadContext\r\nkernel32.dll VirtualAllocEx\r\nhttps://www.cyren.com/blog/articles/example-analysis-of-multi-component-malware\r\nPage 10 of 13\n\nkernel32.dll WriteProcessMemory\r\nntdll.dll ZwUnmapViewOfSection\r\nkernel32.dll CreateProcessA\r\nkernel32.dll CloseHandle\r\nkernel32.dll ReadProcessMemory\r\nTable 17. List of APIs\r\nFigure 18. The first API to be dynamically resolved is ResumeThread, imported from kernel32.dll\r\nAt this point, it just needs the payload it will inject to MSBuild.exe. It hides the payload in the resource named\r\n“Jhufjcjrbgyyuktdl”. The data is reversed and then unpacked using GZIP. The file is a copy of a Formbook\r\nmalware. We detect this file as W32/Formbook.F.gen!Eldorado.\r\nFigure 19. Start of the injection code.\r\nhttps://www.cyren.com/blog/articles/example-analysis-of-multi-component-malware\r\nPage 11 of 13\n\nThe fileless payload Svcwmhdn.dll was created using Purecrypter. It is advertised as a file protector and available\r\nfor sale. And as seen in the GUI interface, these options were available in the settings in Figure 14.\r\nFigure 20. PureCrypter options GUI\r\nIndicators of Compromise (IOCs)\r\nSHA256\r\n6f10c68357f93bf51a1c92317675a525c261da91e14ee496c577ca777acc36f3\r\nDescription: email attachment\r\nFilename: IMG045760.html\r\nDetection: HTML/Dropper.A\r\n9629934a49df20bbe2c5a76b9d1cc2091005dfef0c4c08dae364e6d654713e46\r\nDescription: initial payload\r\nFilename: IMG0457600xls.exe\r\nDetection: W32/MSIL_Kryptik.GSO.gen!Eldorado\r\ndc419e1fb85ece7894a922bb02d96ec812220f731e91b52ab2bc8de44726ce83\r\nDescription: reverse PE fileless payload\r\nhttps://www.cyren.com/blog/articles/example-analysis-of-multi-component-malware\r\nPage 12 of 13\n\nFilename: Svcwmhdn.dll\r\nDetection: W32/MSIL_Kryptik.HJL.gen!Eldorado\r\n37ed1ba1aab413fbf59e196f9337f6295a1fbbf1540e76525b43725b1e0b012d\r\nDescription: final fileless payload\r\nFilename: Jhufjcjrbgyyuktdl\r\nDetection: W32/Formbook.F.gen!Eldorado\r\nSource: https://www.cyren.com/blog/articles/example-analysis-of-multi-component-malware\r\nhttps://www.cyren.com/blog/articles/example-analysis-of-multi-component-malware\r\nPage 13 of 13",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.cyren.com/blog/articles/example-analysis-of-multi-component-malware"
	],
	"report_names": [
		"example-analysis-of-multi-component-malware"
	],
	"threat_actors": [],
	"ts_created_at": 1775434550,
	"ts_updated_at": 1775791278,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/14d2852629b7ffabc3a2fcb6c30a31b63a60c74a.pdf",
		"text": "https://archive.orkl.eu/14d2852629b7ffabc3a2fcb6c30a31b63a60c74a.txt",
		"img": "https://archive.orkl.eu/14d2852629b7ffabc3a2fcb6c30a31b63a60c74a.jpg"
	}
}