TL;DR
Below, we examine the way Cisco Secure Endpoint's defenses reacted to and evolved with the HermeticWiper malware threat, and draw three operational lessons for the defender:
- Use local controls to override default behavior when necessary.
- Look beyond the initial attack to see the larger picture.
- Use the adversary's behavior for detection and threat response.
Background
HermeticWiper is destructive malware that has recently been observed targeting systems in Ukraine. Please refer to Cisco’s Talos “Threat Advisory: HermeticWiper” blog for a detailed analysis of the malware (https://blog.talosintelligence.com/2022/02/threat-advisory-hermeticwiper.html), as well as general guidance on the ongoing cyberattacks in Ukraine (https://blog.talosintelligence.com/2022/02/current-executive-guidance-for-ongoing.html).
This article takes an in-depth look at HermeticWiper from an endpoint defender’s perspective: how the malware affects endpoints, how the attackers attempt to evade detection and prevention, and how Cisco Secure Endpoint reacts and adapts to such evasion.
Both the attack and defense sides are, of course, constantly evolving, for the simple reason that the attackers do not want to get caught, and so they are always looking for ways to escape detection and to defeat protection measures. The defenses then evolve to deal with the new threats, and the cycle continues, and the more rapidly a defense system can react, the better the outcome will be for the defenders.
In this article, therefore, we will examine both successes and shortcomings as the process develops, to see what lessons can be learned for future iterations.
Several key points about the malware’s behavior to keep in mind from the Talos Threat Advisory include:
- A valid digital certificate signed by a trusted Certificate Authority (CA)
- use of legitimate device drivers from non-malicious software
- use of legitimate software tools (e.g., sdelete)
- disabling Volume Shadow Service (VSS)
How the attack begins, version 1
The following screenshot shows an early iteration of the HermeticWiper attack on a target system running Cisco Secure Endpoint.
The most immediate point of concern is that the initial attack was not blocked. At closer inspection, we see that it was actually detected as malicious, but it was not quarantined as a result. The reason for that discrepancy is that the executable herm.exe is signed by a trusted Certificate Authority (“CA”). Because most detection events that involve legitimately signed executables are in fact false positives, the protection logic in Secure Endpoint contains “guard rails” designed to prevent us from unintentionally damaging a system by quarantining legitimate, maybe even essential components due to such a mistaken detection.
(Please keep in mind that this article is following the evolution of Secure Endpoint’s response over time; the certificate trust has since been revoked, so the quarantine mechanism can function as intended.)
In this iteration, we record the detection, and other things like automatic actions (for example, a forensic snapshot of the system's state) may happen as a result, but the guard rails block our quarantine attempt, and so the attack continues to execute. But before we allow the malware to continue doing its dirty work, let’s pause for a minute to ask what we as defenders should do about this undesirable situation.
Obviously, the main problem is the valid certificate that was used (and misused) to sign the malicious file. Clearly, that certificate should no longer be trusted. And in fact, we’ll take another look at the attack process below once the certificate has been marked as untrusted in Cisco’s intelligence cloud. But suppose that, for whatever reason, there is a time delay between when we become aware that we are under attack by such a method and when the certificate is marked untrusted by Cisco. Is there anything else that could be done?
In the case of Secure Endpoint, the answer is to use a custom block list. Because a custom local rule will override a global one, that will allow other systems that are targeted in the same way to prevent the attack at the initial point of entry.
Lesson 1 for the defender: Use local controls when necessary.
In Secure Endpoint, that means both custom blocklists when something is known to be bad, and customer allow lists to correct any false positives until the erroneous detection can be reported to Cisco and fixed globally.
The attack continues
The second stage of the attack is to extract a device driver from one of four embedded resources and drop it on the target system. In this case, as noted in the Talos blog, the driver is taken from a legitimate system utility, and so of course it is also signed by a trusted certificate – a perfectly legitimate one in this case, and not a stolen or abused one like in the initial stage.
However, while the driver itself is not inherently malicious, the circumstances are unusual enough to arouse suspicion. In fact, this behavior is sufficient to trigger a “suspicious driver creation” threat detection and to terminate the process that was responsible for dropping the driver on disk.
Unfortunately, the driver itself is still present – and remember, this is a perfectly legitimate driver in this case – and so it is still available for the malware to abuse in a subsequent step, namely, to leverage it to damage the filesystem of the target.
Lesson 2 for the defender: Keep looking, beyond the initial event.
In an advanced multi-stage attack, make sure to look beyond the success or failure of a single event. Referring to the MITRE ATT&CK mappings is helpful to understand what an attacker’s overall goal is, and what follow-up steps might be expected next.
We’re not quite done with this iteration yet, though. We definitely have an Indication of Compromise (IOC) from the initial detection event, and Secure Endpoint, therefore, does log a Cloud IOC for the execution of a malicious file. So, even though we were not able to prevent damage to the target in this instance, we at least know what happened so we can prevent the same thing from happening to other systems.
What a difference a cert makes
Now, most of the damage done in the previous description can be traced to a single failure: that unsuccessful quarantine of the original malware, blocked by our guard rail mechanism. Since we clearly should no longer trust a certificate that was used to sign a malicious file, let’s see what happens under the same set of circumstances, but with updated information so we know that the certificate has been compromised or otherwise abused.
Here is what the initial detection event looks like now:
So, now that the signing certificate is no longer fully trusted, the guard rails no longer apply, and therefore the quarantine attempt succeeds, thereby stopping the attack in its tracks.
Now that we have the immediate problem solved, what other information can we extract from this experience, in order to strengthen our defenses?
Leveraging attacker behavior
The actions of an attacker are inherently different from those of normal system users and processes. For example, disabling Volume Shadow Services is a very common step taken by ransomware as well as by wipers, to make recovery more difficult for their targets. So, if we see something trying to interfere in the normal operation of VSS, that could indicate a problem, as seen in the behavioral detection below.
Notice, though, that by the time we see this behavioral detection on one of our systems, it is often too late to protect that particular system – after all, by the time you see harmful behavior, that means that something harmful has already happened.
But what if we had a way to detect the bad behavior somewhere else? That, of course, is the idea behind Cisco Secure Malware Analytics (formerly known as Threat Grid), and all Secure Endpoint customers have access to it. Taking the same malware and submitting it to Secure Malware Analytics produces all the information we need to determine that the sample is indeed malicious.
Lesson 3 for the defender: Use the attacker’s own behavior to help detect and respond.
Anomalous actions like disabling VSS, attempting to evade sandbox detection, using obfuscated command lines or parameters, and so on, all of which are intended to help the attacker hide from detection, can actually turn into a way of helping us find the attacker, as long as we have the context and information to tell what’s normal and what’s not.
Do I see this on any of my other systems?
One final point before the end: When a new detection (or attack) method is developed, that also provides an opportunity to look for similar indications elsewhere in our environment. After all, attacks often travel in groups. It’s a good idea to check for indications of related activity in our other systems. The problem, of course, is that very few of us have extra time to spend on going out and looking for more trouble. That, in turn, means that we need ways to make it faster and easier to conduct those searches.
The Orbital advanced search service that is available to Secure Endpoint customers at the Advantage license tier and higher is helpful here. Searching the catalog of prebuilt queries for “hermetic” shows two useful items.
The first, labeled “windows_eventlogs_driver_loaded”, is well suited to hunting for signs in the event logs of other driver-dropping events similar to what was described above. Also, because the attackers are known to disable crash dumps in order to interfere with forensic analysis, the “windows_registry_crashcontrol” query can be used to find other endpoints that show signs of this technique.
Summing it all up
So, what lessons can we take from this? The main one is this: The bad guys do not want to get caught. Therefore, they are constantly looking for new ways to avoid being detected and blocked. For the defender, this requires constant vigilance and adaptability as the attack and evasion patterns change. Cisco’s security teams and threat researchers are at your side in this fight, helping your defenses to stay up with the latest tricks.
Special thanks to Cisco's Talos Intelligence Group, and especially the Research and Efficacy Team (RET) for their insight and information, and for their tireless efforts to ruin the bad guys' day.
