Static and Dynamic analysis of malware dropper

Hi there. Today we shall reverse a unknown .exe file to analyze whether it is malware. If it indeed is malware we will unravel its internal functionality. Let's get going!

You can download the binary file from this link. The password is re1012018

Disclaimer: The sample provided may contain a software that is potentially harmful to your system. Open it with all due precaution. Please use Virtual Environment for analysis. I will not be responsible for any damage caused to your system. YOU HAVE BEEN WARNED!

Before we proceed any further, below is a list of the tools that we shall be using in this post. As a reverse engineer, these tools are the must haves for you. So make sure you download and install them before proceeding any further.

• IDA Community Edition : Dis-assembler
• X32dbg : Debugger [ You can also use Ollydbg.]
• PEStudio : PE file viewer
• Fakenet : network simulator
• Wireshark : packet capture
• Sysinternal suite

Every malware researcher follows his/her own Triage analysis techniques. Here we shall use most prevalent one as stated below:

1. Check on VirusTotal
2. File analysis
3. String analysis
4. API analysis
5. Detonation
1. network sniffing
2. registry monitoring
3. file system monitoring
4. process monitoring
6. Dis-assembled code review
7. Debugging the code.

Static Anaysis:

Step 1) Submit file to VirusTotal

As following image indicates VirusTotal has detected this file as malicious with Community Score of 54 which means 54 of 72 AV programs identified file as malicious.

Most of the AV programs identified the program as Dropper.

But there were few who claimed file to clean.

Even though as this point we can be pretty sure that file is malicious, we need to further analyze the file to gauge its exact functionality. The goal here is not just to tag the file as malicious/non-malicious. It is also important to develop host and network based signatures to feed our IDS and AV programs so that they can capture similar files in the future without manual intervention.

Step 2) File Analysis

File utility in Windows has detected file as PE32 Executable.

PE file is executable file format in Windows Operating System. We can also validate file format by opening file in text editor. If first 2 bytes are MZ which is PE Signature then file is PE file.

Step 3) String analysis

Lets open our file in PE Studio for further analysis.

Following strings can be found in String tab of PE Studio

• stage2.exe
• definitely-not-evil.com
• User-Agent:Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:47.0) Gecko/20100101 Firefox/47.0
• Im totally malware
• totally not malware

Step 4) API analysis

When we open Imports tab in PE Studio, we can see list of  Windows APIs used by program.

From the information drawn from Step 1 through Step 4 so far, we can draw following probable inference:

• File is some sort of dropper which downloads/executes additional malware
• stage2.exe string along with CreateFile and WriteFile import functions indicative of fact that additional payload is stored with this name.
• Presence of Browser User Agent and URL string  definitely-not-evil.com indicates that malware needs to connect to internet
• But libraries and API imports do not list any networking related APIs such as wininet32.dll
• Then how does malware unload additioanl paylaod? 

Let's analyze further.

If we notice image provided above carefully, PE Studio has detected an Executable Resource in the resources section of file.

This means that malware is holding additional PE file in its resources section. Malware needs to unload this file into new file using FindResource and LocateResource APIs. We indeed can find their use in Import section.

Thus we can conclude that Dropper is creating additional file named stage2.exe that connects with remote server of URL  definitely-not-evil.com

We can corroborate these findings by dumping the resource into file and further analysing it using PE Studio in similar fashion.

We notice following imported APIs in the payload file.

• CreateWindowExA
• IsDebuggerPresent
• InternetReadFile
• HttpSendRequestA
• InternetConnectA
• GetCurrentProcess
• TerminateProcess
• etc

These functions indicate that program connects with remote host and downloads file.It also opens a new GUI window as presence of CreateWindowExA function indicates.

Now that we have some general idea of what malware does, let us now execute it in sandbox environment to validate our findings.

Ensure you have setup a secure private network that is not connected to Internet. This is essential to avoid malware spread across the entire network. Ensure you use Virtual Environment to detonate malware.

Dynamic Analysis

step 5) Detonation

Following are the pre-requisites for the dynamic analysis:

1. Virtual system to execute malware
2. Simulated network to ensure malware attempts to connect to C&C server
3. Network and File monitoring tools [As we did not find any registry modification functions in imported list, we need to monitor registry changes here.]

I am using Windows 10 OS where I have already installed Wireshark, Fakenet and Procmon to carry out detonation.

First start all tools before hand in the following order: Fakenet,Wireshark and then Procmom.

Then rename file from Unknown to Unknown.exe. Then double click on it to execute. Make sure all tools are listening for events before executing the file.

A new popup windows is displayed as shown below:

Unfortunately we do not see any activity at Fakenet window:

