To start things of with this sample, before doing some basic dynamic analysis, its the best practice to take a look at the strings of the binary, using floss and redirecting the output to a txt file so they are easier to be read. Unfortunately this time the strings do not appear to have any fruitful information. After that, the binary is imported in PEstudio in the search for anything useful information that can be foudn there. In PEstudio there are some information on some API calls that are marked as suspicious by the tool.

Moving on to the strings we get in PEstudio there are some that might prove insightful and appear to be connected with network traffic and socket opening.

Going forward, using FlareVM as the detonating host, and REMnuxVM as a fake DNS Resolver, the malware is “armed”, wireshark starts capturing on the interface that the packets will go through and the malware sample is executed.

When looking at wireshark captures it is advised to always look for the “highest” protocol of the OSI layer first, which in this case would be DNS. In this packet, there is a URL that didn’t appear in the strings, which means that most likely it was “made”(concatenated) during the initial execution of the sample. Since there are no more interesting packets captured in wireshark, no http requests, no tcp, we are going to add the URL found within wireshark into the hosts file from windows in order to trick the malware thinking that the localhost(127.0.0.1) is the URL it is trying to reach or get a response from. So with that out of the way, we will launch procmon and set it to filter on `Process Name = sample name`, and `Operation contains TCP`. 

This appears to be a potential callout to specified DNS Record on the HTTPS port 443. Having that info, we will attempt to open a netcat listener on FlareVM that the analysis is taking place, which is the same that the sample currently thinks is the C2/Specified DNS server its trying to connect to. After running the binary again, there is some interesting output from the netcat listener. 

So far, this sample appears to be some sort of a reverse shell “generator/listener”.  Moving on we are going to take a look at procmon’s process tree to see if there are any fruitful information over there. 

Nothing really out of the ordinary, just taking a look at the structure of parent-child processes when a malware is spawned, to keep in mind that when looking at PPIDs and PIDs we can make our procmon filtering even better.

After this basic dynamic analysis the malware can be classified as some sort of a ReverseShell generator for a remote host.