{
	"id": "893665a2-54ae-4c81-a22a-e3f2a6e8b2f7",
	"created_at": "2026-04-06T00:07:15.879564Z",
	"updated_at": "2026-04-10T03:20:33.483917Z",
	"deleted_at": null,
	"sha1_hash": "3d1dbded2cced4b85dd3d725be18f22b57e44f69",
	"title": "An AI Based Solution to Detecting the DoubleZero .NET Wiper",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 220141,
	"plain_text": "An AI Based Solution to Detecting the DoubleZero .NET Wiper\r\nBy Akshata Rao, Zong-Yu Wu, Wenjun Hu\r\nPublished: 2022-11-19 · Archived: 2026-04-05 15:16:18 UTC\r\nExecutive Summary\r\nUnit 42 researchers introduce a machine learning model that predicts the maliciousness of .NET samples based on\r\nspecific structures in the file, by analyzing a .NET wiper named DoubleZero. We identify the challenges of\r\ndetecting this threat through PE structural analysis and conclude by examining the cues picked up by the machine\r\nlearning model to detect this sample.\r\nWhile wipers are not necessarily new, the recent discovery of several new wipers associated with the ongoing\r\nRussia-Ukraine cyber activity has driven renewed public interest in understanding how to identify and defend\r\nagainst their use.\r\nPalo Alto Networks customers receive protections from .NET malwares with Cortex XDR or the Next-Generation\r\nFirewall with cloud-delivered security services, including WildFire and Advanced Threat Prevention.\r\nDoubleZero Wiper\r\nThe wiper DoubleZero was revealed to the public by Ukraine CERT in March 2022. It is one of many wipers –\r\nincluding HermeticWiper, IsaacWiper and CaddyWiper – that were apparently targeted against their country.\r\nDoubleZero is implemented in C#, and it is heavily obfuscated. This wiper is capable of typical, non-reversible\r\nand destructive actions that include the following:\r\nGaining the highest privilege in the host\r\nHunting down all available targeted files from every volume\r\nDestroying targeted files or disk volumes within a short period of time\r\nUnlike HermeticWiper and other wipers that damage the Master Boot Record (MBR) or GUID Partition Table\r\n(GPT), DoubleZero only wipes the first 4096 bytes in selected files using the file system driver. We limit our focus\r\non the .NET samples feature engineering, but this Splunk article provides a more in-depth technical analysis of the\r\nwiper sample.\r\nSHA256 3b2e708eaa4744c76a633391cf2c983f4a098b46436525619e5ea44e105355fe\r\nFile size 419.50 KB\r\nExamining the PE File Structure\r\nhttps://unit42.paloaltonetworks.com/doublezero-net-wiper/\r\nPage 1 of 7\n\nResearchers have been commonly using Microsoft Windows Portable Executable (PE) file structure to detect PE\r\nmalware for many years. The thought behind this tactic is that variants of the same malware family can often share\r\nsimilarities in their file structure.\r\nMachine learning models also detect PE malware based on the file structure. To do so, they have historically used\r\nPE header characteristics, imports and section attributes to recognize known malware characteristics.\r\nWhile the .NET PE file structure is based on the PE format, a lot of its functionality is encoded within the .NET\r\nspecific structures. In the next section, we’ll dive deeper into the .NET structural attributes.\r\nAn Inside Look Into .NET files\r\nThe .NET open source framework was introduced in 2002 and is available by default in most Microsoft Windows\r\nplatforms. The framework provides developers with powerful, built-in methods to access the internet, file system\r\nand encryption. Having these options already available makes this framework attractive to both system\r\nadministrators and malware authors.\r\nMicrosoft Windows PE loader will already know how to load and execute the .NET sample once the framework is\r\nready, since .NET assembly re-uses the PE file format.\r\nDuring code generation, the source code for .NET compatible languages is compiled to platform-agnostic\r\nCommon Intermediate Language (CIL) byte code. A special .NET\r\nIMAGE_DIRECTORY_ENTRY_COM_DESCRIPTOR can be found in the data directory for referencing the\r\nCor20 header, as shown in Figure 1. The Cor20 header (otherwise known as the CLR header) contains .NET\r\nspecific information like versioning and resource information and the location of the Metadata header. The\r\nresources, streams, type references, methods, CIL byte codes and usage of external assemblies are all in the\r\nmetadata. For a more detailed description, please refer to our article on dotnetfile.\r\nhttps://unit42.paloaltonetworks.com/doublezero-net-wiper/\r\nPage 2 of 7\n\nFigure 1. A simple illustration of .NET file structure.\r\nUnlike most PE files, where dependent libraries and APIs can be found in the import table, for a .NET file the\r\nimport table contains just one module (the mscoree.dll) and one imported function (_CorExeMain for executables\r\nand _CorDllMain for dynamic load libraries). The resources are contained within the .NET storage stream instead\r\nof the .rsrc section.\r\nThe entry point of the PE header points to the _CorExeMain or _CorDllMain of the mscoree.dll, while the actual\r\nentry point can be found in the Cor20 header as shown in Figure 2. Thus, some of the most useful attributes to\r\nidentify PE malware files do not contain many clues for .NET malware.\r\nhttps://unit42.paloaltonetworks.com/doublezero-net-wiper/\r\nPage 3 of 7\n\nFigure 2. .NET specific structures and the data they hold.\r\nThe metadata table contains defined tables for Module, MethodDef and Assembly among others. By examining\r\nthe .NET file structure, we can see it provides a lot more information about the file as compared to the PE file\r\nstructure alone. Instead of only using the general PE features for the .NET machine learning solution, we added\r\nthe data specifically parsed from the structure of .NET samples. These customized features improve the quality of\r\nour machine learning solutions.\r\nApplying Machine Learning to .NET Malware Detection\r\nWe have trained a machine learning model on custom features learned on the PE file structure, .NET file structure\r\nand other file characteristics of .NET samples, as shown in Figure 3.\r\nAs .NET is an extremely popular file type in customer environments, it is necessary for us to have a quick\r\nturnaround time in case any disruptive false positives emerge. This means that our model’s functionality has to be\r\nwell understood by researchers, and that the predictions could be reverse engineered.\r\nBecause .NET files are so ubiquitous, they also have a highly imbalanced distribution of benign vs. malicious\r\nsamples. Consequently, the trained model has to ensure that we maintain extremely low false positive rates while\r\nretaining detection accuracy.\r\nhttps://unit42.paloaltonetworks.com/doublezero-net-wiper/\r\nPage 4 of 7\n\nFigure 3. An overview of our detection workflow.\r\nDetecting the DoubleZero Wiper\r\nThe malware sample has a single import, _CorExeMain, from mscoree.dll, consistent with other .NET executable\r\nfiles. It contains only .text and .reloc sections, all of which are native to the PE file format and have fairly low\r\nentropy. Hence, there’s not much we can learn from this file’s PE structure.\r\nThe CIL bytecode uses obfuscation to hide the string resources that are critical for pattern based detection. It also\r\ninterleaves random code among actual operations, together with flattened control flow, to make the code harder to\r\nfollow. However, we can glean a lot about the objective of this malware by observing the imported libraries and\r\nassociated API calls found in the decompiled code.\r\nThe imports System.DirectoryServices.ActiveDirectory and System.Security.AccessControl indicate the intention\r\nto interact with the Active Directory and access control attributes of the files.\r\nThe regular expression function imported by System.Text.RegularExpressions is used to locate certain files by\r\npatterns.\r\nThe most significant signs of malicious code usage are the calls to the unmanaged DLL functions. Platform\r\nInvoke (P/Invoke) enables the managed codes in .NET to call the unmanaged functions. Calling the lower level\r\nAPIs directly is a well known anti-analysis technique to evade API hooking by sandbox. The following\r\nunmanaged APIs are used in the sample:\r\nntdll.ntopenfile\r\nntdll.ntfscontrolfile\r\nntdll.rtlntstatustodoserror\r\nntdll.rtladjustprivilege\r\nkernel32.closehandle\r\nkernel32.getfilesizeex\r\nhttps://unit42.paloaltonetworks.com/doublezero-net-wiper/\r\nPage 5 of 7\n\nkernel32.getlasterror\r\nuser32.exitwindowsex\r\nIn most of the use cases, there are equivalent managed functions in .NET runtime libraries to use. However, this\r\nsample intends to operate at a lower level with some of the unmanaged APIs in ntdll.dll.\r\nThe target files and the regular expression patterns are surprisingly stored as plain strings, as shown in Figure 4.\r\nThis possible mistake by the threat actor allows us to get more insights about the objective of the sample.\r\nFigure 4. An example decompiled code snippet where the sample uses regular expressions to search\r\nthe target files.\r\nThough obfuscation exists, we are still able to get the argument FsControlCode for the call to\r\nntdll.NtFsControlFile, which is 0x980c8 = FSCTL_SET_ZERO_DATA. This is how the wiper writes 4K of null\r\nbytes to a targeted file that was opened by ntdll.NtOpenFile.\r\nThe sample calls ntdll.RtlAdjustPrivilege several times with privileges 9, 17, 18 and 19. These privileges are\r\nSeTakeOwnershipPrivilege, SeBackupPrivilege, SeRestorePrivilege and SeShutdownPrivilege respectively. These\r\nprivileges are used to ensure the wiper has the access right to destroy the target file and reboot the system after all\r\nthe actions are done.\r\nUnlike HermeticWiper and ransomware like LockBit, DoubleZero doesn’t delete the shadow copies that can\r\npossibly be used to recover files from the damage. However, the wiper does kill any process named lsass. Lsass is\r\nimportant to the Windows system, and any application that kills this process is most likely malicious.\r\nThe aforementioned file characteristics give us clues that the machine learning model uses to detect the sample.\r\nThough obfuscation is more common among malicious .NET files, because the sample uses several unmanaged\r\nAPIs as well as sensitive target path patterns, these stand out as potentially malicious indicators.\r\nConclusion\r\nResearchers have been using PE file structure to detect variants within malware families for years, as they often\r\nshare similarities in their file structure. Despite the .NET framework being well known, it can still be challenging\r\nto detect files using this strategy. Some of the most useful attributes for identifying PE malware files don’t offer\r\nmany clues for identifying .NET malware.\r\nWe have highlighted the fundamental difference between .NET and PE samples to help identify where those clues\r\ncould be hiding. In doing so, we illustrated that machine learning feature engineering can be improved by\r\ncorrectly parsing out the .NET specific data structure.\r\nWe also showed that imported libraries, unmanaged API calls and unencrypted strings are the most useful features\r\nfor detecting .NET malware. While a recent wiper called DoubleZero was analyzed as an example, the features\r\nhttps://unit42.paloaltonetworks.com/doublezero-net-wiper/\r\nPage 6 of 7\n\nthat are important for detecting .NET can be generalized, and this feature can be broadly useful for future research\r\nefforts.\r\nPalo Alto Networks customers receive protections from .NET malware with Cortex XDR or the Next-Generation\r\nFirewall with cloud-delivered security services including WildFire and Advanced Threat Prevention.\r\nIndicators of Compromise\r\n3b2e708eaa4744c76a633391cf2c983f4a098b46436525619e5ea44e105355fe\r\nSource: https://unit42.paloaltonetworks.com/doublezero-net-wiper/\r\nhttps://unit42.paloaltonetworks.com/doublezero-net-wiper/\r\nPage 7 of 7",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia",
		"ETDA"
	],
	"references": [
		"https://unit42.paloaltonetworks.com/doublezero-net-wiper/"
	],
	"report_names": [
		"doublezero-net-wiper"
	],
	"threat_actors": [],
	"ts_created_at": 1775434035,
	"ts_updated_at": 1775791233,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/3d1dbded2cced4b85dd3d725be18f22b57e44f69.pdf",
		"text": "https://archive.orkl.eu/3d1dbded2cced4b85dd3d725be18f22b57e44f69.txt",
		"img": "https://archive.orkl.eu/3d1dbded2cced4b85dd3d725be18f22b57e44f69.jpg"
	}
}