Malware analysis

Static Analysis

Security Ninja
February 9, 2017 by
Security Ninja

In Part 1, we have seen that how to perform behavioral analysis on a malicious specimen. In this article, we will look at another specimen and perform behavioral analysis on it, but in this article, we would like to build some IoC's for behavioral analysis beforehand with static analysis of the specimen.

Static analysis involves analyzing or collection information about a specimen without running it. Remember even in the behavioral analysis we did run the specimen. Let's start static analysis with below-mentioned tools

Become a certified reverse engineer!

Become a certified reverse engineer!

Get live, hands-on malware analysis training from anywhere, and become a Certified Reverse Engineering Analyst.
  • Strings 2
  • PEStudio
  • PEFrame
  • Signsrch

Strings2 extracts both ASCII and UNICODE by default and is an enhancement over strings. It can also get strings over running processes. Below is an example for strings 2 in action

Straight away we can see important strings which referred to a .tmp file (may be a temporary file used by malware), Run registry settings, HTTP/1.1, InternetReadFile, sleep, etc. InternetReadFile will read file referred by HttpOpenRequest. We can relate this to HTTP 1.1 in the embedded strings.

Let's see the suspicious indicators from PEStudio. Below is a snapshot for the same. It shows file is not signed by any certificate and modifies the registry. That will certainly create some doubts.

We can also look at the embedded strings from PEstudio. Some interesting references here like CryptDecrypt which is an indicator that the specimen might deal with some encryption/decryption routines.

We can also use PEframe to find out suspicious IAT alerts which tell us all the DLLs it is importing and utilizing functions. For example, again we can see CryptDecrypt, CreateFile, CreateProcessA, etc. tells us lot of information about the nature of the specimen.

Now with all that static analysis, we can start out behavioral analysis to see how the specimen is utilizing these IoCs. Tools we are going to use:

  • RegShot
  • CaptureBAT
  • Wireshark
  • FakeDNS
  • ProcessHacker
  • ProcessMonitor

Before we are going to infect the system with malware, let's capture the state using RegShot. Take a 1st shot of the system.

Also, we are going to launch CaptureBAT to capture all transactions done from this malware sample. This will also generate a pcap which we can also analyze it with Wireshark.

Now let's start the behavioral analysis. Let's launch the malware specimen and let's observe the process monitor output. We can see that for the specimen; we see that a new file .tmp file is created with call WriteFile.

What is this file? Let's take a look at its contents. Below are the contents of the .tmp file. As expected it is obfuscated. Do not worry we will get around this.

Now after letting the malware run for approx. 40-45 secs, let's terminate the process and observe what our tools have captured. Below is a pcap file captured from CaptureBAT.

We can analyze the pcap file in Wireshark. We can see that it is trying to reach brb-3dtuts.by but since we are running it in an isolated environment, it cannot found it, but as learned from Part 1, we know how to get around this. We will come to that shortly.

There is a fantastic tool named ProcDOT which helps us to visualize actions taken by the specimen. It takes input from ProcMon and a pcpa file. We have both of these and below is the snapshot of the specimen activity after feeding those.

As we can see that it creates a file .tmp but also created a file we have seen above. Ok, that is another thing to watch out for. It looks like after creating these files, specimen kills that thread, but there is another thread for this process which is modifying the registry.

Ok, so let's give malware what it needs. Launch fakedns so that malware can connect to it. Below is a screenshot for the same.

Moreover, we can analyze the traffic from Wireshark to observe the same.

However, after connecting it is looking to connect to port 80. We do not have that running for now, but as mentioned in Part 1, we can leverage Netcat to start listening on that port. Below is a screenshot of the Netcat.

We can see that there is a mention of some file ads.php that the malware is trying to read from the server. Let's pick up the same activity from Wireshark as well.

Following TCP stream reveals us this.

I want to know what is this long string. Convert this to ASCII will give some gibberish output, which means that we will need to perform code analysis on it.

Become a certified reverse engineer!

Become a certified reverse engineer!

Get live, hands-on malware analysis training from anywhere, and become a Certified Reverse Engineering Analyst.

So I hope now we got a basic idea of how to perform behavioral analysis. In the next part, we will take a look at the code analysis of both the specimen discussed in Part 1 and Part 2.

Security Ninja
Security Ninja