Detect Generically Ransomware With Joe Sandbox 7.4.0

Malware which blocks your computer in order to demand a ransom has become extremely popular. Most of them are delivered via exploit kits. Recently even some of our friends and relatives got infected by these nasty programs. It turned out that often an old Java installation was the gateway for the infection. However, although a known up to date Anti Virus Solution was running, nothing got detected. Thus we thought it might be worth to research some techniques to generically detect ransomware.

If we let Joe Sandbox analyse a recent ransomware sample (MD5: 3e99fab7f175eb8bf283b1e883c714c9) we get the following report artifacts: 

As you see the malware injected code into the trusted processes explorer and svchost. Inside svchost it created an autostart key. If we check out the screenshots captured by Joe Sandbox we can see what has happened:

Due to the last screenshot it becomes suddenly clear that this is ransomware. In addition there are some additional artifacts in the report which describe how the malware creates the top level window to block access:

Windows contains functionality to handle virtual desktops which is abused by the malware. It creates a new virtual desktop called "MyDesktop". Later it switches to the new desktop and creates an overlay window to lure the victim to pay a ransom. As Windows does not offer any default hot-key to switch back to the original desktop, operating the computer becomes tedious. Thus the new desktop is an excellent scheme to block operation.

To detect ransomware one may think of detecting code that creates / switches to desktops. However, this may lead to false positives, since all virtual desktop tools (e.g. VirtuaWin) use these APIs. A much more elegant and generic approach would be to detect key aspects such as display text (e.g. block, copyright, violation etc.) of the window shown to the victim.

One way to do that would be to enumerate all windows, control fields and dialogs and query their display text. However, this may be easily prevented by  malware using custom controls or GUI frameworks such as QT. A much better approach is using OCR (optical character recognition). We used that idea to develop a cool signature:

