Bypass Dynamic Analysis

Dynamic malware analysis - or sandboxing - has become a central piece of every major security solution... and so has the presence of evasive code in malicious software. Practically all variants of current threats include some sort of sandbox-detection logic.
One very simple form of evasive code is to delay execution of any suspicious functionality for a certain amount of time - the basic idea is to leverage the fact that dynamic analysis systems monitor execution for a limited amount of time, and in the absence of malicious behavior classify a program as benign. On a victim machine, on the other hand, delaying behavior for a few minutes does not have a real impact, allowing the attacker to easily achieve different behavior in the analysis environment and on a real target machine.
The easiest, and definitely most prevalent method of stalling behavior is to make a program “sleep” for a certain amount of time. Since this is such a common behavior, most analysis sandboxes are able to detect this kind of evasion, and in most cases, simply “skip” the sleep. While this sounds like a simple solution, it can have a wide range of unintended effects as we will see in this blog post.

The Power of Procrastination

In our whitepaper Automated Detection and Mitigation of Execution-Stalling Malicious Code we describe the basic principle behind stalling code used against sandboxes:

Stalling code is typically executed before any malicious behavior. The attacker’s aim is to delay the execution of the malicious activity long enough so that an automated dynamic analysis system fails to extract the interesting malicious behavior.

Code stalling can be achieved in a number of ways: Waiting for a specific action of the user, wasting CPU cycles computing useless data, or simply delaying execution using a call to the Sleep() function.
According to MSDN

VOID WINAPI Sleep(  _In_  DWORD dwMilliseconds);
Suspends the execution of the current thread until the time-out interval elapses.

a call to Sleep() will delay the execution of the current thread by the time passed as argument. Most sandboxes monitor the system- or API-calls of a program under analysis and will therefore see this evasion attempt. Therefore, the sandbox is able to detect, and in most cases even react to this, either by patching the delay argument passed to the operating system, by replacing the called function with a custom implementation, or simply by returning immediately to the calling code (skipping the sleep altogether).

Detecting Sleep Patching

Recently, we have come across an interesting malware family that uses this anti-evasion trick used by sandboxes to detect the presence of the analysis environment (one could call it an anti-evasion-evasion trick…)
This malware detects sleep-patching using the rdtsc instruction in combination with Sleep() to check acceleration of execution, as one can see in the following code extract:

In summary, this code:

• executes rdtsc, which reads the CPU’s timestamp counter, and stores the timestamp in a temporary value,
• invokes Sleep() to delay execution,
• re-executes rdtsc, and
• compares the two timestamps.

Sleep Patching Using High-Resolution Dynamic Analysis

Different from traditional sandboxes, Lastline’s high-resolution analysis engine monitors more than just the interaction of programs with the operating system (or API functions). Our engine sees - and can thus influence - every instruction that is executed by the malicious program, not just API function invocations. Thus, since we can also manipulate the values returned by the rdtsc instruction, we can maintain a consistent execution state even when patching a sleep, for example by fast-forwarding the timestamps returned by the CPU to the program each time a sleep is skipped or accelerated.
As a result, the program can no-longer distinguish if a sleep was truly executed in full, or if the analysis system simply forwarded the time inside the sandbox.

Side-Effects of Sleep Patching: User Emulation

We found other interesting side-effects introduced by sleep patching that might not be directly related to deliberate sandbox detection, as can be seen in the following piece of code:

Here, the malware sample checks for user-activity by repeatedly checking the cursor position (in 30 second intervals).
Most sandboxes have some mechanism to trigger (or simulate) user activity. Typically this means repeatedly changing cursor position, opening new windows, click on dialog-boxes, etc, just to name a few.
In the code above, the malware sample uses the Sleep() method not for delaying malicious activity, but merely to have a simple way for checking that some user-activity --mouse movement, in this case-- was observed within a certain time period. Clearly, if a sandbox naively accelerates this code by patching the sleeps, the behavior that was expected to happen while the malware sample is dormant will not happen, and as a consequence, the presence of the analysis environment will be detected, evading analysis.
Therefore, again, a naive approach to execution-stalling will allow an attacker identify the presence of the sandbox, or, as in this case, the absence of a real user, evading analysis.

Side-Effects of Sleep Patching: Race Conditions

Another interesting problem related to sleep-patching are race conditions: Race conditions are a non-trivial programming error, where multi-threaded code needs to be executed in a specific order to work correctly.
One (ugly, as many programmers would agree) way of avoiding race conditions is to delay code depending on completion of another task by the amount of time this task typically needs.
In the presence of sleep-patching, however, this approach is bound to fail, as the sandbox influences the amount of time that is slept. One such example can be seen in the code below, extracted from another malware family:

In this code, the malware decrypts and executes code from a dropped file, cleaning up after the program has executed (by deleting the file). Between invoking and deleting the program, the malware sample uses a - one already guessed - sleep to make sure the program is started before it is deleted. Once again, by patching the sleep incorrectly, the sandbox breaks this logic, causing the malware to delete the payload before it is ever executed.
A more complex example can be seen below:

Here, malware reads encrypted code from a file on disc and executes it in the context of the current process using a separate thread. Once the payload has been started, the main thread goes into an infinite sleep (but this could equally be a long sleep), before executing ExitProcess (which terminates the execution of all threads in the process).
If this sleep is patched to be shorter than the execution of the malicious payload, the process is terminated before completing its activity, unintentionally stopping the process before it can completely reveal its malicious behavior.

Summary

Timing attacks are common to most malware families today. While some of these timing attacks are easy to detect, naive approaches to overcoming these evasion attempts often cause more harm than they do good, opening gates to evasion attacks based on anti-evasion systems.
Using high-resolution dynamic analysis and leveraging its insight into each instruction that is executed by the malicious program, the Lastline sandbox is able to foil these attacks and reveal the malicious behavior.