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
customers in the Joe Sandbox 10 release.
Full analysis reports: