Lab: Basic Malware Dynamic Analysis

The lab instructions are precise and we've got the hashes for the malware this time.

I begin by unpacking the malware and conducting some standard static analysis to gather some leads.

I get the strings output of the binary from floss, which ended up exhausting my cli's history so I saved the output to a file to be able to go through it without any hitches.

Now I this output didn't have any recognised strings by floss so I had to manually search through the all too long word list, so I just did Ctrl+F to look for keywords. Luckily it caught something very interesting on the first try.

I got what looks like a second stage executable, a suspicious URL and a mention of http client in use, i.e., Nim.

Since I saw a URL mentioned in the floss output, I decide to trial run with inetsim running first.

That leads to expected results as now I can confirm that the malware did contact this ec2 instance to request the second stage payload from it, it is a notable network indicator.

I revert the machine and try to get some host signatures now, I run procmon while filtering by process name, which gives a lot of information, much of it is garden variety registry modifications and permission grabbing.

I decide to add another filter, this time following another lead from the floss output, i.e., the path '\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup'.

Startup programs is a very good way for a malware to maintain persistence so it is very popular tactic to establish itself in there.

 

This goes to show that the malware placed its downloaded module in the startup directory. This module was also mentioned in the floss output, however the download requested was for 'msdcorelib.exe', the malware is seemingly storing the requested payload under the name 'mscoredll.exe'.

Storing a file which is supposedly a 'dll' as an 'exe' is extremely suspicious so I note this down as a host signature.

I also tried a clean run without inetsim and apparently the malware does need an internet connection as otherwise it just throws an error.

I wanted to know more about the connections the malware is making, so I open up tcpview with name filtering for the malware and detonate the malware while inetsim is running.

The malware has two TCP connections on port 80 of destination, these are likely from the download of payload. It is also listening on all addresses (0.0.0.0) on port 5555, which presents a wonderful opportunity as my remnux VM is also on the same network and I can see what the listener is going to do if I interact with it.

The connection seems successful, although it displayed something similar to a base64 encoded string. So I decode it with the standard base64 utility and it reads,

The repetitive string below is an error since I did not give it a recognisable command, which leads me to believe that this malware is the client for a C&C server.

So I try a few basic commands, `pwd` gives me the same error, i.e., unrecognisable command, however `ipconfig` does work.

This reinforces the initial assumption that the malware has command injection capabilities.

I try another command, however with procmon watching this time to see how it reacts to a command.

So it tries to find the executable with the command name in its local directory first, and then looks for it in the `Windows\System32` directory, if found it'll execute it and send the output as a base64 encoded TCP response back else it'll just respond back with an error.

With the information gathered I can conclude that this is a Remote Access Trojan with Bind Shell and Command Injection capability along with the capacity to establish persistence.