HermeticWiper: Behavioral Analysis and Indicators of Attack
On 23 Feb 2022, different cyber threat intelligence services began to witness the usage of a new disk wiper being leveraged against Ukrainian organizations. ESET Research was among the first to tweet out hashes related to the malware. The community named it HermeticWiper after the organization in the digital certificate used to sign the malware.
HermeticWiper comes embedded with four different versions of the same drivers in its resource data. Therefore, we assume the malware will select the appropriate driver based on the host OS version.
Note:
Before going further, know that we aren’t going to do any reverse engineering on the sample as we believe this has been done extensively by now. However, check out the sources at the end for great write-ups on the internal of the malware. Going further, we will look at how the malware interacts with the victim system and different event logs that the system might have generated.
Run As Context
We observed that HermeticWiper needs to be executed in the context of a system administrator. However, when executed as a typical user, the malware remains relatively benign.
However, when run as an Administrator, the wiper generates interesting logs. Below are various activities observed when sandboxed in any.run.
Interesting to note is that the sample used for analysis did not create any network connections during the course of our analysis. This leads us to believe that the sample was never used for any C2 purposes and was meant to be used exclusively to damage IT systems.
Here is a brief overview of the order of events for what the wiper does. Note that these actions all happen within the span of a couple of seconds. If you’re a detection engineer, it might be worth locking onto high entropy driver files created, installed as a service, and executed.
Timeline of Events
HermeticWiper registered different activities in the context of Window’s Event Log. All logs were forwarded to an Elastic stack in our test environment and analyzed in Kibana.
Let's take at each step. First, using Swift on Security’s Sysmon configuration, we get a log like the following.
Not long after, we get the file creations.
After the files are created, HermeticWiper installs the driver into the registry to create a service.
Because it’s a driver service and not a Win32 service, it doesn’t show up in Task Manager or Services.msc despite it running in the background.
At the time of this writing, the registry entry is also missing. It is believed that the registry entry is added specifically to start the service and then is removed by some method that our logging capability doesn’t detect.
After the service is started, the system loads the driver and then disables the Volume Shadow Service to prevent backups.
Tampering with the VSS service is the last event log we received related to HermeticWiper. Based on malware analysis by other threat intelligence, we assume the wiper continues to use the embedded driver to write random data to disk before the system comes offline to instability.
Conclusion
At the end of the day, HermeticWiper is a streamlined piece of Malware, and we can assume variants will be as well. Manual detection of HermeticWiper will most likely not be practical at scale, and if detected that way, the damage is most likely done. An EDR/XDR solution would be best suited to trigger on the high entropy file names like “fndr.sys” or “vfdr.sys” as examined during our analysis.
Additionally, detect and kill any processes that execute file creations in critical file locations that tampers with any backup services. It’s much easier to whitelist a known application than recover your entire organization’s data assuming you have backups.
