Joe Sandbox aware Malware? Certainly not! But surely!

    During the weekend we have been notified by one of our Joe Sandbox Cloud customers that they have found an interesting sample (MD5: D80E956259C858EACCB53C1AFFAF8141) which shows much malicious behavior on a competitor malware analysis system but behaves silently on Joe Sandbox. A first look at the behavior report does not give any clues why it stays silent:




    We see that Joe Sandbox has found a function which is used to inject code into remote processes. However the function has not been executed:



    As a next step we checked the last behavior actions from the chronological section within the report:


    As we see the malware seems to executed some kind of sleep loop. So we checked the last API call before the sleep loop started:


    Here comes the interesting part. The code is checking the volume number of the local disk as well as the disk name. In a next step, all software uninstallers are enumerated. Thanks to Hybrid Code Analysis (HCA) we can lookup the function corresponding to this behavior:



    This is the key function. First the file name is validated it contains the substring "sample". Then the disk volume ID and name are queried. Finally, it starts the software uninstall key enumeration:


    During enumeration it checks if AutoItv3, CCleaner and WIC have present uninstaller entries. Guess what? These software are installed on all our Joe Sandbox Cloud and analyzer VMs. Joe Sandbox uses AutoIt for user emulation and CCleaner is a default system cleaning tool we often use. So this is a very nice and unique fingerprint of a Joe Sandbox Cloud / Analyzer VM. If the three applications are installed on a system the malware redirects to the endless sleep loop previously detected:


    To prove our theory we have written quickly a cookbook which deletes the uninstall keys:

    Finally result:







    So you may wonder how did they know about the software installed on the Joe Sandbox Cloud VMs?
    Since more than a year we are running free online services, including www.file-analyzer.net. The analyzer services are highly restricted but still leave some room for spying. We have experienced many attacks for all analyzer services (mostly www.apk-analyzer.net) ranging from simple ID lookups to information gathering and technology bypasses. Therefore, we have changed the free services to registered services. If you would like to use them send us your request and you will get an authentication code.


    Full Joe Sandbox 9.5.0 Report available at:










    The Power of Cookbooks - generic HTTPS Analysis

    Besides Hybrid Code Analysis, one of the top features of Joe Sandbox is the Cookbook technology. Cookbooks? Sounds like cooking. That is correct, Cookbooks lets one "cook" the malware. To be more precise, they enable to describe a malware analysis procedure in great detail. Below you see a very simple Cookbook for analysis on Windows:


    Cookbooks are written in AutoIt, which is a BASIC like programming language which has been designed to automate tasks on Windows based operating systems. AutoIt offers a huge set of functionality from browsers (IE, FF, Chrome) to windows, files, registry controlling. In addition to that, one can call Joe Sandbox commands - starting with _JB. Joe Sandbox offers an extensive set of commands letting one play around with malware samples. The simple Cookbook sample above analyses a sample on a Windows XP system. For anti-VM it randomizes artifacts which are unique on the virtual machine. It also simulates mouse clicks and launches tools for GUI click simulation. Lets have look at a more complex Cookbook:



    Rather than one analysis, the Cookbook above consists of two analyses which are some how connected. We call that Cookbook chaining. The second analysis starting at line 40 is only executed if during the first analysis HTTPS traffic has been detected. To connect two analyses one can use the _JBChainCookbook command. _JBChainCookbook has directly access to the generated behavior report and uses an XPATH expression for evaluation. In the sample above it checks if there are some TCP packets on port 443. If true the second analysis is started, if false the analysis is finished.

    Let us assume that we analyze a malware sample which uses HTTPS for C&C communicate. Since HTTPS is encrypted, we do not see the clear text data sent through the tunnel. In order to get that data, we have implemented a cool technique which is based on our API patching framework. Within the second analysis, line 55 you find the command _JBForceHTTP. _JBForceHTTP is implemented as:


    _JBAddAPIPatch has the following function signature:


    The commands enables to fake input arguments for any API call. So assuming the malware calls InternetConnectA(12, "", 443, "", "", INTERNET_SERVICE_HTTP, INTERNET_FLAG_SECURE, NULL) the API patch will substitute the second input parameter with 80. _JBForceHTTP patches all important input arguments in order to force HTTP. As a result the WININET subsystem makes a normal HTTP connection rather than a HTTPS and we can analyze the protocol without any problems. This is working very well, as an example - browsing https://www.google.ch with IE demonstrates:



    IE still believes it is using HTTPS but it is not true as the network analysis proves. Of course the technique also works well with malware using HTTPS.

    Analysis example without _JBForceHTTP for a recent sample:




    With HTTP force enabled:






    Full analysis report available at: report - c77dd48c57156a20f0e32022e489546e.

    Using Cookbook chaining to analyze HTTPS malware is just one example of many. Other use cases are:

    • Analyse on VM, if sample is idling, analyze again on native machine
    • Analyse on VM, if sample is idling, analyze again and show more user behavior
    • Analyse on VM, if sample sleeps, analyse again and patch sleep
    • Analyse, if domain is down or blocked analyze again with a different DNS server 
    Generally, Cookbooks have more and more become a very important tool in Joe Sandbox to fight advanced malware. The flexiblity with this technology is unmatched. Beside _JBForceHTTP there are additional commands like:

    • _JBReboot
    • _JBShortenSleepsGreaterThan
    • _JBComment
    • _JBCreateSlice
    • _JBLowerOfficeSecurity and _JBLowerIESecurity
    • _JBAddProxyToIE
    Interested to try out the Cookbook technology? Send us a mail and we well setup a test account for you on Joe Sandbox Cloud!




    Detecting Malware by using the Application Icon

    Have you ever wondered how many malicious applications use an application icon from a legit application?



    We did the same and thought about implementing a cool signature to detect if a potential malicious application uses an icon of a benign application. To do so, we collected a large set of icons by extracting them from malicious applications. Afterwards, we selected those icons which looked familiar to us:

    The next step was to search for a good icon comparison algorithm. After a quick search we found a very cool differential hashing algorithm called dHash as well as an implementation in python. dHash calculates the relative gradient direction by measuring the brightness between adjacent pixels. Compared to a crypto hash function dHash ignores some of the image features. Therefore, similar but non-equal icons get the same hash. To do so it reduces the size and the color (grayscale) of an icon. Having a hashing/icon comparison algorithm which compensates modifications is necessary since the icons of malicious applications are often not identical to the those of legit applications.

    Finally, we calculated unique dHashs of our set of benign icons we found in malicious apps:



    We wrote a Joe Sandbox behaviour signature to detect those icons generically:


    The full analysis report is available at:




    Introducing Joe Sandbox Class

    Introduction


    As you may know Joe Sandbox is a very extensive analysis system. Hybrid Code Analysis Technology, a key part of Joe Sandbox, enables to analyze executed and non-executed code paths - things a malware would execute only if a specific event triggers. Rather than looking at the installation behavior of the malware which is often a tiny part, HCA provides a complete overview of all the behavior. In addition it enriches disassembly codes with dynamic information such as API calls, arguments, strings and constants, making the understanding of the code much easier. Finally HCA links dynamic data such as a "File Create" event with its underlying code function. This enables to understand the context and relation between different events. All in all HCA is a very powerful and unique technology that helps to understand today's complex threats more efficiently. Below you see an excellent example of the HCA output:


    During extensive field tests with HCA and several great customer feedbacks over the last years we realized that HCA generates very rich output describing the malware behavior nearly completely in most cases. Therefore we started some research in order to use HCA output to do malware similarity analysis and clustering. Today I am happy and excited to release a new Joe Security Product called Joe Sandbox Class which is based on this research.

    Similarity Analysis

    Joe Sandbox Class is a plugin for Joe Sandbox Desktop, Complete and Light. On a high-level Joe Sandbox Class works as outlined in the following picture:


    As a first step Joe Sandbox Class selects some features from analysis data generated by Joe Sandbox. Due to its quality mainly HCA code functions are used. The analysed code functions are always based on malicious data, e.g. from the sample under analysis. They do not include Windows or third party library functions. In a second step the features are generalized in order to match variations (different code functions with the same behavior). Next Joe Sandbox Class reduces noise. Noise can be understood as functions which often occur in malicious code and are related to setup functions introduced by compilers and runtime environments. Right after that Joe Sandbox searches its database for similar features. Finally all features are stored in the database and a detailed report in HTML, XML and JSON is generated. Joe Sandbox Class also compiles a graph outlining the different malware groups respectively clusters.

    Finding Similar Samples

    There are several cool use-cases for Joe Sandbox Class. Let's have a look at some of the most important:

    Assuming that we have the sample install.exe (MD5: 1c95dc2d7af36838341996e6ed50fef1) and we want to see if we have a similar sample within our database:


    Joe Sandbox Class has found two similar samples. One of the functions which is similar in the two samples is function 00403329. This function is very huge and has not been executed :



    Looking at the behavior analysis report for the two similar samples it becomes obvious that it is the same malware:




    Since we know that it is the same malware we can get a more complete picture of its behavior:




    We can also find the samples within the cluster graph generated by Joe Sandbox Class:




    Improving Detection

    Another very cool use-case is enhancing detection. Imagine that we have a sample which has some new evasion technique (e.g. Sandbox Overloading with GetSystemTimeAdjustment) included and therefore could not be detected as malicious by Joe Sandbox. However with the help of Joe Sandbox Class we can find similar samples which may have been detected as malicious by Joe Sandbox. Since they share some common behavior we can automatically classify the sample with the evasion technique as malicious. Finding samples in the cluster graph which have been classified as benign is very simple since the nodes are colored green:


    As the graph outlines the Lloyds Message Service_....exe has been classified as benign. However it shares several code functions with malicious samples:


    Looking at the behavior report of Lloyds Message Service_...d.exe we encountered that it tried to download additional files which where not available anymore.

    As we have outlined there are many interesting use-cases. You can analyze all the interesting clusters, detect campaigns and get an understanding of the threat landscape:


    or you can also search for new malware - things you have not seen before. However this requires a very large feature database. We are currently constructing such a database and will move the demonstration of this use-case to a future blog-post.

    You would like to test Joe Sandbox Class? We have setup a free analyzer service which can be found at www.class-analyzer.net.


    Analyzing Android/SpyBanker

    Today we will take a look at an Android malware that is generally labeled as "Android/SpyBanker" (part of the Android.Gepew family). The sample we will be look at has the MD5 0d28fa54f9c0d41801e8fb5a7b0433dd. Attention was brought to us looking at Symantec's blogpost, so we were quite interested to see if Joe Sandbox Mobile, our Android analysis system, would allow similar or even more insights into the malware behavior without much reverse engineering effort and minimal time.

    To be more concrete, the sample is part of a larger attack vector that stems from Windows, in an attempt to infect an USB connected device with a fake Android App Store that acts as a banking trojan, but has some interesting functionality. This type of attack vector is rather new, albeit we have seen the opposite direction (mobile device trying to infect Windows) before (see Android.Backdoor.Ssucl found about a year ago). Finally, we may note that we've introduced a "harmful classification" of samples and Joe Sandbox Mobile was able to mark the APK as malicious straight away. A fresh VirusTotal result determined that only 29/50 AV engines detected the APK as malicious (timestamp 2014-02-18).

    Report Overview

    As always when analyzing an APK (or any file in another Joe Sandbox product) we start out looking at the head of the report, that is where the behavior signatures are located that give a good first idea of what the sample is capable of doing and offer entrypoints into the disassembly code.


    Besides the suspicious signatures dealing with the network part, the "Boot Survival" (starting a service on phone boot), SMS Sending and Phone call Blocking signatures are usually a strong indicator for malicious behavior, if they appear in combination. The "Deletes other packages" signature, as we will see later, is part of an automatic "app re-installation" functionality that overwrites local banking apps with malicious versions.
    As a next step, let's take a look at the "Static Info" area of the report to get a better idea of the permissions requested or additional entrypoints, such as the registered receivers or services. It is usually quite easy to find interesting code locations following these points.


    As we can see, the APK wants to be notified about BOOT_COMPLETED, PACKAGE_ADDED, PACKAGE_REMOVED and some Phonestate/SMS related events. All of which are probably used to intercept incoming banking SMS (TAN numbers) and for persistance functionality.  Also, we see that a service called "CoreService" is created where we will probably find a lot more interesting code. Seems like an easy deal so far. Let's dive into the code!

    Taking a deeper look

    Joe Sandbox Mobile uses Hybrid Code Analysis and allows the viewer to differentiate between executed and non-executed functions (at least for what is algorithmically determined as executed based on the instrumented subset), as well as annotated disassembly code for better understanding of in-out parameter data. Either way, it is easy for us to find the main entrypoint browsing the disassembly listings, as we know the main activity name from the prior static info analysis. So what does the APK do? Upon startup, the user is prompted to activate device administrator rights, if the phone is not rooted yet. Then, irregardless of the user choice, the CoreService is started.


    In the CoreService, sensitive user data is gathered and sent initially to a C&C server. The C&C server URL is read from a shared preference file (in this case it is http://www.slmoney.XXX):


    Sensitive phone information, such as the phone contacts, the IMSI and the IMEI are extracted and appended to an opening URL connection:


    Depending on the C&C server result, a variety of commands may be executed. The command handler expects a JSON string and has a variety of commands, among of which the "changeapp" command is probably the most interesting, as it is used to replace existing APKs with malicious versions (in this case, banking apps):


    The C&C "auto installer" functionality to replace existing apps can be found here:


    First, as we can see in the screenshot above, a list of installed APKs is queried (we have a signature hit on the call, thus the function name is highlighted). The list of installed APKs is compared against a list of known banking target package names (e.g. com.korea.kr_nhbank):

    An "app.auto.install" event is sent to the core service handler:


    ... and finally CoreService.autoChangeApk is called.

    The last parts were not executed, because the C&C server is down and not responding to our initial request. In a future release version of Joe Sandbox Mobile, we will extend the cookbook with a command to simulate custom APK specific broadcast events, that would allows us to simulate some internal C&C trojan commands in a second run, but it is out of the scope of this blogpost.

    Full Analysis Report: