Even the Most Advanced Malware Analysis Environment could potentially be Circumvented by a Sufficiently Advanced Attacker
From a technology perspective, it has never been a better time to be in the cyberattack business. Thanks to the common availability of attack tools in the underground marketplace, today’s adversaries don’t require the technical know-how to develop malware. Instead, they can simply rent exploit kits, botnets and other tools they need for the duration of the attack, or even leverage the attack-as-a-service model and simply hire someone to conduct the attack for them. In addition to this “democratization” of tools, one of most concerning developments in malicious techniques has been the development of threats that can avoid detection in virtual machine (VM) analysis environments.
I’m referring to VM-aware malware. If you’re not familiar with the concept, a quick definition is in order. To discover unknown malware, security providers have created systems that detonate the sample in a virtual environment to observe its behavior and determine if it is malicious – a technique commonly known as sandboxing. Attackers are incentivized to evade detection. They have developed anti-VM analysis techniques to allow the malware to recognize when it is being run on a virtual machine and fail to execute, meaning the system or threat analytics cannot make a verdict determination or extract intelligence from the sample.
Complicating the anti-VM analysis problem is the fact that nearly every virtual environment created by security vendors is based on the same common open-source code, as seen in the VENOM vulnerability (CVE-2015-3456). This has allowed cyberattackers to commoditize evasion by creating one malware sample that can sidestep detection by all major providers. For example, an analysis of the Furtim malware family revealed that it looks at more than 400 different attributes to determine if it’s actually being activated on the target network or a virtual machine.
In light of this, organizations need to conduct some due diligence before selecting a malware analysis environment. Questions to ask a prospective environment vendor include:
1. What VM evasions do you look for and how do you deal with them?
2. Is your environment based on open-source virtualization components, or was it 100 percent custom-developed?
3. Can you detonate unknown samples on hardware as part of your automated detection workflow?
The answer to the open-source question is particularly important. When the same technology is shared by multiple environments, it allows attackers to write one set of code to evade detection across all of them at once, whereas the cost of an attacker targeting just one will rarely justify the effort required to develop the code.
Another key consideration should be the availability of running suspicious samples on actual hardware systems, as opposed to in a virtual environment. While virtual analysis can be highly effective, even the most advanced environment could potentially be circumvented by a sufficiently advanced attacker, so consider if the system allows for what is commonly called “bare metal” analysis. This capability must be automatically engaged when samples show evidence of evasion, since manually detonating malware on hardware systems would put too high of an operational burden on security teams.
Malware analysis environments can be valuable weapons in the ongoing cybersecurity wars, provided organizations are aware of their limitations. By selecting an environment based on the criteria covered above, security teams can not only better identify and mediate malware but can also handle a much higher malware analysis workload.
