{
	"id": "799c2ed7-7de7-4561-b5d2-6a2d11a88224",
	"created_at": "2026-04-06T00:09:23.35211Z",
	"updated_at": "2026-04-10T13:12:23.089462Z",
	"deleted_at": null,
	"sha1_hash": "9915fd7be2b4a858e134002d5af8315da7662b40",
	"title": "HermeticWiper: A detailed analysis of the destructive malware that targeted Ukraine",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 4341537,
	"plain_text": "HermeticWiper: A detailed analysis of the destructive malware\r\nthat targeted Ukraine\r\nPublished: 2022-12-04 · Archived: 2026-04-05 19:58:58 UTC\r\nThis blog post was authored by Hasherezade, Ankur Saini and Roberto Santos\r\nDisk wipers are one particular type of malware often used against Ukraine. The implementation and quality of\r\nthose wipers vary, and may suggest different hired developers.\r\nThe day before the invasion on Ukraine by Russian forces on February 24, a new data wiperwas found to be\r\nunleashed against a number of Ukrainian entities. This malware was given the name “HermeticWiper” based on a\r\nstolen digital certificate from a company called Hermetica Digital Ltd.\r\nThis wiper is remarkable for its ability to bypass Windows security features and gain write access to many low-level data-structures on the disk. In addition, the attackers wanted to fragment files on disk and overwrite them to\r\nmake recovery impossible.\r\nAs we were analyzing this data wiper, other researchhas come out detailing additional components were used in\r\nthis campaign, including a worm and typical ransomware thankfully poorly implemented and decryptable.\r\nArticle continues below this ad.\r\nWe obtained samples and in this post we will take apart this new malware.\r\nBehavioral analysis\r\nFirst, what we see is a 32 bit Windows executable with an icon resembling a gift. It is not a cynical joke of the\r\nattackers, but just a standard icon for a Visual Studio GUI project.\r\nIt has to be run as Administrator in order to work, and does not involve any UAC bypass techniques. As we will\r\nlater find out, the name of the sample also (slightly) affects its functionality; if the name starts with “c” (or “C”, as\r\nit is automatically converted to lowercase) the system will also reboot after execution.\r\nOnce run, the sample works silently in the background. For several minutes we may not notice anything\r\nsuspicious.\r\nhttps://blog.malwarebytes.com/threat-intelligence/2022/03/hermeticwiper-a-detailed-analysis-of-the-destructive-malware-that-targeted-ukraine/\r\nPage 1 of 33\n\nOnly if we watch the sample using tools like Process Explorer, we can notice some unusual actions. It calls\r\nvarious IOCTLs, related to retrieving details about the disks:\r\n…including  FSCTL_GET_RETRIEVAL_POINTERS and\r\nFSCTL_MOVE_FILE\r\nwhich can remind of files defragmentation*.\r\n[*] Note, that at the low-level, files may not be kept in a filesystem in one continuous chunk (as we see them at\r\nhigh-level), but in multiple chunks, stored in the various sectors of the disk. Defragmentation is related to\r\nconsolidating those chunks, and fragmentation – to splitting them.\r\nHowever, further examination has shown that the effect here is the opposite of defragmentation. In fact, the data\r\ngets more fragmented as a result of the malware execution.\r\nThe disk status regarding data fragmentation, before and after the malware execution, can be checked in the\r\nfollowing images:\r\nhttps://blog.malwarebytes.com/threat-intelligence/2022/03/hermeticwiper-a-detailed-analysis-of-the-destructive-malware-that-targeted-ukraine/\r\nPage 2 of 33\n\nThis is probably made in order to escalate the created damage: the more fragmented the file is, the more difficult it\r\nis to carve it out from the raw disk image, and reconstruct it forensically.\r\nAs the execution progresses, at some point, we may realize that some applications stopped working. It is because\r\nof the fact that some files, including system DLLs, have been overwritten with random data.\r\nExample: an application failed to run because of a system DLL being trashed:\r\nhttps://blog.malwarebytes.com/threat-intelligence/2022/03/hermeticwiper-a-detailed-analysis-of-the-destructive-malware-that-targeted-ukraine/\r\nPage 3 of 33\n\nIf we now view the raw image of the disk (i.e. using HxD), we can notice that some sectors have been also\r\noverwritten with random data:\r\nNot surprisingly, on reboot our Windows OS will no longer work:\r\nhttps://blog.malwarebytes.com/threat-intelligence/2022/03/hermeticwiper-a-detailed-analysis-of-the-destructive-malware-that-targeted-ukraine/\r\nPage 4 of 33\n\nBut what exactly happened underneath? Let’s have a closer look…\r\nUsed components\r\nThe initial sample: 1bc44eef75779e3ca1eefb8ff5a64807dbc942b1e4a2672d77b9f6928d292591– comes with\r\nseveral PE files in its resources:\r\nThe names chosen for the resources ( DRV_X64 ,\r\nDRV_X86\r\n,  DRV_XP_X86 ,\r\nDRV_XP_X64\r\n) suggest that they are a version of the same driver, dedicated to different versions of Windows: appropriately 32\r\nor 64 bit version, or a legacy version for Windows XP. Each of them is in compressed form. By checking the\r\ndumped files by the Linux  file command, we can see the following output:\r\nfile DRV_XP_X86DRV_XP_X86: MS Compress archive data, SZDD variant, original size: 13896 bytes\r\nTo find out how they are loaded, we need to have a look at the sample that carries them.\r\nFortunately, the sample is not obfuscated. We can easily find the fragment that is responsible for finding the\r\nappropriate version of the driver:\r\nhttps://blog.malwarebytes.com/threat-intelligence/2022/03/hermeticwiper-a-detailed-analysis-of-the-destructive-malware-that-targeted-ukraine/\r\nPage 5 of 33\n\nThe buffers are then decompressed with the help of the LZMA algorithm:\r\nhttps://blog.malwarebytes.com/threat-intelligence/2022/03/hermeticwiper-a-detailed-analysis-of-the-destructive-malware-that-targeted-ukraine/\r\nPage 6 of 33\n\nThis format of compression is supported by a popular extraction tool, 7zip. We can also make our own decoding\r\ntool, basing on the malware code (example).\r\nAs a result we get 4 versions of legitimate drivers from the EaseUS Partition Master – just as reported by ESET\r\n(source).\r\n2c7732da3dcfc82f60f063f2ec9fa09f9d38d5cfbe80c850ded44de43bdb666d\r\n23ef301ddba39bb00f0819d2061c9c14d17dc30f780a945920a51bc3ba0198a4\r\n8c614cf476f871274aa06153224e8f7354bf5e23e6853358591bf35a381fb75b\r\n96b77284744f8761c4f2558388e0aee2140618b484ff53fa8b222b340d2a9c84\r\nBased on the timestamps in the PE headers, the builds of the drivers are pretty old. Probably they have been stolen\r\nby the attackers from an original, legitimate software bundle. Each of them comes with a Debug directory,\r\nincluding a PDB path. Example:\r\nhttps://blog.malwarebytes.com/threat-intelligence/2022/03/hermeticwiper-a-detailed-analysis-of-the-destructive-malware-that-targeted-ukraine/\r\nPage 7 of 33\n\nDriver overview\r\nThe drivers leveraged by HermeticWiper are part of the Suite from EaseUS, a legitimate software that brings to\r\nthe user disk functionalities like partitioning and resizing. As told, this tool is legitimate so no one was detecting\r\nthe sample in VirusTotal at the time of the attack:\r\nLooking inside the driver, we can see typical functions. The driver creates the required device and establishes\r\nsome Dispatch Routines, as can be seen in the following image:\r\nhttps://blog.malwarebytes.com/threat-intelligence/2022/03/hermeticwiper-a-detailed-analysis-of-the-destructive-malware-that-targeted-ukraine/\r\nPage 8 of 33\n\nThe internals of the driver are quite straightforward. In order to access the driver from usermode we need to\r\nuse  CreateFile API function and the name of the device under which the driver was installed (\r\n\\.EPMNTDRV\r\n) along with the partition ID. Example shown below:\r\nThis string is important to understand the driver capabilities. As you can see, this drivers code will convert this\r\nsent string from usermode to integer and will use that integer as an input to the `saveReferenceHardDisk` helper\r\nfunction. As it can be extracted from the images, this helper function will save a reference to the physical disk\r\n(DeviceHarddisk[num]Partition0) in FsContext attribute:\r\nhttps://blog.malwarebytes.com/threat-intelligence/2022/03/hermeticwiper-a-detailed-analysis-of-the-destructive-malware-that-targeted-ukraine/\r\nPage 9 of 33\n\nThis behaviour can has been tested also in real time. We can see how the leading backslash is removed prior to\r\nconvert this value to integer type:\r\nIRP_MJ_CREATE function will save a Device Object pointer for the hard disk in FsContext2 attribute, returned\r\nby getDeviceObject helper function. The DeviceObject pointer in getDeviceObject is used to find\r\nIRP_MJ_CREATE function will save a Device Object pointer for the hard disk in FsContext2 attribute (returned\r\nby getDeviceObject helper function). The DeviceObject pointer in getDeviceObject is used to find the disk.sys\r\nassociated device object by traversing to the lowest device object leveraging IoGetLowerDeviceObject function.\r\nTo confirm that the lower device object is indeed the one we are looking for we check the ServiceKeyName of the\r\nobject with “Disk” which indicates that its looking for the disk.sys object as the ServiceKeyName for that object is\r\n“Disk”. These objects will be used later in read and write operations. That means that, when different operations\r\nare requested to the driver from usermode, the real operation will be performed over the machine physical disks.\r\nhttps://blog.malwarebytes.com/threat-intelligence/2022/03/hermeticwiper-a-detailed-analysis-of-the-destructive-malware-that-targeted-ukraine/\r\nPage 10 of 33\n\nNext images show how the driver builds the incoming requests and forwards them to the lower level devices:\r\nhttps://blog.malwarebytes.com/threat-intelligence/2022/03/hermeticwiper-a-detailed-analysis-of-the-destructive-malware-that-targeted-ukraine/\r\nPage 11 of 33\n\nBy using FsContext2 field saved by a CreateFile operation performed from usermode, this driver could be seen\r\nas a proxy driver where IRPs are handled by underlying devices. In a nutshell, this legitimatedriver lets the\r\nattackers bypass some windows security mechanisms which would ideally be forbidden from usermode such as\r\nwriting to certain sectors of the raw disk.\r\nImplementation of the Wiper\r\nThis malware is designed to maximize damage done to the system. It does not only overwrite the MBR, but goes\r\nfurther: walking through many structures of the filesystem and corrupting all of them, also trashing individual\r\nfiles.\r\nWe know that this executable is going to somehow abuse those drivers in order to implement the wiper\r\nfunctionality. Yet, the question arises, how exactly is it implemented?\r\nIt is worth to note that Windows (since Vista) introduced limitations, thanks to which only the sectors at the\r\nbeginning of the disk can be written to from usermode (with the help of the standard windows drivers). If we want\r\nto write to further sectors, i.e. overwrite MFT (Master File Table) we need some custom workarounds. (More\r\nexplanation given here.)\r\nIn case of Petya(as well as NotPetya, which used the same component), this workaround was implemented by an\r\nalternative “kernel” that was booting (instead of Windows) on machine restart, and doing the overwrite. In case of\r\nthe HermeticWiper, the authors decided for an easier way: they used another driver, that was able to do such\r\noverwrites.\r\nFirst, the malware parses NTFS structures, and stores information about them in the internal structures. For\r\nimplementing the reads, standard system devices being used. After the needed data is collected, the additional\r\n(EaseUS) driver comes into play: it is used as a proxy to writeinto the collected sectors.\r\nThe attack can be divided into several phases:\r\n1. Preparation, including:\r\nInstallation of the additional driver (EaseUS)\r\nDisabling system features that may help in recovery, or in noticing of the attack\r\nhttps://blog.malwarebytes.com/threat-intelligence/2022/03/hermeticwiper-a-detailed-analysis-of-the-destructive-malware-that-targeted-ukraine/\r\nPage 12 of 33\n\n2. Data collection: walking through NTFS structure, collecting sectors and files that are going to be\r\noverwritten. Also, the random data of appropriate size is generated for the further overwrite.\r\n3. Trashing (at this stage the EaseUS driver is utilized): the collected sectors are being overwritten by the\r\npreviously generated random data\r\nAt the end, the system may be automatically rebooted.\r\nExecution flow\r\nLet’s now have a look at the malware sample, to see how those phases are implemented in detail.\r\nPreparations\r\nFirst the sample parses command line arguments. They will have minor impact on the execution – may just alter\r\nhow long the sample is going to sleep between the execution of the particular phases.\r\nThen, the sample proceeds to set privileges that are needed in order to execute the actions that are going to be\r\nperformed. Two privileges are being set in the main function of the malware:  SeShutdownPrivilege (that allows\r\nto reboot the system) and\r\nSeBackupPrivilege\r\n(that allows to manipulate system backups):\r\nhttps://blog.malwarebytes.com/threat-intelligence/2022/03/hermeticwiper-a-detailed-analysis-of-the-destructive-malware-that-targeted-ukraine/\r\nPage 13 of 33\n\nHere comes and interesting twist: the string defining  SeShutDownPrivilege is composed on the stack, and one\r\nchunk in between is missing:\r\nThis missing chunk  wnPr is then being filled at the position that is calculated depending on the first character of\r\nthe current executable name. Due to this, the string becomes complete (and the privilege is set properly) only in\r\nthe case if the sample has a name starting from “c”.\r\nThe reason why the authors decided for such unusual alteration of the flow is not sure. It may be just to obfuscate\r\nthis particular, suspicious string. It is also common for malware authors to use a name check as an anti-sandbox\r\ntechnique (since sandboxes may assign to samples some predictable names: in the case if such name was detected,\r\nsample may exit, so that its behavior cannot be tracked by the Sandbox). However, here the change in the sample\r\nbehavior is very minor – it affects only the reboot functionality, not the main mission of the malware.\r\nDriver Installation\r\nAfter that, the malware proceeds to the installation of the driver:\r\nThe installation function takes several steps.\r\nhttps://blog.malwarebytes.com/threat-intelligence/2022/03/hermeticwiper-a-detailed-analysis-of-the-destructive-malware-that-targeted-ukraine/\r\nPage 14 of 33\n\nFirst, the system is fingerprinted, so that the malware can select the most appropriate version of the driver to be\r\nused. Depending on the Windows version, and the bitness (32 or 64 bit), the resource is selected.\r\nBefore installing the driver, the crash dump mechanism is being disabled:\r\nCrash Dumps are usually being made if the full system crashes, possibly because of a bug/instability in a driver.\r\nThey contain information about the full status of the system, and on what exactly happen, in order to help\r\ndebugging. Disabling crashes before the installation suggests that the authors of the malware have some level of\r\ndistrust in the used drivers, or believe that the executed operation posses some risk of crashing the system. That’s\r\nwhy they want to be extra sure that if it eventually happens, the Administrators will have a harder time to find the\r\nreason.\r\nThen, they check if the driver is already installed. They do it by sending there and IOCTL, that is supposed to\r\nretrieve information about the drive geometry. If this operation has failed, it means the driver is not there, and they\r\ncan proceed with the installation.\r\nhttps://blog.malwarebytes.com/threat-intelligence/2022/03/hermeticwiper-a-detailed-analysis-of-the-destructive-malware-that-targeted-ukraine/\r\nPage 15 of 33\n\nThe installation is done by first generating a pseudorandom, 4-character long name for the driver, from the\r\nhardcoded charset. The function also makes sure that the file with the generated name does not exist yet.\r\nThen, the compressed version of the file is being dropped. And finally, the driver is decompressed from it.\r\nThe decompressed driver is installed as a service:\r\nhttps://blog.malwarebytes.com/threat-intelligence/2022/03/hermeticwiper-a-detailed-analysis-of-the-destructive-malware-that-targeted-ukraine/\r\nPage 16 of 33\n\nAt this point, the newly dropped files are also added to the structures that will be further passed to the wiping\r\nfunctions – so that the files can be overwritten at low level. More about it is described in section “Data\r\ncollection”.\r\nThe installation function (denoted as  create_driver_svc ) first enables yet another privilege:\r\nSeLoadDriverPrivilege\r\n(which is required to allow loading drivers):\r\nThen the driver is added as a system service, and started:\r\nThis triggers execution of the  DriverEntry function, and since that point, the driver is residing in memory.\r\nAfter the successful installation, the registry keys related to the service, as well as the dropped files, are deleted, to\r\nmake the new driver more difficult to spot:\r\nhttps://blog.malwarebytes.com/threat-intelligence/2022/03/hermeticwiper-a-detailed-analysis-of-the-destructive-malware-that-targeted-ukraine/\r\nPage 17 of 33\n\nWe must note, that file deletion does not interfere in the functionality of the driver. It is still loaded in memory (till\r\nthe next reboot) and will be available for the further use.\r\nDisabling shadow copies\r\nIt is a common action done by ransomware to delete shadow copies. It is supposed to destroy system backups, and\r\nparalyze the recovery. In this case, we can see the sample disabling the Shadow copy Service:\r\nData Fragmentation\r\nDuring our analysis, we noticed that the malware fragments the files present on the disk (as opposite of\r\ndefragmentation).\r\nBefore the fragmentation routine, it changes some settings related to explorer:\r\nhttps://blog.malwarebytes.com/threat-intelligence/2022/03/hermeticwiper-a-detailed-analysis-of-the-destructive-malware-that-targeted-ukraine/\r\nPage 18 of 33\n\nThis is probably to hide the information about the file status to the user, to keep them in blind for as long time as\r\npossible.\r\nBelow function shows how the fragmentation routine is executed:\r\nThe standard windows directories are being excluded:\r\nThis can be done both to save time (by not corrupting standard files), and to avoid the interference with system\r\nstability.\r\nThe file fragmentation process can be seen in next images:\r\nhttps://blog.malwarebytes.com/threat-intelligence/2022/03/hermeticwiper-a-detailed-analysis-of-the-destructive-malware-that-targeted-ukraine/\r\nPage 19 of 33\n\nThe fragmentation algorithm implementation is achieved by using different IOCTL_CODES (FSCTL) as\r\nFSCTL_GET_RETRIEVAL_POINTERS and FSCTL_GET_MOVE_FILES. The code looks pretty similar to a\r\ndefragmentation code. But in this case, is being modified in order to fragment, where file chunks are splitted and\r\nmoved to free clusters in the disk.\r\nData collection\r\nAfter those preparations, malware enters the second stage of the execution: data collection. In casual ransomware\r\ncases, we may see sometimes that prior to the encryption, malware iterates through various directories, and makes\r\na list of files that it is going to attack. This case is analogous, but much more interesting, because the authors\r\niterate not through directories (at high level, using windows API), but at low level, through NTFS file system,\r\nreading various structures and parsing them manually. To enumerate them, they send IOCTLs through standard\r\nWindows devices (the newly installed driver is not used yet).\r\nhttps://blog.malwarebytes.com/threat-intelligence/2022/03/hermeticwiper-a-detailed-analysis-of-the-destructive-malware-that-targeted-ukraine/\r\nPage 20 of 33\n\nData storage\r\nThe output of this parsing is stored in custom structures which we managed to reconstruct, and defined in the\r\nfollowing way:\r\nstruct elemStr{ elemStr *fLink; elemStr *bLink; chunkStr *chunkPtr; DWORD diskNumber; BYTE *randomBuf\r\nThey both are linked lists.\r\nThe first one  elemStr defines the element that will be overwritten. Its size is retrieved, and the random buffer\r\ndedicated for its overwrite is generated:\r\nThe “chunk” represents a continuous block of physical addresses to be overwritten.\r\nSo in general, the malware will use these structures in a 2 step process. First step will collect all the data. The\r\nsecond step will wipe this data, using the previous created structure.\r\nCollected elements\r\nAs seen before, these structures will be sent to functions that will perform the data corruption, at a very low level.\r\nThe elements that are collected for later destruction are presented below.\r\nhttps://blog.malwarebytes.com/threat-intelligence/2022/03/hermeticwiper-a-detailed-analysis-of-the-destructive-malware-that-targeted-ukraine/\r\nPage 21 of 33\n\nOwn executable and the dropped drivers\r\nWe have seen that the attackers were interested in cleaning their trace. To accomplish that, they will delete their\r\nown executable from disk, even tough the binary itself keeps running and in memory. As any other task performed\r\nin the filesystem by HermeticWiper, the way of deleting their binary is slightly different as other malwares do. The\r\nattackers first manage to find which offset the binary occupies in raw, and finally they will overwrite that specific\r\noffset.\r\nThe dropped files (compressed and uncompressed driver) were added to the same structure, just after the the\r\ninstallation.\r\nThe Boot Sector\r\nOne of the attackers motivation is making devices incapable of loading the OS. The first step followed is\r\nenumerating all physical devices, as well as partitions. For that, a simple loop is used that tries to open a handle to\r\nHardDisk[num], where num is iterated from 0 to 100:\r\nAll this information is then stored into a  elemStr structure that contains data as the disk number. In this case,\r\nchunkElement will describe raw addresses of boot sectors. In that regard, an especial mention is made to\r\nC:System Volume Information\r\n. The attackers will add to boot_sectors structure this folder contents:\r\nAccording to Microsoft, “The Mount Manager maintains the Mount Manager remote database on every NTFS\r\nvolume in which the Mount Manager records any mount points defined for that volume. The database file resides\r\nin the directory System Volume Information on the NTFS volume” (Windows Internals, 6th edition). So this\r\nhttps://blog.malwarebytes.com/threat-intelligence/2022/03/hermeticwiper-a-detailed-analysis-of-the-destructive-malware-that-targeted-ukraine/\r\nPage 22 of 33\n\ntechnique is also created for increasing damage. Finally, all these collected offsets will be overwritten as the\r\nmalicious binary was, leveraging the EasyUS driver.\r\nReserved Sectors and MFT\r\nAs before, the malware will brute-force again against the PhysicalDrive ID to find valid drive IDs. Then it uses\r\nIOCTL_DISK_GET_DRIVE_LAYOUT_EX to retrieve information about all the primary partitions present on the\r\ndrive and reads the first sector from that partition. Other information required to read one sector from the disk is\r\nretrieved by using the IOCTL_DISK_GET_DRIVE_GEOMETRY_EX.\r\nOnce the first sector of a partition is read then the callback function passed by the malware is invoked on this\r\nsector.\r\nhttps://blog.malwarebytes.com/threat-intelligence/2022/03/hermeticwiper-a-detailed-analysis-of-the-destructive-malware-that-targeted-ukraine/\r\nPage 23 of 33\n\nDepending on the filesystem type if its FAT then it wipes all the Reserved Sectors, the boot record sectors in FAT\r\nfilesystem are part of Reserved Sectors. In case of NTFS the malware wipes the MFT and MFTMirror (backup\r\nMFT) present on the disk, the purpose of which is to make the recovery of the data harder.\r\nhttps://blog.malwarebytes.com/threat-intelligence/2022/03/hermeticwiper-a-detailed-analysis-of-the-destructive-malware-that-targeted-ukraine/\r\nPage 24 of 33\n\nEach file on an NTFS volume is represented by a record in a special file called the master file table (MFT). In case\r\nthe MFT becomes corruptible then MFT mirror is read in an attempt to recover the original MFT, whose first\r\nrecord is identical to the first record of the MFT. MFT table is the index on which the filesystem relies, having\r\ninformation like where a file resides. Without MFT, the system will be unable to know were folders and files are,\r\nor modification dates, etc. \r\nBitmap and LogFile\r\nIn an attempt to hinder the recovery, Bitmap and LogFile are overwritten as well for all the logical drives present\r\non the system. The logical drives are retrieved by GetLogicalDriveStringsW in this case. These structures are also\r\nimportant when doing recovery and postmortem investigation. $Bitmap contains information about free and\r\noccupied clusters and $Logfile contains a log of transactions that happened in the filesystem.\r\nAlso user files will be impacted by data destruction. We have discovered that the malware will overwrite as well\r\nalmost everything inside C:/Documents and settings. In modern Windows, Documents and Settings will point to\r\nC:/Users. This folder contains users data folders (for example, My Documents or Desktop are located in these\r\nhttps://blog.malwarebytes.com/threat-intelligence/2022/03/hermeticwiper-a-detailed-analysis-of-the-destructive-malware-that-targeted-ukraine/\r\nPage 25 of 33\n\nfolders). Some files are skipped in this process, as the ones under APPDATA but in general, every file that is\r\ncontained under these folders will be overwritten.\r\nCollecting clusters to erase the whole disk\r\nThe final part of the data collection is to get information required to wipe all the occupied clusters on the disk. To\r\nget this information the malware uses FSCTL_GET_VOLUME_BITMAP IOCTL which gives us information\r\nabout all the occupied and free clusters on the disk. The malware traverses all the logical disks and uses\r\nFSCTL_GET_VOLUME_BITMAP to retrieve the bitmap, every bit in the bitmap denotes a cluster, a value of 1\r\nimplying that the cluster is occupied and 0 meaning that the cluster is free. The bitmap retrieved with the IOCTL\r\nis traversed bit by bit and all the occupied clusters are added to the wiping structure which is described above in\r\nthe post, one thing to note here is that malware combines all the contiguous clusters and these contiguous multiple\r\nclusters are denoted by a single chunk structure opposed to earlier usages where one chunk structure denoted a\r\nsingle cluster.\r\nFinally, all occupied clusters will be collected in a  elemStr typed structure for its destruction.\r\nHow is this all performed?\r\nThrough the entire post its been told that some NTFS properties (like attributes, indexes, etc) are being used in\r\norder to collect data, that will be wiped after. We will like to show an example of how attackers implemented that\r\nfunctionality and show the level of sophistication.\r\nFor that, we will take as example the code responsible in collecting the Windows log files:\r\nAfter this call, some data structures are filled, containing data regarding physical disk properties and the folder\r\nname itself. Our first reference to the NTFS filesystem is found in the way that the HANDLE is retrieved. This\r\nhttps://blog.malwarebytes.com/threat-intelligence/2022/03/hermeticwiper-a-detailed-analysis-of-the-destructive-malware-that-targeted-ukraine/\r\nPage 26 of 33\n\nfolder is opened as a NTFS stream:\r\nEventually, the code will reach the following point. The first call will parse $INDEX_ROOT attribute, and the\r\nfunctionality is relatively similar and simpler than the second one, where $INDEX_ALLOCATION attribute is\r\nused. Additional information about these NTFS attributes can be found here. We will assume that the list of\r\nelements is long enough to have an $INDEX_ALLOCATION and we will deep into this call:\r\nIt is important to have in mind the parameters sent for a better understanding of the whole process. First two\r\nparameters (nFileIndexLow and nFileIndexHigh) are used for calling the\r\nfunction FSCTL_GET_NTFS_FILE_RECORD, which will retrieve a NTFS record. After some checks (for\r\nexample, the magic value), we will pop out in a function that we have called callback_when_attribute_is_found.\r\nNote that the first parameter sent to this function will be the $INDEX_ALLOCATION (0x20) value that was\r\npreviously sent:\r\nWhat this function will do is to iterate through all NTFS attributes that are part of the record. To do that, the code\r\nwill have to find the offset to the first attribute. This offset is just 2 bytes long, as is relative to the structure. The\r\nlayout of the header is demonstrated below:\r\nhttps://blog.malwarebytes.com/threat-intelligence/2022/03/hermeticwiper-a-detailed-analysis-of-the-destructive-malware-that-targeted-ukraine/\r\nPage 27 of 33\n\nA NTFS File record will follow this structure:\r\nRecord Header\r\nAttribute\r\nAttribute\r\nAttribute\r\nNTFS record layout\r\nIf we still remember the $INDEX_ALLOCATION (0x20), it becomes handy now. Attributes will start with a\r\nspecific TypeCode, as $INDEX_ALLOCATION is. So, if one of the attributes matches the selected type that was\r\nrequired, the first callback function (the one sent steps before as a parameter) will be triggered:\r\nhttps://blog.malwarebytes.com/threat-intelligence/2022/03/hermeticwiper-a-detailed-analysis-of-the-destructive-malware-that-targeted-ukraine/\r\nPage 28 of 33\n\nIn the case there is not matching TypeCode but an $ATTRIBUTE_LIST is found, that will mean that exists more\r\nattributes, but these cannot fit into $MFT table. In this rare case, the malware will continue processing these extra\r\nattributes and will call recursively the first function.\r\nLets check what this callback will do. Remember that this callback function, in our case\r\nis indexAllocation_Callback_CollectAllfiles. The first step will be recovering the stream that this attribute points\r\nto. As $INDEX_ALLOCATION is an attribute meant for directories, makes sense this stream being an index array\r\n(block indexes):\r\nAs this is an index array, these indexes will point to something. This something is, as you would imagine, NTFS\r\nrecords. In raw disk, these type of indexes look like that:\r\nAs indexes point to records, all of these records will be sent, recursively, once more to the initial function. But this\r\ntime the callback function will be different, also the typecode:\r\nhttps://blog.malwarebytes.com/threat-intelligence/2022/03/hermeticwiper-a-detailed-analysis-of-the-destructive-malware-that-targeted-ukraine/\r\nPage 29 of 33\n\nSo this time, every record sent will behave differently. $DATA attributes will be looked for instead of\r\n$INDEX_ALLOCATION ($DATA contains file data). Also, the executed callback function will be different\r\n(named now dataExecuting). By using the disk properties that were sent in the first call combined with\r\ninformation gathered from indexes, this callback will locate the exact location of the file in disk. The last step for\r\nthese files, as for all the ones that we have summarized in this report is being added as a member to a  elemStr *\r\nstructure. The offsets contained in this structures, as stated, will be overwritten by the malware in the last steps:\r\nData overwriting\r\nFinally, after all data is collected, the malware starts overwriting. The  elemStr structure is passed into the\r\nfunction, and all the elements on the linked list are being processed:\r\nhttps://blog.malwarebytes.com/threat-intelligence/2022/03/hermeticwiper-a-detailed-analysis-of-the-destructive-malware-that-targeted-ukraine/\r\nPage 30 of 33\n\nThe overwriting function uses the installed driver in order to gain the write access to the sectors. It opens the\r\ndevice, and then walks through all the collected chunks, by their offsets. It uses  WriteFile to fill it with the\r\npreviously prepared, random data.\r\nhttps://blog.malwarebytes.com/threat-intelligence/2022/03/hermeticwiper-a-detailed-analysis-of-the-destructive-malware-that-targeted-ukraine/\r\nPage 31 of 33\n\nExample below shows a fragment of a log from our experiments, when we dumped the content of particular\r\nstructures during malware execution: first data collection, and then usage of the filled structures to wipe out the\r\nsectors on the disk:\r\nConclusion\r\nAs can be seen, by leveraging legitimate but flawless signed code, the attackers are capable of bypassing some\r\nWindows security mechanisms. This is extremely harmful because user applications are not meant to have this\r\nlevel of control in kernel space, for security reasons.\r\nAlso, we would like to state that recovery in this case is complicated. The attackers first fragment files on disk,\r\nand finally, will overwrite all of these fragments. Even without the last step (indiscriminate disk trashing), the\r\nhttps://blog.malwarebytes.com/threat-intelligence/2022/03/hermeticwiper-a-detailed-analysis-of-the-destructive-malware-that-targeted-ukraine/\r\nPage 32 of 33\n\ncombination of fragmentation and wiping of required structures (like $MFT) would be enough to make recovery\r\nalmost impossible.\r\nOur final thoughts are about the special focus that cybercriminals put in hiding their tracks. Maybe, that part is the\r\nfinal stage of a bigger operation. In fact, ESET recently described other related artifacts here, and they connect\r\nthem to the same actor and campaign. Being part of a bigger picture can explain why attackers are so much\r\ninterested in corrupting files like $LogFile and Windows events.\r\nMalwarebytes detects this disk wiper as Trojan.HermeticWiper.\r\nSource: https://blog.malwarebytes.com/threat-intelligence/2022/03/hermeticwiper-a-detailed-analysis-of-the-destructive-malware-that-targeted\r\n-ukraine/\r\nhttps://blog.malwarebytes.com/threat-intelligence/2022/03/hermeticwiper-a-detailed-analysis-of-the-destructive-malware-that-targeted-ukraine/\r\nPage 33 of 33",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA",
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://blog.malwarebytes.com/threat-intelligence/2022/03/hermeticwiper-a-detailed-analysis-of-the-destructive-malware-that-targeted-ukraine/"
	],
	"report_names": [
		"hermeticwiper-a-detailed-analysis-of-the-destructive-malware-that-targeted-ukraine"
	],
	"threat_actors": [],
	"ts_created_at": 1775434163,
	"ts_updated_at": 1775826743,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/9915fd7be2b4a858e134002d5af8315da7662b40.pdf",
		"text": "https://archive.orkl.eu/9915fd7be2b4a858e134002d5af8315da7662b40.txt",
		"img": "https://archive.orkl.eu/9915fd7be2b4a858e134002d5af8315da7662b40.jpg"
	}
}