On this section I will be running the sample I did the static analysis on in order to find network and host indicators. For this FlareVM will be used as the detonating machine, and a REMnux VM “faking” a DNS Resolver for the FlareVM so that we can track were the malware tries to send/receive data from.

First of all, starting inetsim and wireshark on the REMnuxVM is essential in order to have a DNS Resolver for the FlareVM and to capture the packets that will be created if the sample tries to communicate with the DNS Resolver, and the internet in general. Also, before detonation, “arm” the malware, removing the extra extension it has, leaving it only to .exe.

For this portion, some of the indicators found  during basic static analysis will be used in order to see if that portion of the analysis was correct. To start with I will be filtering wireshark with the one of what it seems to be a network indicator from the strings found in the malware, favicon.ico.

The malware sample indeed does a GET http request on that uri.

When it comes to rule writing for IOCs with yara for example, these kinds of network indicators will be very invaluable. 

After validating one of the network indicators found during basic static analysis, restoring the VM to the pre-detonation state is crucial, in order to detonate the malware again but this time looking for host indicators with the use of procmon, a powerful tool from the sysinternals microsoft tool suite. In order to get the most out of procmon, trying to use the filters option to the best of my capabilities.

To start, I will be applying a very basic filter which will filter on process name, since I don’t have any indicators from the basic static analysis in regards to host indicators. Like shown bellow:

After creating the first filter, the procmon UI will be empty as the malware sample has not run again, but when it does, the UI of procmon will look a bit more like this, 

When looking at the above image we can see certain useful information on what the malware is trying to do, but the column that should be focused more is “Operation”. This column is giving a brief explanation of what the malware is trying to achieve. For example, the “Operation” column can be a really goof starting point for making new filters, “Operation `containts`  `file` ”, this is going to give to the UI all the malware interactions with files. After applying the filter, and looking through the output, we can see,

which appears to be the same file path as the one found during basic static analysis, and indeed after following the given path, there is this file in there.

Following the search for host indicators, after finding out that this sample is trying to download a file from the internet and put it in the public documents directory, we can try running the malware again but this time without having inetsim running on the REMnux VM faking the DNS Resolver that the malware is using. For this, looking at the strings from the basic static analysis part, there is a string that looks like a killswitch for the malware, 

this cmd command will try to ping a webserver(could be a C2 domain of a malicious actor for example) if the ping doesn’t get a reply, it will delete itself from the disk. So we can use that string as a filter in procmon, again. After applying the filter, this is the details of the process involved.