It is well known that a big amount of malware samples are aware of the execution environment. This means that a malware sample can change his behavior if it detects that the running environment is unwanted.
There are resources, public source code, and even programs that detail how to bypass automatic malware analysis systems and make things awkward for malware researchers. Of course, these resources are quite useful for both researchers and malware developers.
We are going to take a look at some of these tricks, all found in real malware samples.
Also, just as they do, we have developed some yara signatures to detect these tricks that could be useful to differently process or classify these malware samples.
We could classify anti analysis tricks in three big groups:
- Anti Virtual Machine, that tries to detect if the execution environment is a known VM or emulator.
- Anti Debugging, that tries to detect if the program is running under the surveillance of a debugger.
- Anti Sandbox, that tries to detect known sandboxing products.
It is not unusual to find all kind of tricks in just one malware sample. For example, we can take a look at the sample 9255c75de8fbc20ee67f427397e1ef82:
Quickly we can find that it is looking for sbiedll.dll (to detect Sandboxie) and dbghelp.dll
It also opens the registry key HKLMSYSTEMControlSet001ServicesDiskEnum with value 0 to read the ID of the hard disk in the machine:
Then it is compared with these three strings (VIRTUAL, VMWARE, VBOX):
Finally, it opens the registry key HKLMSoftwareMicrosoftWindowsCurrentVersion with value ProductId:
And checks it against these three known MS Windows products ID from different commercial sandboxes:
If we take a look at another sample (36527d5954bf3b2af60e6efa6398ccff), we will discover a canonical function to check this:
It checks the MS Windows product ID and if it is “76487-644-3177037-23510”, the function will return 1. Else, it will return 0. It also has the same function prototype to check keys “55274-640-2673064-23950” and “76487-337-8429955-22614”.
This sample also uses MS Windows system functions to detect debugging.
It loads the function handler for IsDebuggerPresent using the function GetProcAddress() from kernel32.dll. Hey wait! And why not use IsDebuggerPresent() directly? Because it is noisy and easily detectable.
If it can not load the function or the function returns 0 (debugger not present), it will return 0. Else, it will return nonzero.
It also looks for files (SyserDbgMsg / SyserBoot) and (SICE / NTICE) using this function:
This trick is to detect both SyserDebugger and SoftICE debuggers.
As we said, we have published a ruleset of yara signatures to detect AntiVM, AntiDebugger and AntiSandbox procedures in malware samples. You can grab it in our GitHub repository here.