• Collected over 400 screenshots of different kind and versions of ransomware (a very good source are https://www.botnets.fr/index.php/Accueil and http://bka-trojaner.de/)
• Feed the screenshots to GOCR (http://jocr.sourceforge.net/)
• Statistically analyzed the recognized words

Afterwards we wrote a simple but powerful signature to detect relevant keywords within OCR output:

The statistical analysis showed that in most cases ransomware uses Ukash and PaySafeCard for handling the payment. Thus we used these word for detection. In order to deal with the problems of imprecise OCR output we set a threshold of 80% for word matching based on the Levenshtein distance.

Finally we tested the signature:

In order to detect ransomware we created the following logical formula:

If "creates an autostart key" and "creates a new desktop" and  "shows paysafecard and ukash on the screen" => ransomware

OCR output will be present in all Joe Sandbox 7.4.0 reports. Complete Joe Sandbox Report can be found here: Joe Sandbox Analysis Report

Quick "Visaform Turkey.pdf" PDF Zero Day Analysis

Two days ago FireEye has detected a malicious PDF exploiting all major PDF readers from Adobe (FireEye, In Turn, It's PDF Time FireEye, Number of the beast).

We got the sample (MD5: f3b9663a01a73c5eca9d6b2a0519049e) and started an analysis with Joe Sandbox 7.2.0 on Windows 7 x64, Adobe Acrobat Reader 10.1.0 installed. What follow are some interesting cuttings from the report:

Striking facts:

• The exploit works well on Windows 7 x64! This is interesting since the Acrobat Reader we are using runs on WOW64 on 64bit systems.
• The sample sleeps 3600s to bypass dynamic malware analysis systems (this was already detected by FireEye)
• The sample drops two dlls, one for 32bit and one for 64bit
• The sample drops and opens a fake pdf (to trick the user believing nothing happened)
• The sample checks if it has access to the internet (get www.google.ch)
• The sample contains functionality to download additional files
• After sleeping the sample uses heavily http for its communication

We are currently analyzing the sample with our cookbooks to bypass sleeping malware (Defeating Sleeping Malware) and are going to follow with a detailed blogpost about the sample payload.


The complete report is available at:

•  Joe Sandbox Analysis Report for Visaform Turkey MD5 www.joesecurity.org/reports/report-f3b9663a01a73c5eca9d6b2a0519049e.html

Analysis of with Joe DD:

•  Joe DD Analysis Overview

CVE-2013-0422, java 0-day: Technical Payload Analysis

Some days ago a new java 0-day (CVE-2013-0422) has been spotted in the wild (thanks to Kafeine). The exploit targets Java 7 including the latest Java 7 Update 10 release. For protection disable any java plugin within browsers.

According to Kafeine one of the dropped file is the following:

• UTTER-OFFEND.exe (MD5: 237f8ffc0c24191c5bb7bd9099802ee4)

We thought the binary is a good test for our newest Joe Sandbox release. An initial analysis revealed the following startup and signature overview.

Some striking behavior facts from the startup and signature overview:

• Contains tricks to detect virtual machines
• Starts svchost.exe which is legitimate Windows process and writes its process memory, changes threat context
• Creates an autostart registry key
• Deletes Windows safe boot entries
• Delete initial dropped binary
• Creates a new desktop

Lets analyze the individual facts in detail.

Anti-VM tricks

The binary queries the video bios version via registry:

Opens local disk devices:

Using Joe Sandbox SCAE (static code analysis engine) feature enables to understand in detail what happens at code 40141F:

Function 4013C0 opens the drive device (PhysicalDriveX) and communicates through DeviceIoControlCode with it. 2D1400 is the second DeviceIoControlCode (IoControlCode) . A quick Google search revealed that code 2D1400 is IOCTL_STORAGE_QUERY_PROPERTY. If successful DeviceIoControlCode returns in the fourth parameter a buffer of format STORAGE_DEVICE_DESCRIPTOR. The descriptor contains VendorId, ProductId, ProductRevision, SerialNumber strings. The strings are checked in function 401B40:

Qemu, VMware etc are product id strings which are used for comparison (strstr).

For protection the sample checks if its own file name equals sample.exe or virus.exe (GetModuleHandle, GetModuleFileName). If true it deletes itself and terminates.

Function 401B40 is also used to check the value of the VideoBiosVersion key.

Beside these anti-VM tricks based on system artifacts the sample also uses the VMware backdoor I/O port to detect VMware, function 4019F0:

In addition the sample also verifies if wireshark is running (Function 401D50) or if its running sandboxed (Sandboxie: SbieDll.dll):

Infection and Persistence

For injection the sample uses a combination of different strategies to get into svchost. Beside mapping a file to a remote process (NtMapViewOfSection) it also uses WriteProcessMemory to inject its own file into the remote process. For code execution it modifies the context of a thread in svchost.exe (SetThreadContext):

Within svchost.exe it deletes itself, deletes the Windows safeboot entries and creates autostart entries:

Target

In function 413440 the sample creates a new desktop and switches to it. As a result the current desktop with all its windows gets hidden:

Next it creates the following screen (Function 40100 ensures that no other window is overlays the current window):

For understanding the network functionality have a look at function 4150B0 (registration at admin panel), 413500 (querying ip-address.com for getting IP & provider information to display on screen to raise awareness).

All these facts are present in one single Joe Sandbox report which enables you to understand the complete payload and its target within minutes:

• Joe Sandbox report-237f8ffc0c24191c5bb7bd9099802ee4

Happy New Year!

The Joe Security team wishes you success, satisfaction and many pleasant moments in 2013!

Preview: Analyzing Office Exploits with Joe Sandbox 7.0.0

Lately we have seen an interesting word document (Original Name: Problem Feedback.doc, Virustotal Result 6/44, Date 15.11.2012)  been analyzed with Joe Sandbox 7.0.0 in our cloud service Joe Sandbox Web. As one of the major extensions we have added a Static Code Analysis Engine (SCAE) to Joe Sandbox which enables to understand in detail code functions executed or not executed by the sample under analysis. The code analysis engine is feed by memory and "ret" dumps dynamically created by Joe Sandbox's Thread Analysis Engine (TAE) .

A good start for analyzing office documents is using our cookbook for exploit analysis. The cookbook uses the new command _JBEnableRetMemDumping(). By enabling "return dumping" the TAE captures and stores for each function / system call the code areas where the call has been started from. Because shellcode is often placed in the heap and only available for a short time "return dumps" are perfect for capturing any code fragments executed. With traditional memory dumping tools which only take a dump at a predefine timepoint one would not be able to catch shellcodes in general.

Below you find the process startup / signature part of the Joe Sandbox report generated by using the exploit analysis cookbook:

As the picture outlines we have develop generic signatures to identify document exploits and shellcode artifacts (Joe DD demonstrates how good these signature work to identify any document exploit no matter if the exploit is know / unknown / a zero day). Navigation of the top menu bar leads to the disassembly section of the report:

SCAE has identified successfully some shellcode function as well as strings. Most interesting is function 26F002A:

The API calls executed by the shellcode have been identified by SCAE altough calls are hidden and based on stack data (e.g. ebp+24h). All xrefs and targets are click-able, enabling smooth browsing through the code function data. Function 26F002A contains the key functionality of the shellcode which is basically the extraction of a PE file located in the world document itself:

One of the big features of the SCAE output is that all code function are linked with dynamic behavior information. Thus an analyst can easily navigate from dynamic to static information. The picture above shows the PE file which is dropped / extract.

The complete Joe Sandbox exploit analysis report is available at: report-46e6a921eef3dafb97bf041147244f76

Beside the shellcode analysis the Joe Sandbox report reveals the following interesting facts:

• The name of the initial dropped file is dw20.exe. The file name dw20.exe is also used by Microsofts Application Error Reporting tool. It is launched by Word if a malformed document has been opened. However for this analysis dw20.exe is dropped / malicious file. We think using the name dw20.exe as a dropped file name is smart way to bypass exploit detect systems which blacklist child processes of Word by names.
• Dw20.exe drops the file fxsst.dll in C:\windows and then terminates.
• Fxsst.dll looks to be loaded once winlogon.exe starts due to dll hijacking trick (Microsoft  Security Advisory 2269637)
• Dw20.exe checks if Chrome is installed, if true it drops C:\Documents and Settings\Administrator\Local Settings\Application Data\Google\Chrome\Application\rasadhlp.dll, again tricking Chrome to load the dll via hijacking. This trick even looks more smarter since all programs have write access to "Application Data".
• A second analysis (report-08727a7100766e60026243601fa6ce3b) of Fxsst.dll with SCAE enabled reveals simple downloader functionality:

Full Joe Sandbox exploit analysis report with SCAE analysis for DW20.exe: http://www.joesecurity.org/reports/report-46e6a921eef3dafb97bf041147244f761.html

Some more Joe Sandbox reports demonstrating the shellcode analysis feature (checkout the nop-sled detection signature):

• report-2c4513647290a7e9817eba83e383973e
• report-6c95034d7506af5d3de408d1d2dfbd7d 
• report-d86d9b77f6abeb70596019dec77fa71d 
• report-58fdd7befdcfcfca285543d6e0c0da0f 
• report-4c7ecf0a53aa4cc759961b840ae04a6e

Defeating Sleeping Malware

During some large scale analysis test to optimize our signature sets we detect a sample showing the following behavior:

Joe Sandbox Analysis Report: report-8ebd97ee5f259cb2f1b38da1f1040cf0

The sample has started a couple of new processes as well as new service (smss.exe). Joe Sandbox has not found any malicious behavior, except that the "Contains long sleeps" signature has fired.

Sleeping to bypass automated malware analysis system, like Joe Sandbox, is not new but certainly used more these days. Because the malware is executed / analyzed for a short time only, the analysis system misses interesting activities after the sleep.

Basically there are two techniques to circumvent long sleeps:

• Increase the analysis time (do long term malware analysis)
• Dynamically modify the sleep duration

For doing long term malware analysis we have a special cookbook which executes the malware for more than 10 minutes.  The cookbook produces good analysis results, however we have seen malware with sleeps even longer. In addition it is smarter and efficient to modify the sleep duration dynamically.

A week ago we have implemented the following new cookbook command:

• _JBShortenSleepsGreaterThan(thresholdinseconds,replacementinsecond)

By using the command an analyst can specify how sleep duration are shortened. Internally the Joe Sandbox monitor driver automatically exchanges the sleep duration once a sleep call is executed by a sample.

With Joe Sandbox 7.0.0 all default cookbooks are going to use that command:

  Behavior analysis of the sample previously analyzed, by using the new cookbook:

After the 6min sleep the sample injects itself into lsass.exe. The injection technique is highly malicious and a good artifact for detection. In addition the sample starts its communication:

Analysis Report: report-8ebd97ee5f259cb2f1b38da1f1040cf0(1)

Using the _JBShortenSleepsGreaterThan has a big impact on the analysis results.

Sleeps with a long duration are also a good malicious indicator, since most legitimate software do not use it as malware does.

Shorting sleep and wait duration in general is hard. One may implement a sleep with the following techniques:

• for (int i = 0; i < 240; ++i) Sleep(1000); // Waits 240x 1s
• WaitForSingleObject(non signaled Semaphore / Event, 24000)

We are currently working on an extension of the _JBShortenSleepsGreaterThan command to also cover these techniques.

Preview: Analysing DirtJumper with Joe Sandbox 7.0.0

Since 3 months we are working hard on Joe Sandbox 7.0.0. Among small extensions the biggest improvement is the integration of a static code analysis engine (Joe Sandbox SCAE).

SCAE analyses dynamically generated memory dumps and extracts highly abstracted code functions to the analysis report:

For each code function SCAE detects strings, xrefs, constants, call type and function arguments. In addition we have development an unique and generic algorithm for detecting hidden API calls (e.g. for call eax).

All extracted code functions are connected to dynamic behavior information:

The picture above shows a section of the file open activities (all the files the sample under analysis has opened during execution). By clicking on the source address one gets redirected to the corresponding code function (Function 00414270 shown in the first picture).

What SCAE makes extremely powerful is its ability to detect and analyze code which has not been executed.

One of the big disadvantage of dynamic program analysis is that only a small fraction of the real behavior gets executed and thus can be analyzed. Imagine the dynamic analysis of DirtJumper a DDOS bot. The DDOS functionality only gets executed once the bot herder sends a special command to his bots. Therefore it is normally not possible to analyze and detect any DDOS payload by using dynamic analysis.

To the best of our knowledge all existing dynamic malware analysis system only detect and rate behavior information originating from the execution of the malware (often this is the installation behavior of the malware). They are not able to see any functionalty which has not been executed. Thus they are unable to see the real malicious payload. 

Thanks to SCAE Joe Sandbox 7.0.0 enables to analyze and see what has not been executed:

The picture above shows a code function which is used by DirtJumper to construct different kinds of HTTP headers. Since DirtJumper contains multiple HTTP flood techniques (e.g. POST and GET) it needs to craft different headers. Function 41D0E0 is called by Function 4291FC, which is called by another function in a loop. Sleep is used to control the flood frequency. All those facts are extracted and identified by SCAE and do not appear in any dynamic analysis result!

More facts we found about DirtJumper by looking at SCAE results:

• Works with IPv6 (Function 4181D8)
• Uses a fixed but extensive set of user agents (Function 429030, some of them are: Mozilla/3.01Gold (X11; I; Linux 2.0.32 i486) , Mozilla/2.0 (compatible; Ask Jeeves/Teoma), Mozilla/1.22 (compatible; MSIE 2.0d; Windows NT), Mozilla/4.0 (compatible; MSIE 6.0; Windows 98) Web Link Validator 2.x), Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.19 (KHTML, like Gecko) Chrome/0.2.153.1 Safari/525.19 )
• Contains an extensive list of VM artifacts to detect VMs (including Xen), techniques are based on registry key lookup and process enumeration (Function 4129B0, 412F30 and 4122B0)
• Various anti-debug tricks (Function 412190)
• Contains functionality to infect USB drives (Function 4153C0)

The corresponding Joe Sandbox 7.0.0 report can be found at:

• DirtJumper 6b16c4526a013e744b3d91cd7a091c36 analysis

Of course all static function data is passed to the Joe Sandbox signature interface. Be prepared for new and cool code signatures!