Malware continues to evolve and to fool most sandboxes. It will frequently take an alternate approach to accomplish an old objective – the same wolf in a different set of sheep’s clothing.
As covered in a previous blog, Evasive Malware’s Gone Mainstream, advanced malware contains numerous techniques to avoid detection by security controls. Fortunately, we’ve developed an architecture and approach that defeats these attempts to remain hidden.
At Lastline, we’ve been researching evasive malware for years, and have collected and categorized in great detail the various techniques used to evade detection by a sandbox. This deep understanding of evasive malware combined with our full system emulation-based architecture allows us to detect even the most sophisticated malware evasion tactics.
Malware Evasion Techniques
In today’s blog post we’ll take a closer look at a couple of emerging malware evasion techniques, and show how an advanced malware detection system can identify and defeat them.
Evasion Method 1 – Detecting Core Count via System or Process Affinity Mask
Example file MD5 hash: 53f6f9a0d0867c10841b815a1eea1468
Malware authors use various techniques to identify a sandbox, but most methods involve analyzing the host’s hardware configuration for telltale signs of a real system versus a sandbox. For example, most sandbox solutions are designed to analyze multiple samples in parallel. To achieve this, they assign minimum hardware resources to each sandbox instance — including the least possible amounts of RAM, disk space, and processing power. However, because very powerful systems are widely available today at inexpensive prices, real systems tend to be configured with maximum, or at least numerous, resources. They typically have lots of RAM, extensive disk space, and multi-core processors. These discrepancies in hardware, if they can be determined, enable modern malware to spot a sandbox with some degree of accuracy.
To make discovery more difficult, most sandbox vendors attempt to hide their true configuration, hopefully fooling the malware into believing it’s executing within an actual host.
Recently, we’ve observed a new evasion tactic that alters the way the system’s core count is determined: while most malware families use PEB or WMI to retrieve the core count, in this new variant, the malware obtains the core count using the System Affinity Mask or the Process Affinity Mask.
“A process affinity mask”, as defined by MSDN, “is a bit vector in which each bit represents the processors that a process is allowed to run on. A system affinity mask is a bit vector in which each bit represents the processors that are configured into a system.”
As made clear by MSDN’s definition, each bit in the system or process affinity mask represents a processor, and hence by simply counting the set bits, one can determine the total number of cores in the system.
Malware uses this new method of obtaining the core count by calling the GetProcessAffinityMask API. The API returns the mask, which easily identifies the number of cores in use.
Here is MSDN’s documentation for the GetProccessAffinityMask API:
BOOL WINAPI GetProcessAffinityMask(
_In_ HANDLE hProcess,
_Out_ PDWORD_PTR lpProcessAffinityMask,
_Out_ PDWORD_PTR lpSystemAffinityMask
);
Retrieves the process affinity mask for the specified process and the system affinity mask for the system.
The catch with this method of evasion is that it can defeat those sandboxes that only patch certain ways of querying the environment, such as user mode APIs (e.g., GetSystemInfo) or data structures related to processor/system information (e.g., PEB) mapped in process memory. As we can see here, there are numerous ways of querying the number of available cores, and a system needs to be aware and be in control of all of them.
Here is an actual sample of malware code making a call to GetProcessAffinityMask in order to determine the core count:
In the above sample, if the core count is less than 2, the malware simply terminates without executing its payload:
Lastline Analysis
When this malware sample is evaluated within Lastline’s sandbox, it fully executes. This is because Lastline behaves like, and looks like, an actual host — returning a core count that matches that of a real system. The malware fully executes, enabling Lastline to perform full behavior analysis and correctly categorize the sample as malicious, as shown in the report below.
Lastline’s analysis of the malware containing the new core count evasion tactic correctly reports the sample as malicious, and in this particular instance, accurately identifies it as ransomware.
Evasion Method 2 – Detecting Lack of User Input
Example file MD5 hash: 5bd308c1b32178098c8202cff5b02a28
In the second evasion technique, malware looks for the lack of user input. In a real machine, user input, such as keyboard or mouse activity, will be a frequent or at least an eventual occurrence. But a conventional sandbox won’t typically have any user input, nor will it emulate user I/O activity sufficiently enough to fool the malware. Because of these limitations, advanced malware can use this discrepancy (the lack of user input) to detect the sandbox. (Learn more about this by reading the blog “Not so fast my friend – Using Inverted Timing Attacks to Bypass Dynamic Analysis”).
To obtain the amount of idle time since user input was last received, malware will often use a combination of the GetLastInputInfo and GetTickCount functions.
Here is the definition of GetLastInputInfo from MSDN:
BOOL WINAPI GetLastInputInfo(
_Out_ PLASTINPUTINFO plii
);
Retrieves the time of the last input event.
When examining the LASTINPUTINFO structure definition, we see that it returns the last input event tick count in the dwTime member
typedef struct tagLASTINPUTINFO {
UINT cbSize;
DWORD dwTime;
} LASTINPUTINFO, *PLASTINPUTINFO;
Here is the actual evasive code from the sample:
An examination of the above code reveals that it executes the following logic inside an infinite loop:
- Get idle input tick count by subtracting the current tick count from LASTINPUTINFO.dwTime.
- If idle input tick count is < 100 ticks and not equal to the last idle tick count, then consider it as “correct idle input time” and add it to counter.
- Break out of loop if correct idle time counter > 10
- Sleep for 11 ms
As a test to see if the code is running on a real system, this malware sample will wait indefinitely for user input. If it is on a real system, at some point a user will press a key or move the mouse and the idle time will be less than 100 ticks. When that happens more than 10 times, the malware will then begin executing its payload.
However, a conventional sandbox has limited time to execute and analyze each program, so detecting this type of evasion is problematic. Additionally, when evaluating the above malware sample, a conventional sandbox needs to generate the correct input idle time 10 times within a specified timeframe. If it doesn’t do this, the malware will not execute and it will remain undetected. Most of the sandboxes we tested are unable to accomplish this and incorrectly concluded that the sample is harmless.
Fortunately, Lastline’s sandbox is designed to mimic real user behavior. This enables Lastline to defeat such evasions and detect the actual behavior of the malware.
The Lastline analysis report for the above code can be seen below:
As the behavior overview shows, the malware code does not detect the presence of the analysis system and successfully executes its malicious behavior – such as decrypting the next stage and communicating with the command-and-control server of the attacker.
Summary
Malware is a profitable business and cyber criminals continually develop new evasion tricks to avoid detection. Conventional sandbox technologies are unable to observe a number of these evasion techniques.
At Lastline, we use full system emulation which provides deep visibility into the OS and allows us to detect even the most advanced evasion techniques that other security tools will miss.
The post Malware Evasion Techniques: Same Wolf – Different Clothing appeared first on Lastline.
Article Link: https://www.lastline.com/labsblog/malware-evasion-techniques/