As I demonstrated in my last blog , malwares have now started to submerge much deeper into the system to detect the sandbox environment. Besides the file system , process and known registry artifacts which can be very easily spotted by the researchers , there are several other methods researched to evade the automated analysis systems and needless to say , actively being used today. This two part blog series is primarily intented to provide a complete walkthrough of the most common sandbox evasion techniques prevalent today.
Latent execution:
Automated malware analysis systems are designed to process several thousand samples within a short period of time . Because of that fact, the proportion of time allocated for its execution is usually very limited , ranging from somewhere between 3 to 5 mins for one sample. Malware authors tend to take the advantage of this configuration aspect by introducing the Sleep ( ) calls in the middle of the code to pause the execution for several minutes before the execution of actual malicious payload. Under the Sandbox configured to execute the malware for shorter period , none of the malwares' actual behaviour would be captured. This is very common technique used today to bypass sandboxes . One such family of malwares using this was Win32/Kuluoz .
One of the disadvantage of using Sleep / SleepEx calls is that they are easily noticeable and Sandboxes are now protected against this trick. Since they use the API Hooking to trace the calls , the moment it notices the Sleep ( ) calls , it will patch the argument to the API, effectively resulting into the faster sample execution.
Malwares as always , continues to look out for more elegant methods. One of the way to evade this protection mechanism is to use the alternate APIs some of them which are undocumented . For Instance below APIs can still be used to achieve the same functionality:
NtDelayExecution ( ) [ Undocumented ]
WaitForSingleObject ()WaitForMultipleObject ( )
CreateWaitableTimer ( )
SetWaitableTimer ( )
More polished method to introduce latency was observed in the Win32/Cutwail ( MD5 : b4f310f5cc7b9cd68d919d50a8415974 ). It loaded the ECX register with the huge value and kept calling the API in the loop resulting into single API call > 78 Lac times. Below is the snippet of the code:
This can still be noticed by some of the intelligent sandbox systems out there . Way to go one step beyond this is not to call the API , instead place the junk instuctions in the loop . This can virtually defeat every sandbox technology. We could do something like this :
Self Name Checks
One of the other common and observed way of sensing the sandbox environment is to perform the self check. Sandboxes, while executing the malwares are inclined to rename the file either to sample.exe / malware.exe / virus.exe etc. Malwares have found to be taking advantage of this naming convention. Similar technique was found in one recent malware (MD5:9404955681a5828b5ab9ab2a5c5547ce) named Win32/Comrerop.
And don't be surprised to see that Comodo sandbox helps this malware. Look at the analysis report here . Prevalent sandboxes like ThreatExpert can also be traced using this simple mechanism.
Loaded modules and monitoring tools
Sandboxes have their own monitoring DLLs that are used and loaded while processing the samples. Several malwares have been observed to check for these loaded DLLs specifc to respective sandboxes. It can also check for the installed monitoring tools used to capture the end to end behaviour of the malwares. Here is the code snippet from Win32/Comrerop performing similar checks:
More checks from the same malware searching for open windows of sysinternal tools / debugger :
Checking Hard Disk size
This technique is very well documented and has been observed in several recent malwares. The idea behind this logic is to obtain the handle to the physical drive using CreateFileA ( ) API and then use this handle to pass it to the device driver using DeviceIoControl ( ) API to perform the operation specified by IoControlCode. Malware using this mechanism with IoControlCode of 0x7045c is most likely performing the HD size check . If the Hard Disk size is < 10 GB , malware presumes that it is running under the sandbox.
IoControlCode 0x7045c stands for IOCTL_DISK_GET_LENGTH_INFO , which retrieves the length of the specified disk, volume or partition. Below is the HD size check in the malware code:
This actually makes sense because it is rare to have the sandbox machines with the larger HD size .
Tracing mouse movements
Tracing the mouse movements is one of most effective way of differentiating the sandbox and easier to implement as well. Mouse movement check basically involves checking for the cursor position and then substracting the coordinates to check if the mouse has moved. GetCursorPos ( ) API is called twice to check for the cursor movement . Since there is no input device connected to the sandbox machines, it can trace almost all the sandboxes.
Sandboxes can be protected against this technique by intercepting the call and randomizing the coordinate values.
Ring 3 hook detection
Sandboxes significantly rely on the API hooks to be able to trace the activity of the malware. Ring 3 hooks are the user space hooks that can be easily implemented via modifying the initial instructions of the API code within the mapped DLL and pointing it to the hooked code. Several available sandboxing technology including Cuckoo , employs the similar techniques to log the APIs called by malware . Malware authors are very well aware of this and take the advantage of this implementation by detecting them. One of the simplest detection method is to get the virtual address of the API and check if that does not start with the standard prologue. If code starts with Jump/Call instruction , then it indicates that API has been hooked which leads to the conclusion that code is being executed in the sandbox . Here is the example code that attempts to detect the user mode inline hooks.
One of the way malwares tend subvert the user space hooks is to implement the custom loader and map the desired DLL in the process address space perhaps using a different name, and then get API address using the standard GetprocAddress mechanism . More sophisticated approach for the malwares could be to drop the kernel drivers which implements the required code using the lower level APIs and then user space components calling them , which will essentially bypass the sandbox hooking framework .
Sandbox detection using known product IDs
This is the another popular and easy to implement sandbox detection technique used by several recent malwares including Win32/Gamarue,Win32/Comrerop etc . Every commercial sandbox has its own associated Windows product ID that can be fetched from the registry key and matched against the blacklisted product IDs. Calliing the API RegQueryValueEx ( ) on the following registry keys will extract the respective product IDs :
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\\ProductID
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\\ProductID
API trace for one of the sample trying to access the product ID:
Following is the list of some of the known product IDs and associated with their respective sandboxes:
Anubis :
product ID :76487-337-8429955-22614
CWsandbox :
Product ID :76487-644-3177037-23510
JoeBox :
Product ID :55274-640-2673064-23950
I'll keep rest of the techniques of evading sandboxes to my next blog.We'll walk though few of them used in the recent targeted attacks. Stay tuned !!..
Posts
