{"id":18430,"date":"2022-03-04T10:10:23","date_gmt":"2022-03-04T18:10:23","guid":{"rendered":"http:\/\/www.palada.net\/index.php\/2022\/03\/04\/news-12163\/"},"modified":"2022-03-04T10:10:23","modified_gmt":"2022-03-04T18:10:23","slug":"news-12163","status":"publish","type":"post","link":"http:\/\/www.palada.net\/index.php\/2022\/03\/04\/news-12163\/","title":{"rendered":"HermeticWiper: A detailed analysis of the destructive malware that targeted Ukraine"},"content":{"rendered":"

Credit to Author: Threat Intelligence Team| Date: Fri, 04 Mar 2022 17:18:26 +0000<\/strong><\/p>\n

This blog post was authored by Hasherezade, Ankur Saini and Roberto Santos<\/em><\/p>\n

Disk wipers are one particular type of malware often used against Ukraine. The implementation and quality of those wipers vary, and may suggest different hired developers.<\/p>\n

The day before the invasion of Ukraine by Russian forces on February 24, a new data wiper<\/a> was unleashed against a number of Ukrainian entities. This malware was given the name “HermeticWiper” based on a stolen digital certificate from a company called Hermetica Digital Ltd.<\/p>\n

This 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 make recovery almost impossible.<\/p>\n

As we were analyzing this data wiper, other research<\/a> has come out detailing additional components were used in this campaign, including a worm and typical ransomware thankfully poorly implemented<\/a> and decryptable.<\/p>\n

We obtained samples<\/a> and in this post we will take apart this new malware.<\/p>\n

Behavioral analysis<\/h2>\n

First, what we see is a 32 bit Windows executable with an icon resembling a gift. It is not a cynical joke of the attackers, but just a standard icon for a Visual Studio GUI project.<\/p>\n

\n
\"Icon
Icon used by HermeticWiper<\/em><\/figcaption><\/figure>\n<\/div>\n

It has to be run as Administrator in order to work, and does not involve any UAC bypass techniques. As we will later find out, the name of the sample also (slightly) affects its functionality; if the name starts with “c” (or “C”, as it is automatically converted to lowercase) the system will also reboot after execution.<\/p>\n

Once run, the sample works silently in the background. For several minutes we may not notice anything suspicious. <\/p>\n

Only if we watch the sample using tools like Process Explorer, we can notice some unusual actions. It calls various IOCTLs, related to retrieving details about the disks:<\/p>\n

\n
\"Example<\/a>
Example of actions performed by HermeticWiper, seen in ProcessMonitor<\/em><\/figcaption><\/figure>\n<\/div>\n

…including FSCTL_GET_RETRIEVAL_POINTERS<\/span><\/a><\/code> and FSCTL_MOVE_FILE<\/span><\/a><\/code> which can remind of files defragmentation<\/a>*. <\/p>\n

[*] Note, that at the low-level, files may not be kept in a filesystem in one continuous chunk (as we see them at high-level), but in multiple chunks, stored in the various sectors of the disk. Defragmentation is related to consolidating those chunks, and fragmentation – to splitting them.<\/em><\/p>\n

\"\"<\/a><\/figure>\n

However, further examination has shown that the effect here is the opposite of defragmentation. In fact, the data gets more fragmented as a result of the malware execution.<\/p>\n

The disk status regarding data fragmentation, before and after the malware execution, can be checked in the following images:<\/p>\n

\n
\"\"
Disk status before fragmentation<\/em><\/figcaption><\/figure>\n<\/div>\n
\n
\"Disk
Disk status after fragmentation<\/em><\/figcaption><\/figure>\n<\/div>\n

This is probably made in order to escalate the created damage: the more fragmented the file is, the more difficult it is to carve it out from the raw disk image, and reconstruct it forensically.<\/p>\n

As the execution progresses, at some point, we may realize that some applications stopped working. It is because of the fact that some files, including system DLLs, have been overwritten with random data.<\/p>\n

Example: an application failed to run because of a system DLL being trashed:<\/p>\n

\n
\"Example<\/a>
Example of an error caused by the wiper<\/em><\/figcaption><\/figure>\n<\/div>\n

If we now view the raw image of the disk (i.e. using HxD), we can notice that some sectors have been also overwritten with random data:<\/p>\n

\n
\"Sector<\/a>
Sector overwritten by HermeticWiper, seen in HxD<\/em><\/figcaption><\/figure>\n<\/div>\n

Not surprisingly, on reboot our Windows OS will no longer work:<\/p>\n

\n
\"Message<\/a>
Message shown to the user after corruption of data<\/em><\/figcaption><\/figure>\n<\/div>\n

But what exactly happened underneath? Let\u2019s have a closer look\u2026<\/p>\n

Used components<\/h2>\n

The initial sample: 1bc44eef75779e3ca1eefb8ff5a64807dbc942b1e4a2672d77b9f6928d292591<\/a> – comes with several PE files in its resources:<\/p>\n

\n
\"Resources<\/a>
Resources of the malware<\/em><\/figcaption><\/figure>\n<\/div>\n

The names chosen for the resources (DRV_X64<\/code>, DRV_X86<\/code>, DRV_XP_X86<\/code>, DRV_XP_X64<\/code>) suggest that they are a version of the same driver, dedicated to different versions of Windows: appropriately 32 or 64 bit version, or a legacy version for Windows XP. Each of them is in compressed form. By checking the dumped files by the Linux file<\/code> command, we can see the following output:<\/p>\n

file DRV_XP_X86 DRV_XP_X86: MS Compress archive data, SZDD variant, original size: 13896 bytes<\/strong><\/pre>\n
To find out how they are loaded, we need to have a look at the sample that carries them.<\/p>\n
Fortunately, the sample is not obfuscated. We can easily find the fragment that is responsible for finding the appropriate version of the driver:<\/p>\n
\n
\"HermeticWiper<\/a>
HermeticWiper selecting which driver will load<\/em><\/figcaption><\/figure>\n<\/div>\n
The buffers are then decompressed with the help of the LZMA algorithm:<\/p>\n
\n
\"Code<\/a>
Code responsible of decompress drivers compressed by LZMA algorithm and driver installation<\/em><\/figcaption><\/figure>\n<\/div>\n
This format of compression is supported by a popular extraction tool, 7zip. We can also make our own decoding tool, basing on the malware code (example<\/a>).<\/p>\n
As a result we get 4 versions of legitimate drivers from the EaseUS Partition Master \u2013 just as reported by ESET (source<\/a>).<\/p>\n