Regardless of the technology being used maintaining an efficient sandbox requires to continuously monitor new malware samples in order to effectively cope with new evasion techniques. Today we want to share some of the techniques that we have spotted during the last couple of months. We mentioned some of these already briefly on our Twitter feed.
COM/DirectShow Audio device checks
One of the TeslaCrypt variants utilize the COM-based DirectShow audio related piece of code shown below to avoid sandboxes and emulators:
The code above is intended not only to check the presence of an audio device, but it also verifies if the API is fully operational (probably in order to filter out poor API emulation). Let's go through the code to see what exactly it does:
Standard DirectShow initialization, error code is not checked
|E_POINTER != pGraph->AddFilter(NULL, filterName)|
First anti-emulation check: If AddFilter is called with NULL as a first argument it should return the E_POINTER error code. Some emulators may implement unknown COM interfaces in a generic way, so they will probably fail here.
Initializes a simple Audio Renderer, error code is not checked, but pBaseFilter will be set to NULL upon failure and the code will eventually fail later.
Adds the previously created Audio Renderer to the Filter Graph, no error checks
Tries to find the filter that was just added; in case of any previously not checked error (or wrong emulation) this function won't find the filter and the sandbox/emulator will be successfully detected.
Checks if info.achName is equal to the previously added filterName, if not - poor API emulation
Checks if the API sets a proper IReferenceClock pointer
Checks if CLSID is different from 0
Just checks if the call was successful
The reference count returned by AddRef has to be higher than 0
These are just some random checks to ensure that the malware is executed on a real system. A sandbox here would be considered a real system only if it has an audio device installed. Most emulators will fail since it is close to impossible to implement proper support for every COM interface that is present in modern operating systems.
Office Recent Files & GeoIP checks
A recent batch of Dridex embedded in MS Office documents utilizes two different tricks to avoid execution in sandboxed environments. At first, it checks for the number of Recent Files opened by one of the Office apps on the target machine:
If the number is lower than 3 malware simply stops execution. The second method checks if the ISP/Organization that the machine IP belongs to is on the list below:
To get this information, this particular malware family abuses the MaxMind GeoIP online database:
The above snippets are a deobfuscated version of the VBA script that is embedded in the original Office documents. More detailed analysis can be found on the Zscaler blog.
OS Locale check
It is a common technique to check the system locale and execute (or not) payload only in some countries. Usually the check is made with GetSystemDefaultLangID Win32 API, which returns a 16-bit value that identifies the OS language (Language Identifiers). Since it is a numerical ID, it is very easy to feed the malware with the correct ID value, so it will believe that it is being executed in the language region of its choice. Recently we came across a sample that uses VerLanguageNameW in addition to the GetSystemDefaultLangID API to get the textual version of the language identifier:
The results are then compared to the string that is hard-coded in the executable:
The trick here is that if the OS locale was artificially changed the returned string will be in the language of the original Windows installation. So in case of an English OS it will be Portuguese (Brazil) instead of Português (Brasil). Game over.
Command line switches
Sometimes it happens that we need to replicate some file, but the original dropper is missing and the sample does not really do anything meaningful. In some cases, the solution is as simple as a missing command line argument. Recently we have added a new signature that detects command line switches and shows them in the final report, so that the user has the ability to re-run the analysis with a proper argument set through a cookbook (The example cookbook is called "Execute binary with arguments"). In such cases the analysis report contains results similar to the one below:
This trick is not new, but due to recent Nymaim activity we are getting many queries regarding it. We have already described best practices for such samples in the post describing API hammering, so we will just quote it here to have everything in one place:
"It is always good to re-run the analysis with different dates to verify if the sample does not expire or if it is not activating in the near future. Usually it is safe to assume the day when the sample was received as the initial date, timestamp from the PE header should work as well. (...) We can easily handle such cases in Joe Sandbox through our Cookbooks technology, whole operation boils down to adding below line to the Cookbook: _SetDate(06, 04, 2016)"
Thanks to the agility and flexibility of Joe Sandbox we can very quickly react to new evasion techniques. This is what we call Agile Malware Analysis. We continuously monitor the latest threats for evasions. Once we find an evasion we write a signature to detect it, and create Anti-Evasions. The concept of Agile Malware Analysis is also adopted by many of our customers. Many of our technologies such as Cookbooks, Hybrid Code Analysis and Execution Graph analysis are extremely helpful for this process. When compared to other approaches Agile Malware Analysis has proven to be by far the most successful concept in the long term.