Joe Sandbox X: Automated Dynamic Malware Analysis on Mac OS X

    We are proud to present today Joe Sandbox X - the first automated dynamic malware analysis system for Mac OS X. As with all of our productsJoe Sandbox X executes files in a controlled environment and monitors the behavior of applications for suspicious activities. All activities are compiled into a comprehensive and extensive analysis report.

    There are currently only a moderate number of known malware targeting Mac OS X systems. However, we at Joe Security think that the number of unknown Mac threats is high and since many companies are moving to the Mac world, Mac OS X will become more and more a hot target.

    To show some of the features of Joe Sandbox X, we have analyzed a recent malware named "xslcmd" (MD5: 60242ad3e1b6c4d417d4dfeb8fb464a1) that was deteced by FireEye about two weeks ago (VirusTotal 0 score 0/55 at detection time, 12/55, date of this blog post).

    Joe Sandbox X uses the same report format as Joe Sandbox Desktop and Joe Sandbox Mobile, so it is likely that you are familiar with the report structure. Let us walk through the report. From the behavior analysis report we see that the sample has opened a terminal window:

    Currently, Joe Sandbox X includes about 100 behavior signatures which rate and classify the behavior. The signature summary already gives a nice overview concerning some of the key functionalities of the malware:

    Static analysis which includes a Mach-O parser shows other interesting facts:

    The sample is able to run on three different architectures (Power PC, i386 and x86_64). Usually, Mach-O files only run on one or two architectures. It is likely that three architectures are supported to extend the number of potential target systems.

    Next, the comprehensive process overview shows the child and overlayed (forked then execve'd) processes of the initial sample as well as other processes started during analysis time:

    After startup the sample spawns the launchctl command which is often used to load a launch agent or launch daemon (service processes). The sample also starts itself again (see PID 275). Looking at the behavior of this process reveals its purpose:

    As the report excerpt outlines the sample deletes itself. Looking further down the startup shows that a launch agent process named "clipboardd" is started:

    Clipboardd starts the command "sw_vers" twice. Sw_vers prints version information about the operating system:

    Looking at the "sample-xslcmd" process (see PID 271) in more detail reveals that one of the created files is a plist file in the user's launch agent directory. This file is a necessary file when creating a launch agent and controls some of the launch agent' settings.

    The content of the plist file outlines that the launch agent is not started on system boot (XML tag false), where the other setting ensures that the launch agent keeps running. Also
    the dropped "clipboardd" file is executable (check out the Mach-O magic header bytes CAFEBABE):

    The launch agent is explicitly started with "launchctl load":

    Looking at the "clipboardd " process (see PID 274) in more detail shows that besides other activites two directories are created: ".fontset" and "BackupData". ".fontset" is hidden on Mac OS X systems due to the point prefix. In the "BackupData" a log file is created containing the term "##Terminal##".

    This is likely a log file of a keylogger (due to the suspicious name). Joe Sandbox X also enables to interact with the analysis machine, so we were able to run the sample again, simulate some user behavior and check the file content in order to verify our assumption:

    The service also tries to open the three files "pxupdate.ini", "chkdiska.dat", and "chkdiskc.dat". These files did not exist so the open calls were not successful.

    It is likely that these are configuration files and that the sample checks if the files exist to prevent reinfection. Finally, two hidden files named ".got" are created in the "Desktop" and "Documents" directory of the user.

    As some of the signatures already detected, the sample is actively communicating with the Internet. The included world map shows at a glance which countries have been contacted:

    When looking at the HTTP traffic, one can see the HTTP POST requests performed on a non-standard port to the fake host "":

    As this blog post outlines Joe Sandbox X enables to quickly understand and detect threats which target Mac systems. We continue our development to increase the number of signatures and also capture more behavior. Joe Sandbox X will be also available in Joe Sandbox Cloud, Joe Sandbox Complete, and Joe Sandbox Ultimate.

    Full analysis report for xslcmd:

    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: