<aside> 💡 In this sample, I chose a pretty well-known ransomware.

</aside>

To start things off, it would be a good idea to detonate the sample and see what it behaves like and how the “surface” of it works.

This is supposedly the decryption program that the malicious actors are going to use if the user pays the ransom. And following is a screenshot of how the desktop will look like after detonation. 

All the files in the system have had their extension changed to `.WNCRY` and have been encrypted. Also, some of the malware analysis tools that are installed with FlareVM are not able to be used after the detonation of the ransomware. 

Moving forward, we will extract the strings of the binary and take a quick look and see if there are any useful information in there. Not always are the strings useful, but it is always a great place to start with the analysis. For this, since it looks to be a bigger-than-usual sample, meaning it will most likely contain more strings, it is a good idea to redirect the output of the floss command to a `.txt` file and read the strings from there. Also it is generally a good idea to use the `-n` flag for our floss command in order to get rid of the random short strings. 

When going through the stings, this particular string (dos header) `!This program cannot be run in DOS mode.` appears more than one time, so we can make the assumption that this binary contains multiple packed binaries inside it. Bellow each of those strings, there are different DLLs APIs that look like to “belong” to each of the packed binaries inside our ransomware. There are also some random base64 strings, and these two **`C:\\%s\\qeriuwjhrf`, `C:\\%s\\%s`** that look like some kind of a paths, that might prove insightful further down the analysis. That % sign might be a token of some sort. Further down, there is also the first network-based string indicator, a URL, `http://www.iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea.com`. Lastly, from the useful strings, we have the following: 

cmd.exe /c "%s" 115p7UMMngoj1pMvkpHijcRdfJNXj6LrLn 12t9YDPgwueZ9NyMgw519p7AA8isjr6SMw 13AM4VW2dhxYgXeQepoHkHSQuy6NgaEb94 Global\MsWinZonesCacheCounterMutexA tasksche.exe TaskStart icacls . /grant Everyone:F /T /C /Q attrib +h .

Following the extraction of the strings from the binary, lets import it to PEview and take a look at the import address table. 

The original assumption that the file maybe contains more packed binaries inside it appears to be true. In fact, in has a total of three packed binaries inside of it. Also, these are some of the API imports that the binary is using, and they have all been blacklisted by PEstudio. 

Moving on, lets open up REMnuxVM and fire up inetsim to fake as a DNS Resolver and detonate the malware again and see how it behaves. Weirdly, if the sample gets a 200 OK response (which it does, from inetsim) it will not execute its payload and it will not encrypt the filesystem. So in the original detonation (in which I did not have inetsim running) the sample executed after “finding out” that there is no “internet connectivity” on the machine. Of course, even with inetsim we dont have true internet connection, but the binary thinks that we do, and does not execute. So in order to gather some network indicators and/or artifacts we will need to use tools that are on the same machine. For example, TCPView. 

After execution, the ransomware is trying to make a lot of TCP connection to what appears to be random IP address. We could make the assumption that this is how the malware will try to spread to other machines in our network through port 445, which is the default port for SMB. Another network based indicator would be a listener that is spawned after we let the binary execute fully. 

After the network-based indicators, lets try to collect some network-based indicators, with the use of procmon. As always, good filters will make the job much easier.