Joe Sandbox 10: Analysing unpacked PE Files and Memory Dumps with IDA

    As you know the current Joe Sandbox version is 9.0.0 which we released in the end of March 2014. Since then we have implemented a set of very cool new features which we are going to release soon with Joe Sandbox 10. Some of them are outlined in this blog post.

    Let us have a look at a recent Retefe e-banking trojan (MD5: 894c20f0d97c5a1dee106331e00abd48):

    Compared to some other well known e-banking Trojans such as Zeus, SpyEye or Citadel - Retefe does not intercept network traffic directly on the host. It also does not install any malicious code. Rather it configures a rogue DNS server on the victim system. As a result the bad guys control DNS resolution and can redirect to their fake banking webpage. However nearly all e-banking portals use HTTPS today. So a vicitm would notice that there is no HTTPS or a certificate error:

    In order to stay hidden Retefe installs on the vicitm system its own root certificate. Thus the browser trusts the rogue HTTPS certificate.

    As some initial cuttings from the Joe Sandbox report shows, Hybrid Code Analyis (HCA) has detected the function which installs the rouge root certificate:

    Central API to load a certificate is CertCreateCertificateContext. It creates a certificate context directly from a byte pointer:

    Wouldn't it be great to extract the certificate to block it generically? To do so we have to find the value of ecx. Joe Sandbox 10 includes a generic PE unpacker engine. As new supplementary analysis data it generates unpacked PE files one can directly load and run with a disassembler:

    Let us open the unpacked PE file and jump to the certificate function (some paths have been removed to improve simplicity):

    IDA's Graph View is very powerful and helps to quickly detect that the pbCertEncoded pointer is located at the address [436FC8+4]. Since Joe Sandbox captures memory dumps during runtime we can now easily find the corresponding dump, locate and extract the certificate:

    Joe Sandbox's PE unpacking engine is sophisticated but it is not always possible to extract a valid unpacked PE file. Sometimes we even do not have a PE file at all. This is especially true for shellcode and injected codes. Let us have a look at the analysis of a malicious Word document (MD5: b9f33467d0856e18129aca8f997eeaf8, 25/54 on Virustotal):

    After exploiting Zeus is dropped. Zeus is known to inject its payload into explorer.exe. If we look at Hybrid Code Analysis (HCA) results for explorer.exe we find a reference to Joe Sandbox IDA plugin file:

    The file is a definition of all Hybrid Code Analysis data Joe Sandbox has captured for the given process. We have developed a plugin for IDA to directly load memory dumps:

    The plugin creates a new segment, adds entrypoints, strings and functions:

    With the hot-key ALT-J one can load dynamic behavior data captured by Joe Sandbox. This is extremly helpful since IDA does not detect any API calls since the code is not part of a PE file:

    Of course the plugin works great to also analyze shellcode with IDA (blue prefixes outline dynamic code execution):

    Adding runtime data such as strings and API arguments to a disassembly output is exactly one of the ideas behind Hybrid Code Analysis. Runtime data helps to understand the disassembly more efficiently and enables to detect non-executed / dormant codes.

    The Joe Sandbox IDA plugin, as well as the unpack engine will be available for all Joe Sandbox Desktop, Complete and Light customers in the Joe Sandbox 10 release.

    Full analysis reports:

    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 The analyzer services are highly restricted but still leave some room for spying. We have experienced many attacks for all analyzer services (mostly 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 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!