The Threat of Evasive Malware

Transcription

1 The Threat of Evasive Malware Lastline Labs February 25, 2013 Key Points Malware authors exploit the limited visibility of traditional malware analysis systems (sandboxes) to evade detection Stalling code is a novel evasion technique that delays the malware execution without invoking any system calls, thereby timing out existing sandboxes The problem of evasive code is increasing Introduction The fight against malicious code is an arms race. Whenever defenders introduce novel detection techniques, attackers strive to develop new ways to bypass them. Automated malware analysis systems (or sandboxes) are one of the latest weapons in the defenders arsenal. Such systems execute an unknown malware program in an instrumented environment and monitor their execution. While such systems have been used as part of the manual analysis process for a while, they are increasingly used as core of the detection process. The advantage of the approach is clear: It is possible to identify previously unseen (zero day) malware, as only the observed activity in the sandbox is used for detection. As dynamic analysis systems have become more popular, malware authors have responded by devising evasive techniques to ensure that their programs do not reveal any malicious activity when executed in such an automated analysis environment. Clearly, when malware does not show any unwanted activity during analysis, no detection is possible. Simple evasive techniques have been known for quite a while. For example, malware might check for the presence of a virtual machine, or it might query well-known Windows registry keys or files that reveal a particular sandbox. Other malware authors instructed their malware to sleep for a while, hoping that the sandbox would time out the analysis before anything interesting is happening. Security vendors reacted by adding some counter-intelligence of their own to their systems. They added hooks that would identify cases where malware queries for well-known keys, and they would force a program to wake up after it calls sleep. This approach worked reasonably well for a while, although it is fundamentally reactive in nature. That is, the malware analysis system needs to be manually updated to handle each new, evasive trick. As a result, malware authors who create zero day evasions can bypass detection until the sandbox is upgraded. Unfortunately, malware authors have recently introduced an evasive technique that can no longer be handled by current sandboxes (even if the trick is known). This new evasive

2 technique, which we refer to as stalling code, delays the execution of malicious code so that a sandbox times out. However, to do this, the malware does not simply sleep. Instead, the program performs some (useless) computation that gives the appearance of activity. Hence, there is no way for the sandbox to wake up the program. Also, there are no checks for artifacts in the environment that might reveal any evasive behavior. The program simply executes, and from the point of view of the malware analysis system, everything is normal. The key problem, and the reason for the fundamental limitation of current sandboxes, is their lack of visibility into the execution of a malware program. A good sandbox has to achieve two goals: Visibility and stealth. That is, a sandbox has to see as much as possible of the execution of a program. Moreover, it has to do this in a stealthy fashion. Otherwise, it is easy for malware to detect the presence of the sandbox and alter its behavior (as discussed above). Current sandbox implementations typically rely on a virtual environment that contains the guest operating system. Sometimes, a sandbox runs the operating system directly on a real machine. The malware program is started inside the guest OS. To monitor a program s activity, a sandbox introduces hooks. These hooks can be inserted directly into a program to get notifications (callbacks) for function or library calls. The problem with direct hooks is that the program code needs to be modified, and this can be detect by malware or interfere with dynamic code generation (unpacking). Most frequently, sandboxes hook system calls to monitor the interaction between a program and the operating system. This is quite stealthy, especially for user-mode malware. Moreover, system calls capture all interactions between a program and its environment (e.g., when files are read, registry keys are written, and network traffic is produced). The key problem with hooking system calls (or library functions) is that the sandbox is blind to everything that happens in between calls. That is, a traditional sandbox cannot see any instruction that the malware executes between calls. This is a significant blind spot that malware authors can target; and they do so with stalling code, which is code that runs between system calls. An alternative approach to increase the visibility into malicious code execution is to use a debugger. A debugger has the advantage that it can see every instruction that a program executes. Typically, these tools used by a human analyst to manually step through the code in order to understand its functionality. Unfortunately, debuggers are not stealthy, and malware programs already employ many techniques to detect running debuggers. Also, debuggers are mostly used for manual analysis, which does not scale to the number of samples that vendors receive. What is needed is an automated malware analysis system that delivers the visibility of a debugger, but that is as stealthy and easy to manage as a virtual execution environment (a traditional sandbox). To achieve this goal, Lastline relies on system emulation. With a system emulator, we gain the advantages of a virtual execution environment, but retain the ability to see every instruction. This is crucial to be able to automatically handle evasive checks as well as stalling code. Figure 1 shows an overview of the ability of different malware analysis techniques. In the following sections, we discuss in more depth the two main evasive techniques that malware used in the wild: environmental checks and stalling code.

3 Figure 1: Visibility versus stealth for different malware analysis approaches Environmental Checks Malware programs frequently contain checks that determine whether certain files or directories exist on a machine and only run parts of their code when they do. Others require that a connection to the Internet is established or that a specific mutex object does not exist. In case these conditions are not met, the malware may terminate immediately. This is similar to malicious code that checks for indications of a virtual machine environment, modifying its behavior if such indications are present in order to make its analysis in a virtual environment more difficult. Other functionality that is not invoked on every run are malware routines that are only executed at or until a certain date or time of day. Functionality can also be triggered by other conditions, such as the name of the user or the IP address of the local network interface. Environmental checks have been discussed among security vendors in the past, and malware authors share well-known checks on hacker forums. As an example for such an environmental check, consider the example in Figure 2 and Figure 3. Here, we see malicious code querying for the names of the attached disks, and checking these names for the presence of the string QEMU. If this comparison is true, the malware knows that it is running inside the Qemu virtual environment.

