{
	"id": "01dd4aba-fd1c-45de-bae4-da51a6c0dcdd",
	"created_at": "2026-04-06T00:22:13.604639Z",
	"updated_at": "2026-04-10T03:20:06.415361Z",
	"deleted_at": null,
	"sha1_hash": "e690a7d6bb5ad6b9778067a2806b4807dc37633b",
	"title": "Dumping WhisperGate’s wiper from an Eazfuscator obfuscated loader – Max Kersten",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 168961,
	"plain_text": "Dumping WhisperGate’s wiper from an Eazfuscator obfuscated\r\nloader – Max Kersten\r\nArchived: 2026-04-02 10:56:56 UTC\r\nThis article was published on the 1st of February 2022.\r\nOn the 15th of January 2022, Microsoft released a report which covers havoc wreaking wiper that is targeting\r\nUkraine. This goal of this article is to provide a step-by-step guide with regards to dumping the wiper sample from\r\nmemory. At first, some observations regarding the sample will be made, and the execution chain will be explained.\r\nTable of contents\r\nTechnical sample information\r\nOutline\r\nObservations\r\nStage 2 – Analysing the loader\r\nCreating a custom loader\r\nStage 3 – Dumping the wiper\r\nConclusion\r\nTechnical sample information\r\nBelow, the information with regards to the initial loader, as well as it’s remote payload, is given.\r\nStage 2\r\nThe sample can be downloaded from Malware Bazaar or MalShare. The hashes are given below.\r\nMD5: 14c8482f302b5e81e3fa1b18a509289d\r\nSHA-1: 16525cb2fd86dce842107eb1ba6174b23f188537\r\nSHA-256: dcbbae5a1c61dbbbb7dcd6dc5dd1eb1169f5329958d38b58c3fd9384081c9b78\r\nSize: 214944 bytes\r\nStage 3 (raw)\r\nThe sample can be downloaded from Malware Bazaar or MalShare. The hashes are given below.\r\nMD5: b3370eb3c5ef6c536195b3bea0120929\r\nSHA-1: b2d863fc444b99c479859ad7f012b840f896172e\r\nSHA-256: 923eb77b3c9e11d6c56052318c119c1a22d11ab71675e6b95d05eeb73d1accd6\r\nSize: 280064 bytes\r\nhttps://maxkersten.nl/binary-analysis-course/malware-analysis/dumping-whispergates-wiper-from-an-eazfuscator-obfuscated-loader/\r\nPage 1 of 7\n\nStage 3 (DLL)\r\nThe sample can be downloaded from Malware Bazaar or MalShare. The hashes are given below.\r\nMD5: e61518ae9454a563b8f842286bbdb87b\r\nSHA-1: 82d29b52e35e7938e7ee610c04ea9daaf5e08e90\r\nSHA-256: 9ef7dbd3da51332a78eff19146d21c82957821e464e8133e9594a07d716d892d\r\nSize: 280064 bytes\r\nOutline\r\nThis blog will focus on the loader, and the stages that follow from it. In the initial attack, this loader was used as\r\nstage two. To remain consistent with other articles, this article will refer to the loader as stage two, the payload as\r\nstage three, and the wiper as stage four. Stage one, the master boot record wiping malware, is not covered in this\r\narticle.\r\nThis blog will focus on the loader with respect to the process hollowing it performs, and how this technique can be\r\nspotted. The loader’s additional capabilities are out of scope for this article, but can be read in this corporate blog I\r\nco-authored.\r\nAnother article in this course provides an in-depth explanation of debugging Dot Net binaries, which provides\r\nfurther clarification on some of the concepts that are used within this article.\r\nDo not forget to make a snapshot of the machine prior to executing the malware, as the loader itself will alter your\r\nmachine, even if the wiper isn’t executed in the end.\r\nObservations\r\nUpon executing the sample, several processes are started. The purpose of some is directly obvious, such as the\r\nencoded PowerShell command that performs a ten second sleep. For the execution of InstallUtil.exe from\r\n%TEMP%, the purpose is not as clear. These observations might not mean much from the get-go, but they can\r\ncome back as a key puzzle piece at a later stage. After a bit, the files on the machine are (partially) overwritten by\r\nthe wiper.\r\nStage 2 – Analysing the loader\r\nThe second stage is written using the Dot Net Framework, and is obfuscated to make the code harder to read.\r\nUsing a debugger, such dnSpyEx, one can go over the code as it is executed. Additionally, or alternatively, one can\r\nstatically go over the code to understand what is going on.\r\nIn short, stage 2 uses a WebClient object to download data from the Discord CDN. The downloaded data seems to\r\nbe an image when looking at the extension of the file in the URL, as it pretends to be a jpg file.\r\nhttps://maxkersten.nl/binary-analysis-course/malware-analysis/dumping-whispergates-wiper-from-an-eazfuscator-obfuscated-loader/\r\nPage 2 of 7\n\nThe code to download the third stage from the remote location\nThe downloaded data (as a byte array) is then reversed in order, after which it is loaded as an Assembly object. As\nsuch, the downloaded data is actually a Dot Net Framework based PE file, rather than an image. Next, the\nexported types from the Assembly object are obtained, after which a function named Ylfwdwgmpilzyaph is\ninvoked without any arguments.\nThe name of the function which is to be invoked\nNormally, one would be able to continue the execution of this stage into the next, but the payload isn’t hosted on\nthe given location anymore. As such, one has to either be able to resolve the URL, by using a custom response for\nthe request, or by invoking the function in another way. The latter way will be described in the next section.\nAs always, do note that there are multiple ways to solve this problem. Based on your own area of expertise and\npreference, a different option might be better suited.\nCreating a custom loader\nStage 3 is a Dot Net Framework based DLL, meaning one cannot simply debug it from the get-go. One way to\neasily debug the DLL, is by writing a simple reflective loader which invokes Ylfwdwgmpilzyaph. The code that is\ngiven below reads the original payload from the disk, reverses the given array, and loads it as an Assembly object.\nThe next step is to fetch the class where the function resides in. This class is named Main, within the namespace\ncalled ClassLibrary1. At last, a member from the type is invoked, based on the given function name. Since this is\na static function, there is no need to initialise the type prior to its invocation.\nbyte[] jpg = File.ReadAllBytes(@\"C:\\WhisperGate\\stage3\\923eb77b3c9e11d6c56052318c119c1a22d11ab71675e6\nArray.Reverse(jpg);\nAssembly assembly = Assembly.Load(jpg);\nType type = assembly.GetType(\"ClassLibrary1.Main\");\ntype.InvokeMember(\"Ylfwdwgmpilzyaph\", BindingFlags.InvokeMethod, null, null, null);\nWithin the Visual Studio project, one has to allow the project to load from remote sources, which can be done by\nediting the app.config file within the project. The snippet that is given below needs to be included in the file.\nhttps://maxkersten.nl/binary-analysis-course/malware-analysis/dumping-whispergates-wiper-from-an-eazfuscator-obfuscated-loader/\nPage 3 of 7\n\nNote that one has to start dnSpyEx with administrator privileges for this specific sample, as this is required later\r\non!\r\nStage 3 – Dumping the wiper\r\nStage 3 is obfuscated using Eazfuscator, which is a commercial obfuscator and optimiser. When digging in the\r\ncode, one will encounter the inclusion of unmanaged functions, as the Dot Net Framework’s interoperability\r\ncapability provides this feature. Additionally, during the execution of the sample in a sandbox (or on your own\r\nanalysis system), one will observe the start of several processes that execute something directly, one being\r\nPowerShell.\r\nAdditionally, InstallUtil.exe is copied to, and executed from %TEMP%. This is an odd location for the file to be\r\nin, but there is something more important: the process is created in a suspended mode. This generally indicates\r\nprocess injection. In this case, process hollowing is used.\r\nSince the process hollowing is performed using unmanaged functions, one can use x32dbg to debug the program.\r\nDo note the need to run the debugger with administrative privileges, as stage 3 requires these privileges later on.\r\nOne can launch the custom loader as a normal executable, break on the entry point, and set breakpoints on\r\nCreateProcessA, CreateProcessW, and WriteProcessMemory. The breakpoints on CreateProcessA and\r\nCreateProcessW will provide context as to when the process hollowing’s target will be started, instead of another\r\nprocess, as it is known that several process will be started by the loader. To see what data is written to the target\r\nprocess, a breakpoint on WriteProcessMemory is set, as this function is used to write data into a given process.\r\nDuring the execution, one will see that the breakpoint on CreateprocessW will be hit when PowerShell and\r\nAdvancedRun are launched. The breakpoint on CreateProcessA will be hit when InstallUtil.exe is launched, the\r\nonly process which is created in a suspended state. After that, WriteProcessMemory is hit several times, once per\r\nsection of the wiper, which it will write in the targeted InstallUtil instance.\r\nDumping the wiper\r\nThe sections of stage 4 are written into the target process one at a time using WriteProcessMemory. The function\r\nsignature is given below, as taken from MSDN.\r\nBOOL WriteProcessMemory(\r\n [in] HANDLE hProcess,\r\n [in] LPVOID lpBaseAddress,\r\n [in] LPCVOID lpBuffer,\r\n [in] SIZE_T nSize,\r\n [out] SIZE_T *lpNumberOfBytesWritten\r\n);\r\nThe third argument points to the buffer that will be written into the target process. The amount of bytes that will be\r\nread from this buffer, and written into the target process, is specified in the fourth argument. When viewing this in\r\nx32dbg’s stack window, the arguments are given, as can be seen in the image below.\r\nhttps://maxkersten.nl/binary-analysis-course/malware-analysis/dumping-whispergates-wiper-from-an-eazfuscator-obfuscated-loader/\r\nPage 4 of 7\n\nWriteProcessMemory’s arguments as shown in x32dbg\r\nOne can right click on the third argument and display it in a specified dump window. To copy the bytes, one can\r\nselect nSize bytes from lpBuffer‘s location onwards. The amount of bytes is given in the fourth argument, which\r\nequals 0x400 for the first section. The image below shows most of the selected bytes. The line in the bottom\r\nshows how many bytes are selected in total, making it easy to see if the complete buffer is selected before copying\r\nthe data.\r\nThe first section of the wiper, as seen in x32dbg’s dump window\r\nhttps://maxkersten.nl/binary-analysis-course/malware-analysis/dumping-whispergates-wiper-from-an-eazfuscator-obfuscated-loader/\r\nPage 5 of 7\n\nTo easily copy the selected bytes, one can use SHIFT + C. This will copy all bytes, without the ASCII\r\nrepresentation or addresses. The image below shows the copy menu options.\r\nx32dbg’s context menu to copy the selected bytes\r\nOne can concatenate all copied buffers in a hex editor, such as HxD. Once all sections are copied, one can save the\r\nnewly created file as stage4.bin, as this is the wiper. One can analyse the fourth stage with an analysis tool of their\r\nown choosing.\r\nThe wiper sample can be found on Malware Bazaar and MalShare. The hashes are given below.\r\nMD5: 343fcded2aaf874342c557d3d5e5870d\r\nSHA-1: 8be3c66aecd425f1f123aadc95830de49d1851b5\r\nSHA-256: 191ca4833351e2e82cb080a42c4848cfbc4b1f3e97250f2700eff4e97cf72019\r\nSize: 25092 bytes\r\nConclusion\r\nEven though the sample is based on the Dot Net Framework, it does not mean that there’s nothing more to the\r\nsample. Additionally, this case serves as the perfect example as to why it’s not always important to focus on the\r\ncomplete deobfuscation of a sample, although that obviously depends on the goal of the analysis.\r\nhttps://maxkersten.nl/binary-analysis-course/malware-analysis/dumping-whispergates-wiper-from-an-eazfuscator-obfuscated-loader/\r\nPage 6 of 7\n\nThere are more ways to dump this stage, and some might be considered easier than others, compared to the\r\nexperience and background of the analysts. Be creative and use the available tools to your advantage!\r\nTo contact me, you can e-mail me at [info][at][maxkersten][dot][nl], or DM me on BlueSky @maxkersten.nl.\r\nSource: https://maxkersten.nl/binary-analysis-course/malware-analysis/dumping-whispergates-wiper-from-an-eazfuscator-obfuscated-loader/\r\nhttps://maxkersten.nl/binary-analysis-course/malware-analysis/dumping-whispergates-wiper-from-an-eazfuscator-obfuscated-loader/\r\nPage 7 of 7",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://maxkersten.nl/binary-analysis-course/malware-analysis/dumping-whispergates-wiper-from-an-eazfuscator-obfuscated-loader/"
	],
	"report_names": [
		"dumping-whispergates-wiper-from-an-eazfuscator-obfuscated-loader"
	],
	"threat_actors": [],
	"ts_created_at": 1775434933,
	"ts_updated_at": 1775791206,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/e690a7d6bb5ad6b9778067a2806b4807dc37633b.pdf",
		"text": "https://archive.orkl.eu/e690a7d6bb5ad6b9778067a2806b4807dc37633b.txt",
		"img": "https://archive.orkl.eu/e690a7d6bb5ad6b9778067a2806b4807dc37633b.jpg"
	}
}