Getting started with malware analysis could be very confusing and equally dangerous. In the previous blog , we did some fundamental research on a malicious pdf file. This time we will proceed a bit and learn some more stuff about malware analysis.

Now examining malicious software requires two most crucial steps:

  1. Static Analysis
  2. Dynamic Analysis

Note: We do have memory analysis, too, but we will go about it later on.

At this stage, we will begin with the static analysis.
In static analysis, we do not need to run the malicious program for analyzing it. We can break the code using a debugger and start going through what the code might have.

What do we precisely look for in static analysis???
We look for any special strings - which can give us an idea of the kind of calls the malicious program might be making. The calls and functions help us understand what the program might be aiming for - like ransomware or spyware or just a virus damaging files or anything else.
We also look for any URLs that the program might be communicating with.
We look for any suspicious behavior that might be dangerous for the system.

So, let’s get started :)

We will be using Remnux Linux for the analysis. We will learn about the tools while going through the article. We will try out the basic malware challenges from TryHackMe.

Scrolling below gives us a set of 4 tasks - out of which the first one does not require any analysis. Make sure to go through the introduction part properly, as it gives us information about how to unzip the sample malware files.

We will start with the next task.

Strings:: Challenge 1

This is how it looks -

We are supposed to enter the flag once we find it out. I will not be sharing the flag but will explain every essential step involved.

After the file gets downloaded, you will have to unzip the file using the password mentioned in the introduction section of the page. After unzipping, this is the name of the file.

Let’s run the two most relevant commands that we also learned in the previous blog on malware analysis.
file strings1.exe_

This gives us an idea about what kind of file it is. It is a Portable Executable file for a 32-bit windows machine, so if we run it in a 32-bit Windows system, it may corrupt it.

Going further, we will now run the next command, which is
strings strings1.exe_ | less

Since the strings command gives a lot of information about the strings used in a program, we use the less command. If you are using the less command, too, you may keep pressing the enter button to see the different strings used in the file.
If we observe, we can find that it has used several strings that look like the flag that needs to be submitted to confuse the users.
In the real-world scenario, we see a lot of function calls or URLs, or libraries used by the malicious program to corrupt the system.

Since this is a challenge and we are looking for a specific flag, we need something more.
We will use Ghidra for further analysis.

What is Ghidra?
Ghidra is an open-source reverse engineering tool. It is beneficial, especially for performing static analysis. You can download the tool from here
Once you launch Ghidra, this is how it looks like -

It opens some other windows as well that can help you to get started with Ghidra.

Moving ahead, we can directly start with importing the file that we want to analyze.
You may create a project too, but at this point, we will start with importing files.

You can click on the file menu and choose import file as shown in the figure (you may also press the “I” button from the keyboard)

It opens the dialog box to choose the malicious file you want to import, as shown below.-

Click on the select file to import.

It opens another dialog box that gives more information about the file; click on OK so that the tool can debug and give you the essential information.

It summarizes the details that it found from the malicious file; click on OK to move ahead with further analysis.

Once you import the file, double-click on it and observe that the file is yet to be analyzed; again, click on the yes option to move ahead, as shown below. -

You click on the analyze option, and then you are ready to get all started.

Once done, this is how it finally looks like -

When you start analyzing the code, you look towards your left-hand side, where a program tree consists of functions. This is the most exciting part which we are going to look into.

We click on the functions part and see an option as - entry. We can look for the other options, too, just to examine and study more, but we can now click on the entry option as shown below.

As you can see on the right-hand side, there is a decompile entry, where we see some code snippets formed by the program with the help of the binary that we have. In the decompile entry, we see the md5_hash function along with a flag.
Go ahead, copy the flag and add it in the task2 answer area and the challenge is solved :)

Strings:: Challenge 2

This is how challenge 2 looks like. You will have to download the file and use the password to unzip the file like in challenge 1.

This challenge also requires the same steps as shown in challenge 1 - using both the file and strings commands. Since we didn’t get much, we directly imported the malicious file in Ghidra.

After importing and analyzing the file as shown in challenge - 1, the file looks like this.

Now again, checking on the left side, you see the same function options under the symbol tree section, and we click on the entry option to see what the decompile entry looks like.

While analyzing the decompile entry, we see the usage of the md5_hash function along with the initialization of several variables. Hex values have been assigned against these variables.
One thing that we can try at this stage is checking the hex values if they are giving any hint or maybe the flag itself.
So, we observe that local_2c is a character, and it’s ‘F’, so we start converting each of the hex values one by one.

We can use any online converter from hex to text, and this is the result that we get:

Since ‘F’ is already there in the beginning, we see a flag generated, and we put it in the answer section of the challenge, and boom!! It gets accepted, and now we move to the next and final challenge.

Strings:: Challenge 3

This is how the last challenge looks like -

You will have to download the file and use the password to unzip the file like in challenges 1 and 2.
This challenge also requires the same steps as shown in the challenge 1 part using both the file and strings commands, and since we didn’t get much, we directly imported the malicious file in Ghidra.

We will follow the same steps as we did in the first two challenges and the file looks like this -

Again, we will follow the same steps, move to the symbol tree section -> click on the functions -> analyze the entry option first.

This is how it looks like -

In this decompile entry, we see a code, and we will try to understand the code now.
While analyzing, we observe that two functions have been called - FindResourceA and LoadStringA. When we click on each function, we understand that the FindResourceA is loaded from kernel32.dll library and LoadStringA from user32.dll library.
Also, we can notice a slight hint of the flag just beside the LoadStringA function.

We can see this all from the below image :

One thing that we can comprehend is LoadStringA function is loading the string from its reference, and it is getting stored at the local_4a4 variable as shown below:

Let’s find out the entire flag :)
Since we have some hint of the flag, we can find that string in the tool. We click on the search option from the top menu and then click on strings as shown below:

In the filter tab, we can write the string that we saw beside the LoadStringA function.

And there you go, we found the flag…

Congratulations :)

And we are done with basic Malware RE challenges from THM. Ofcourse it was not that difficult but it did give us some basic ideas of how to analyse a sample binary file. These are some first steps towards learning malware RE. We simply did static analysis and made use of some new kinds of tools as well. It seems we are moving ahead gradually. Next, we will try static analysis of an actual malware and run the same commands and tools to understand how an actual malware file looks and how it is supposed to run.