4 Figure 2: Malware enumerating registry keys for the disk Figure 3: The same malware checking for the presence of QEMU in the disk name Environmental checks typically require that malware reads some value from the operating system (its runtime environment). These values can be registry keys, such as the name of the disks in the example above. Other values are file names or names of running processes. Whenever a malware program reads some value from the operating system, it has to invoke a system call. A sandbox sees this system call, and hence, can manipulate the return value (typically, it is randomized). Thus, when a specific environmental check becomes known, security vendors can improve their sandbox to watch for it. While this reactive approach works to some extend, it is vulnerable to evasion when malware authors introduce novel (zero day) checks. This requires vendors to patch their sandbox, introducing a window of vulnerability.

5 To handle the problem of environmental checks, it is crucial to have a more detailed view into the execution of a malware program. In particular, it is necessary to monitor the execution of all instructions. If such a view is available, it is possible to automatically track the values that a program reads and trace how the program processes it. This allows the system to recognize program points where the continuation of the execution depends on previously read input. When such a program point (an environmental check) is encountered, the analysis can explore both possible continuations. In addition, the system can extract the conditions under which the program follows a particular execution path. Using this information, one can determine the circumstances under which a damage routine or a propagation function is executed. This allows the automated identification and bypass of environmental checks, irrespective of the actual check that is used. Stalling Code Stalling code is executed before any malicious behavior regardless of the execution environment. The purpose of such evasive code is to delay the execution of malicious activity long enough so that automated analysis systems give up on a sample, incorrectly assuming that the program is non-functional, or does not execute any action of interest. It is important to observe that the problem of stalling code affects all analysis systems, even those that are fully transparent. Moreover, stalling code does not have to perform any checks. Stalling code exploits two common properties of automated malware analysis systems: First, the time that a system can spend to execute a single sample is limited. Typically, an automated malware analysis system will terminate the analysis of a sample after several minutes. This is because the system has to make a trade-off between the information that can be obtained from a single sample, and the total number of samples that can be analyzed every day. Second, malware authors can craft their code so that the execution takes much longer inside the analysis environment than on an actual victim host. Thus, even though a sample might stall and not execute any malicious activity in an analysis environment for a long time (many minutes), the delay perceived on the victim host is only a few seconds. This is important because malware authors consider delays on a victim s machine as risky. The reason is that the malicious process is more likely to be detected or terminated by anti-virus software, an attentive user, or a system reboot. Figure 4: Stalling code in W32.DelfInj

6 Figure 4 shows a stalling loop implemented by real-world malware. As the sample was only available in binary format, we reverse engineered the malware program and manually produced equivalent C code. Since the executable did not contain symbol information, we introduced names for variables and functions to make the code more readable. While this malware calls functions as part of the loop, this does not have to be the case (as shown in Figure 5). Figure 5: Stalling loop without any function or system call Stalling code can only be recognized by analysis systems that have visibility into all instructions that a malware program executes. There are no obvious checks that can be seen at the system call level. To automatically detect stalling loops, and to ensure forward progress within the amount of time allocated for the analysis of a sample, one can use the following three-step approach. To this end, we introduce techniques to detect when a malware sample is not making sufficient progress during analysis. When such a situation is encountered, our system automatically examines the sample to identify the code regions that are likely responsible for stalling the execution. To this end, our system starts to dynamically record information about the addresses of instructions (code blocks) that are executed. Using these addresses, we build a (partial) control flow graph (CFG) of the non-progressing thread. This CFG is then searched for loops. For these code regions (and these regions only), costly logging is disabled. When this is not sufficient, we force the execution to take a path that skips (exits) the previously identified stalling code. In that case, we need to be careful, since the program could be in an inconsistent state. Malware authors could leverage these inconsistencies to expose the analysis system. To overcome this problem, we mark variables that are touched by the loop as potentially inconsistent. When such a variable is later used, we compute the proposer value on demand, by extracting a program slice.

7 Again, the key insight that allows us to automatically detect and mitigate stalling code is the fact that we see all instructions that are executing. Hence, we can identify stalling loops and actively interrupt their execution. Summary and Trends Malware authors have utilized simple evasion tricks for many years. These tricks mostly targeted public sandboxes and frustrated automated analysis by anti-virus vendors (who leverage sandboxes in the backend to aid signature generation). When sandboxes were introduced as the core of next generation APT detection offerings, attackers responded by developing novel evasive techniques, such as stalling code. Stalling code and novel environment triggers exploit the limited visibility of sandboxes and ensure that targeted attacks and zero day exploits remain successful. Figure 6 shows the fraction of samples with evasive behavior that we collected in our global analysis infrastructure over the last year. The growing trend is clearly visible. Figure 6: Increase of samples with evasive behaviors in 2012

8 , was founded in 2011 by university researchers Engin Kirda, Christopher Kruegel, and Giovanni Vigna. Lastline s security products synthesize and bring to commercial standards the founders award-winning, world-renowned academic research on malware analysis and attack countermeasures. The founders of Lastline are also the founders of iseclab, one of the top malware research organizations in the world, and are considered to be today s thought leaders on automated high-resolution malware analysis and detection. The founders are well-known for their development of Anubis and Wepawet, which are cloudbased malware analysis tools with a user base of thousands of corporations, government institutions, and security vendors. Lastline is focused on real-time analysis of advanced malware and on tracking the Internet s malicious infrastructure (the Malscape ). Lastline leverages this threat intelligence to create advanced malware defenses for companies of all sizes. By focusing on cloud-based automated systems and processes, Lastline has developed the technology to analyze advanced malware at an unprecedented speed and volume. This gives Lastline the ability to analyze binaries and web content as it enters enterprise networks, as well as the ability to map the Malscape at a level of accuracy and relevance previously not available. As a result, Lastline s technology is able to detect 0-day, targeted attacks and provides actionable threat intelligence to address the advanced malware problem. For more information send to: info@lastline.com Copyright All rights reserved worldwide.