Malware that evades detection is nothing new. But in a constantly evolving threat landscape, particularly around targeted attacks, we now see more Environment-Sensitive Malware. This is alternately known as context-aware or environment-aware malware . Not a low carbon footprint variety, but rather malware that is tailored to run only under certain conditions in the computing environment of the intended target. Environment-sensitive malware is also evasive in that it may not execute when being analyzed in a sandbox environment, though this is often a side effect rather than by design. Even when using an undetectable sandbox like VMRay, it may not show its real behavior if expected environment conditions are not met. We’ve got posts on this topic here , here and here . A classic example of environment-sensitive malware was the Conficker worm, which declined to infect Ukrainian machines . One approach to correctly analyze and reliably detect environment-sensitive malware is enabling the user of a sandbox to use his own customized images for analysis. VMRay works independently of the guest configuration and allows the use of gold images and completely customized VM images . However, there are scenarios in which full customization of the analysis environment only helps up to a point when analyzing environment-sensitive malware. One example is the need to analyze targeted attacks that aren’t aiming at your network, e.g., when doing threat intel for a third party or analyzing threat data at scale for signature/IOC generation or research. In those cases, even an advanced sandbox may recognize that the malware is querying the environment settings but may fail to identify dormant functionality and hence will provide incomplete analysis results.
Introducing VMRay Rewind
VMRay already detects such environment checks and can recognize such files as suspicious, even if the malicious payload is not triggered during execution. But that’s not all. We are implementing a powerful feature called VMRay Rewind that not only reliably detects environment-sensitive malware but can automatically determine the necessary environment settings and modify the underlying analysis environment accordingly. With that, the malware is then analyzed once more in the modified environment and the hidden functionality is revealed. We sketched the outlines of this in a previous post on leveraging Intel’s Processor Tracing feature, and we’ve made a lot of progress since. In the following, we go into further detail and describe the power of Rewind . We think you’ll be excited as we are as you read on about the examples and see the screenshots on this very useful upcoming technology. To detect environment-sensitive malware and thus hidden functionality, we combine Intel’s new Processor Tracing Feature with powerful analysis techniques and sophisticated heuristics:
We utilize Processor Tracing information to determine code coverage in memory dumps of the monitored processes, i.e. identify all code locations that have not been executed during analysis.
From these untriggered code locations, we identify the subset of ‘interesting’ functionality, e.g., by discarding error handling routines.
Then we track back execution flow from these ‘interesting’ non-executed code locations to preceding conditional branches that depend on environment settings, e.g., functions that obtain the current time or keyboard layout.
Symbolic execution is then applied to identify paths (conditions) that lead to the hidden functionality.
On these paths we use a solver to generate concrete values to trigger their execution.
Finally, we reanalyze the sample and make sure that all environment queries result in the values needed to reach the hidden functionality.
Note that all (!) steps are performed completely autonomously. There is no user interaction required to: a) Identify hidden functionality b) Determine required environment conditions c) Rerun analysis in a modified environment including required conditions
Automatic Analysis of Environment Sensitive Malware
Let’s take a look at a malware file that executes malicious functionality only if it is executed within a certain time period. After initial analysis, VMRay Analyzer automatically combines the collected Tracing information with the created memory dumps. Note that the dumps not only include the process images, which often resemble the unpacked representation of a binary executable, but optionally all heap and stack memory. For better illustration we apply a script that automatically taints the IDA disassembler output according to the collected tracing data. Figure 1 shows this tainted IDA view. You can easily see how:
The malware retrieves the current date and time by calling the GetSystemTime() API.
It then compares the current month vs. 0x0B (November ) and the current year against 0x7da (2010).
Since the expected date is not met, the malware then immediately terminates by calling the ExitProcess() API.
After the tainting we start the real work: Initially, our algorithm identifies the code sequence starting at loc_40915C, as it has not been reached during the run. It then traces back and identifies the two conditional branches that could have led to the execution of this code. It also identifies the API GetSystemTime as the data source of the branch condition that is checked. Finally, it determines that the MONTH and YEAR fields from the SYSTEMTIME structure are the significant path condition variables. There are two different execution paths that lead to hidden functionality and for both our algorithm determines the specific path conditions:
CASE 1:
path from GetSystemTime at address 0x75c0d354 reached interesting code sequence at 0x40915C Required conditions: SYSTEMTIME.wMonth 0xa
CASE 2:
path from GetSystemTime at address 0x75c0d354 reached interesting code sequence at 0x40915C Required conditions: SYSTEMTIME.wMonth 0xb SYSTEMTIME.wYear 0x7d9
With this information at hand, VMRay Analyzer reruns the sample within an environment adjusted for each identified path condition. As Figure 4 shows, this delivers a more comprehensive analysis result and more malicious behavior reflected in the total severity score as calculated by the VTI (VMRay Threat Identifier) engine:
Automatic Identification of Indirect Call/Jump Targets
One nice side effect of Rewind is its capability to automatically identify targets of indirect jumps and to enrich the disassembly with such information. This may sound obscure and only of interest for static post processing of VMRay’s output. However, it is a great time saver for digital forensics and deep-dive analysis of relevant APTs. As you can see in figure 5 at “loc_b21be6” there is a “call ecx” instruction. With just static analysis it is rather time consuming, complicated, and often impossible to determine the concrete ecx value, needed to reveal the actual call targets. However, by having Processor Tracing data at hand, it’s easy for VMRay to determine the target. Figure 5 shows the resulting disassembly annotation: there are two call targets, one for each loop iteration: sub_B22164 and sub_B24339.
Summary
Rewind is an awesome way to not only detect environment-sensitive malware as often used in targeted attacks, but also fully analyze them by triggering hidden functionality in a completely automated manner. This is accomplished with minimal performance impact due to the awesome new Processor Tracing functionality. Hypervisor-based malware analysis will benefit in the coming years from many other new virtualization extensions that will be developed by CPU vendors to accelerate cloud computing. Rewind allows us to not only recognize all interaction between monitored malware processes and the system but also inspect executed code at an instruction level if needed. While in practice this is often not necessary and can even be annoying (i.e. because it produces tons of unnecessary data), we may now opt to utilize it in certain scenarios. And in contrast to emulation, this can be realized with almost no performance impact. Awesome!
