For this sample, only basic and advanced STATIC analysis will be performed. To get things started, using the trusted FlareVM, let’s load the malware in PEstudio and find out some of the initial IOCs, like hashes, size, strings and blacklisted API calls made within the malware sample. (Keep in mind that for static analysis does not need to be armed)

While waiting for PEstudio to load all the indicators, API calls and strings of the malware, lets take a look at the sample’s hashes and check them on virustotal to see if there are any previous hits. Along with the hashes of the file, we also have available, the size of the file, and the CPU-architecture, that the binary is written for, that can prove useful in creating IOCs and Yara rules for the specific binary.

Along with PEstudio, using PEview will also be useful in order to check the sample’s virtual and raw size. Comparing the two values can prove beneficial when trying to identify if the malware is packed or not. In this case it appears to not be packed as the two values are pretty close.(Even tho it is in hex values, using a programming calculator from windows they can be converted to decimal) If the value of the raw data was a lot more than the virtual data it could be an indicator that the sample is packed.

Continuing with PEstudio, in the in strings session, there are some strings that are clearly API calls used within the sample, and some of them have been flagged as suspicious by the tool.

Especially, the VirtualProtect, CreateRemoteProcess and OpenProcess API calls are highly suspicious for process injection, but that does not mean that the sample has to be flagged as malicious right away. A great resource to check how many malware use such API calls to achieve different kinds of things would be [malapi.io](<http://malapi.io>). 

Searching a bit more through the strings extracted by PEstudio, there are some indicators that the file could possibly try to download somethings, maybe we are looking at a dropper. This, sadly, is not enough to classify the sample as a dropper yet, since the strings do not contain any URL, but of course the URLs can be concatenated during execution. So lets just keep that in mind. Or the malware could be “unpacking” itself in that werflt.exe file.

Moving forward, after gathering some of the “easier-to-get” indicators, it is time to arm the malware and execute it, trying to find some host-based and network-based indicators. After running the sample, with TCPview running, we can see the following connection get created for a brief moment.

This can be a network and a host based indicator on its own as the sample creates the process of WerFault.exe and from that process it is opening a TCP listener on port 8443, which is the default port that Tomcat use to open SSL text service.

WerFault.exe is a built-in binary from windows, but the file that is unpacked from our sample is named werflt.exe, which is kind of suspicious and needs further digging. So, to continue we will be performing advanced static analysis on the unpacked (werflt.exe) binary, using Cutter, a free open-source Reverse Engineering tool. 

Always, starting from the main function of the program is assembly, we come across what is known as a common(but outdated) way to achieve process injection(as assumed from the strings/API calls from PEstudio)

So basically, this binary is getting an argument with the value of a PID which then is moved(mov) into the eax register which is then used as an argument for the OpenProcess API call, giving the binary full access to the specific process, and making it able to execute code from within and already running process.