HermeticWiper | New Destructive Malware Used In Cyber Attacks on Ukraine



On February 23rd, our friends at Symantec and ESET research tweeted hashes associated with a wiper attack in Ukraine, including one which is not publicly available as of this writing.

We started analyzing this new wiper malware, calling it ‘HermeticWiper’ in reference to the digital certificate used to sign the sample. The digital certificate is issued under the company name ‘Hermetica Digital Ltd’ and valid as of April 2021. At this time, we haven’t seen any legitimate files signed with this certificate. It’s possible that the attackers used a shell company or appropriated a defunct company to issue this digital certificate.

HermeticWiper Digital Signature

This is an early effort to analyze the first available sample of HermeticWiper. We recognize that the situation on the ground in Ukraine is evolving rapidly and hope that we can contribute our small part to the collective analysis effort.

Technical Analysis

At first glance, HermeticWiper appears to be a custom-written application with very few standard functions. The malware sample is 114KBs in size and roughly 70% of that is composed of resources. The developers are using a tried and tested technique of wiper malware, abusing a benign partition management driver, in order to carry out the more damaging components of their attacks. Both the Lazarus Group (Destover) and APT33 (Shamoon) took advantage of Eldos Rawdisk in order to get direct userland access to the filesystem without calling Windows APIs. HermeticWiper uses a similar technique by abusing a different driver, empntdrv.sys.

HermeticWiper resources containing EaseUS Partition Manager drivers

The copies of the driver are ms-compressed resources. The malware deploys one of these depending on the OS version, bitness, and SysWow64 redirection.

EaseUS driver resource selection

The benign EaseUS driver is abused to do a fair share of the heavy-lifting when it comes to accessing Physical Drives directly as well as getting partition information. This adds to the difficulty of analyzing HermeticWiper, as a lot of functionality is deferred to DeviceIoControl calls with specific IOCTLs.

MBR and Partition Corruption

HermeticWiper enumerates a range of Physical Drives multiple times, from 0-100. For each Physical Drive, the \\.\EPMNTDRV\ device is called for a device number.

The malware then focuses on corrupting the first 512 bytes, the Master Boot Record (MBR) for every Physical Drive. While that should be enough for the device not to boot again, HermeticWiper proceeds to enumerate the partitions for all possible drives.

They then differentiate between FAT and NTFS partitions. In the case of a FAT partition, the malware calls the same ‘bit fiddler’ to corrupt the partition. For NTFS, the HermeticWiper parses the Master File Table before calling this same bit fiddling function again.

MFT parsing and bit fiddling calls

We euphemistically refer to the bit fiddling function in the interest of brevity. Looking through it, we see calls to Windows APIs to acquire a cryptographic context provider and generate random bytes. It’s likely this is being used for an inlined crypto implementation and byte overwriting, but the mechanism isn’t entirely clear at this time.

Further functionality refers to interesting MFT fields ($bitmap$logfile) and NTFS streams ($DATA$I30$INDEX_ALLOCATION). The malware also enumerates common folders (‘My Documents’, ‘Desktop’, ‘AppData’), makes references to the registry (‘ntuser’), and Windows Event Logs ("\\\\?\\C:\\Windows\\System32\\winevt\\Logs"). Our analysis is ongoing to determine how this functionality is being used, but it is clear that having already corrupted the MBR and partitions for all drives, the victim system should be inoperable by this point of the execution.

Along the way, HermeticWiper’s more mundane operations provide us with further IOCs to monitor for. These include the momentary creation of the abused driver as well as a system service. It also modifies several registry keys, including setting the SYSTEM\CurrentControlSet\Control\CrashControl CrashDumpEnabled key to 0, effectively disabling crash dumps before the abused driver’s execution starts.

Disabling CrashDumps via the registry

Finally, the malware waits on sleeping threads before initiating a system shutdown, finalizing the malware’s devastating effect.


After a week of defacements and increasing DDoS attacks, the proliferation of sabotage operations through wiper malware is an expected and regrettable escalation. At this time, we have a very small sliver of the aperture into the attacks in Ukraine and subsequent spillover into neighboring countries and allies. If there’s a silver lining to such a difficult situation, it’s seeing the open collaboration between threat intel research teams, independent researchers, and journalists looking to get the story straight. Our thanks to the researchers at Symantec, ESET, Stairwell, and RedCanary among others who’ve contributed samples, time, and expertise.