Let us look at events captured by Procmon. The Procmon by default captures all the system calls being executed by processes in the system. We need to filter these events to the calls made by process/malware we are analyzing only, to make analysis manageable.

Two system calls are of particular interest here:

                            Writefile

                         Process Create

Apparently, as our static analysis rightly predicted, this malware has dropped second sample at location <User\Home\Directory\Roaming\> with name stage2.exe

It also executed this stage2.exe using Process Create system call.

We have so far been able to analyze the malware to the extent of predicting that Dropper will load additional malware and stage2 shall connect to remote host. But when we detonated the malware we did not see any network traffic. 

Thus to answer why we need to dive much deeper now and use next step of reviewing disassembled code of malware.

6) Dis-assembled code review

While there are many dis-assembler in the wild to use, we will use most famous one: IDA Pro. Use can use it's community edition which is freely available.

First we shall review original malware sample Original.exe and then stage2.exe

When we open Unknown.exe in IDA we immediately notice that it uses very few functions:

This is expected from a Dropper program since its only job is to unload extra payload, execute it and then exit.

start function is where we shall begin our analysis. 

It's a small function. All it does is makes a call to sub_401000 and then displays a message box we saw earlier.

Lets proceed to function sub_401000. A quick scroll through this function makes us evident that here resource payload is being written to file and being executed in new process.

locate and load resource

write it to file

execute the payload

At this point we dont need to analyse any further into this code. Its evident that main functionality of malware lies in stage2.exe

Let us open stage2.exe in IDA.

Again this sample also has very few functions.

start function of this sample is a little bit complex than previous one. We see use of loop and messaging functions here.

We can proceed to analyse function sub_401000 because that seems to be the only non library function being called from start.

This function is tasked with connecting with remote host and downloading a file to buffer. This can be seen from following images:

internet handler being created

make http request through handle

loop to read incoming stream into buffer

Here we can validate our findings by quickly detonating stage2.exe with fakenet running to see malware attempting to make connection to remote domain.

The content of file is loaded into buffer referred to by EDI register which holds pointer to variable var_104 as is evident from image below.

here effective address of var_104 is loaded in EDI before call to function

 

Code construct after this call is validating the loaded content to ensure that is what it is looking for. As we are not actually going to let malware connect to remote host, we need to pass this validation barrier using debugger.

7) Debugging the code

We need to pass validation construct before we get any further. Here we take help of X32DBG

Open x32dbg and load our binary by drag and drop feature.

We now need to set break point at desired address so that debugger can halt execution there. For this we need to know address of instruction in the file. To know this, first enable line prefixes in IDA by Options > General > Line prefixes.

Once enabled, we see addresses as follows:

Note the address of call instruction 401176. This is where we shall set breakpoint.

Use command bp in x32dbg to set breakpoint as follows:

bp <addr> ie bp 401176

we can see list of bp set

Now begin execution again by pressing F9. X32dbg will execute program till breakpoint is hit. Now we need to step into the function so press F7.

Once inside, we need to set breakpoint at point where httprequest is made. So set breakpoint accordingly. Also start Fakenet to ensure http request is catered to.

We can see the once httpSendRequest function is executed, we receive corresponding event in fakenet:

As can be seen, fakenet delivers configured IP address to DNS query just imitate DNS server response. Malware then proceeded with http request GET.

Now click on Execute till Return so that debugger proceeds with execution till execution returns to start function.

Immediately following function call, we have complex code construct we saw earlier. This is where we need to make changes.

Following are the 4 cmp instructions in the debugger. We need to make changes in the jump instructions highlighted. These instruction make jump based on Zero Flag[ZF].

The jump is taken only if ZF flag is set that is ZF=1. This flag is set based on result of previous instruction. Previous instruction is cmp, each of which compares indexed buffer value with predefined value. If found equal flag is set to 1.

But as we have not read any stream data into buffer, we need to manually alter these ZF flags.  This can be done by clicking on flag and hitting space bar which alters its value. So if value is 0 it will be made 1. Following image shows the code:

Once all jump instructions have been dealt with, we can again hit F9 which resumes execution.

We can proceed till code where call to CreateWindow is made. Once call is completed a window is displayed now as shown below:

Based on the code following this function call, it seems some sort of messages are displayed on this window.

Conclusion:

So we have now completed our analysis of a malware. We carried out both Static and Dynamic analysis. Though it was a long post it is necessary to lay down step by step procedure. All of these procedures may not be necessary for malware you are analyzing. None the less it is useful to know broad framework of malware analysis.

This post will act a base on which we shall proceed with analysis of other malware samples. We need not outline all the details henceforth. If you ever have doubt about certain step taken, you can always come back and check it here.

Teel next time, Cheers!