Joe Security's Blog

Some days ago we received notice by a Joe Sandbox Cloud customer (credits to Rafal Rajs) about an interesting sample (MD5: 3eebf8a3de8fbb1a92aeae7b22f81e23) which did not show its real functionality during analysis with Joe Sandbox, but perfectly on a virtual machine. This behavior made us curious so that we decided to analyze the sample more deeply and write a blogpost about it. The initial Joe Sandbox Report of the sample revealed the following data:







Thanks to our Hybric Code Analysis (HCA) technology Joe Sandbox detected that the sample contains some network DOS functionality. However, apart from that highlight the sample does not create any files, keys or performs any network connections and seems to be idle (it does not terminate). A look at the "Thread Delayed" category had a surprise for us:


It seems that the bot executes sleep several times, more precisely over 2 million times! A look at the corresponding function in the report revealed:



The sample executes the sleep(0) call in a for-loop up to 3912913 times. The same massive loop is executed in sequence three times. A sleep(0) does not really sleep, its only purpose is to pass execution to a different thread. Function 4092E0 is also the entry point of the PE file, thus it is the first executed code (as no TLS callbacks exist):



So why was Joe Sandbox not able to analyse the real functionaltiy of the sample? The reason is very simple: one of the big challenges of malware analysis systems is the handling of the anormous amount of behavior data. Thus it is very easy to flood and overload an analysis system by generating too much worthless behavior data (in our case the sleep call) before executing the real payload. Logging the generated behavior data introduces additional delays and therefore the execution does not reach the real payload.

This technique, which we call Sandbox Overloading, is not new. In fact we started optimizing our solution to handle large amount of data since the beginning. By using a simple POC test of our systems in March we were able to crash most public sandboxes including Anubis (Internal Anubis Error), Malwr (We ware unable to store the complete results: some error occured or the generated report was to big to be stored), ThreatExpert (has failed to reveal any technical details), Comodo as well as GFI Sandbox (no report received):

#include <windows.h>
#include <stdio.h>

void overloadSandbox()
{
    char Path[20];

    for(int i = 0; i < 100000; ++i)
    {
        // Prevent caching
        //sprintf_s(Path, 20, "C:\\test%d", i);
        sprintf_s(Path, 20, "C:\\test");
        DeleteFile(Path);
        // Successful operation
        //CreateFile(Path , GENERIC_WRITE, FILE_SHARE_WRITE, NULL,
        CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
    }
}

int main()
{
    overloadSandbox();

    // call payload
    CreateFile("C:\\payload" , GENERIC_WRITE, FILE_SHARE_WRITE, NULL,
    CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);

    return 0;
}

Overloading sandboxes is a very powerful technique to hinder dynamic analysis, since it is completely generic accross different implementation techniques (usermode, kernelmode hooking or emulator) and system architectures (VM or native system). That Rafal found a sample using that technique demonstrates that malware authors keep up to date with the latest success of dynamic malware analysis.In fact the sample overloads all public sandbox (Anubis, Malwr, ThreatExpert, GFI Sandbox and Comodo).

Finally, how do we analyze this beast? First, we can use the Joe Sandbox "network only" cookbook. With that cookbook Joe Sandbox analyses only network traffic and does not capture any system level behavior. By using that cookbook we detected instantly that is trying to resolve a domain:


In addition we could also write a signature to detect and blacklist the massive count of sleeps. However we still do not have any chance to analyse the system activites such as its installation behavior, etc. Thus we updated the Joe Sandbox's core engine to be able to detect and skip massive API calls dynamically and analyzed the sample again:





As can be seen quite easily, the sample is copying itself to another location, creating an autostart key and modifies the Windows firewall. All the activites would have been hidden without handling massive behavior data properly.

Full Joe Sandbox Report:

• SDOS Bot with sandbox overloading

We will continue improving Joe Sandbox to handle other sandbox overloading tricks.