A key capability for malware is to prevent or delay analysis, usually by implementing dynamic malware analysis detection and evasion. When successful, this can substantially increase the time the malware can continue in the wild undetected, blocked or remediated. While most in-the-wild evasion techniques are rather simple, there also exist sophisticated detection methods that are hard to spot and even harder to prevent. The simple methods check the registry for known sandbox-related values. More advanced checks examine specific CPU registers or return values of certain CPU instructions, e.g. cpuid. The most sophisticated approaches utilize timing and similar hardware-related side-channels. These can range from simple sleep evasions, the usage of unknown Native APIs, through to directly accessing hardware counters via the rdtsc instruction or involving model-specific registers.
In-the-box Monitoring
Depending on the particular analysis environment, and its underlying infrastructure, it is nearly impossible to prevent detection and evasion completely. If the analyzer operates on the same privilege level as the analyzed piece of malware, it’s basically hopeless. Unfortunately, this is the case with most malware analyzers today, as they perform in-the-box monitoring. If a traditional analyzer is installed and used within a virtual environment, the situation becomes worse. Standard virtual machines cause semantical, timing-related, and environmental differences compared to non-virtualized systems. And these differences can easily be detected and/or exploited by the analyzed malware.
However, we believe VM detection itself becomes more and more irrelevant because today production systems are widely virtualized whether servers or workstations. Nevertheless, the modifications and system differences that are directly caused by the in-the-box monitoring remain exceedingly relevant, because they are unambiguous indicators for an ongoing analysis process.
Out-of-the-box Monitoring
The situation is completely different when the monitoring is done from the outside instead. There are no side-effects and artifacts that can be spotted by the malware on the inside. Such a monitoring approach is called 3rd generation and if it is implemented correctly, there is no single bit modified inside the analysis environment. Therefore, malware is incapable of detecting the analyzer itself. But what if the detection aims at the virtual machine instead of the analyzer itself? Again: we don’t believe it is that important anymore today, but there may be some exceptions in which it is essential for getting a sound analysis for a specific malware that refuses to operate correctly within a virtual environment.
Since VMRay Analyzer is an integral part of the hypervisor it utilizes, it renders existing VM detections useless: all device IDs and descriptions are randomized by it, values inside of critical CPU registers and return values of critical CPU instructions are tweaked, and timer MSRs as well as device I/O timers are under its full control. Through these means, VMRay Analyzer effectively hides the existence of the virtual environment and makes it very hard –impossible in most cases– to detect the VM.
Spotting the VM Detection
As an effect of this hypervisor control, current in-the-wild malware, such as MD5 9437eabf2fe5d32101e3fbf9f6027880 (as described in this blog post), cannot detect the virtual environment when being analyzed in VMRay. Therefore, a comprehensive and sophisticated analysis can be generated quickly without the need to utilize expensive and non-scalable bare metal machines. But not only the malware is incapable of detecting the virtual environment when being analyzed in VMRay Analyzer. Moreover, the analyzer is able to notify the VM detection mechanism instead, and this is a powerful behavior signature for malicious software. The following report extracts show how certain filenames and registry keys are queried to detect the presence of different analyzers.
In summary, our adversaries have moved away from VM detection and can easily bypass user or kernel-mode monitoring and analysis. By implementing dynamic analysis at the hypervisor level, we gain the upper hand against threat actors.
Monitoring Full System Interaction
Most dynamic analyzers maintain a list of known security-relevant APIs and monitor their invocations accordingly. Due to technical restrictions, the possible set and total amount of monitored functions is strictly restricted. In contrast, VMRay is using a complete different methodology and generically monitors all interaction between the analyzed malware and its environment. This results in a comprehensive function log that contains all transitions between the malicious code and any other part of the guest system. It contains all regular API calls, private function calls, and direct system calls. It also covers other control flow, as for example function calls that skip the first instructions of each API. These unaligned calls are used more and more by malware to circumvent hooking-based analysis.
One valuable implication of VMRay’s monitoring methodology is the capability to log all string-related function calls. The following figures contain excerpts from VMRay’s function log for 9437eabf2fe5d32101e3fbf9f6027880. By looking at the particular strings that are used as parameters to the string comparison routine StrCmpNIW, one can easily spot how the VM detection is performed.
