For this sample FlareVM and REMnuxVM will be used for basic and advanced analysis. To start things of, and get an initial idea with what we are dealing with, lets extract the sample’s MD5 and SHA256 hashes and submit them to virustotal to check if this sample has been found in the wild previously.

By the looks of it, the sample could have some short of remote/reverse shell or backdoor creation capabilities, but in order to verify that, further investigation is needed. Moving forward, lets examine the strings from the executable and manually look through them to see if there is any more useful information. For this, the FLOSS tool will be used, instead of the “strings” tool, as FLOSS has some extra output, giving the researcher extra output on what the tool thinks are more “interesting” strings. Changing the output to a txt file will be more useful for reading through the strings. 

Looking through the strings, there are many `nim` imports that could indicate that the malware sample is written in the `nim` programming language. Unless of course the author of the sample has put in a lot of effort to make the strings “look like” the executable was written in `nim`.  With that in mind, let’s import the file to PEStudio and see what else we can find in terms of suspicious Windows API calls, flagged strings, binary architecture, file size etc. Basic IOCs, in other words. 

Indicators from PEstudio

Suspicious Strings from PEstudio

The malware is also for 64-bit architecture, which is giving us much needed information for using the correct tools while moving on with the analysis. 

Time to start with basic dynamic analysis, meaning, to run the malware with and without network simulation (using REMnuxVM) and try to check for new network and host based indicators. After initial detonation (execution) of the sample, without having inetsim running on the REMnuxVM, the malware will delete itself a few seconds after execution, which probably means that the malware is trying to make some sort of internet activity and when it realizes it does not have access, it deletes itself from disk. Now to detonate with inetsim, and wireshark running on REMnuxVM. 

The sample will initiate a three-way TCP handshake followed by the first network indicator, which is a GET HTTP Request on a URI. 

Following the wireshark capture, after the initial callback to [<http://update.ec12-4-109-278-3-ubuntu20-04.local/>](<http://update.ec12-4-109-278-3-ubuntu20-04.local/>), it seems like the sample is “feeding” data to another URI, maybe in some short of encryption through `GET HTTP` that can carved out or extracted in some way from the C2 server of the URI.

Worth mentioning is the fact that the first URI is not found in the strings output we got from the binary which means that it is most likely concatenated during execution. After wireshark, continuing the search for indicators and using procmon ,sadly, the binary does not seem to create any persistence mechanisms in the form of creating a file in the startup folder, or making changes to the registry.



From the strings output of the file, there was a `toRC4` method being called. RC4 is a kind of cryptographic cypher. To get more information on that, we will use Cutter, load in the binary and search for the given method.