Computer Malware: Core Basic Static and Dynamic Analysis Tools
Author: John Lawrence
For all prospective craftsmen understanding your tools is a vital part of learning the trade. The field of malware analysis is no exception, with a large variety of basic static and dynamic analysis at your disposal. Understanding how, where, and when to use them will ensure you gather correct information on your malware specimen. For those who are already accustomed to malware analysis many of these tools are as ubiquitous in their work as water is in the ocean.
In this exercise we will be focusing on tools used on Windows malware analysis machines. I can say from experience that some of these tools (netcat, virustotal, strings, wireshark) will work on Linux, however I can not say this for all of them. Without further ado, let us begin.
The term ‘static malware analysis’ means that you are analyzing the malware without executing it in any way. This means we are going to view the executables code and resources to the best of our ability and discern its behaviour from that. While this area of malware analysis is one of the simplest this should not detract from its importance. The information gathered will provide context for the rest of your testing and analysis.
There are numerous antivirus solutions available on the market today, each with their own different but similar ways of detecting and removing malware. A very common means of doing this is comparing the hash of the possibly malicious binary with known malicious hashes. Other means involve temporary sandboxes that do dynamic analysis, performing automated code review for malicious functions, and even some following known malware sellers to compare against their products.
For your average run of the mill malware analysis we can get this sort of information by querying our malicious binary through virustotal.
In this example I am going to take a neutered malware binary I have from my Practical Malware Analysis labs and run it through to get some results.
In this detection pane we can see how various antiviruses label the sample we sent in if it has been analyzed before. I also recommend viewing the other panes as well, with details providing great in depth file information some of which we will see in other tools as well. The behaviour pane will list detected file actions like registry changes, file creation, file deletion, etc. The community section is where other users will provide their ranking. You can also find the odd meme comment in here that is worth a chuckle.
Resource: http://www.fileformat.info/tool/hash.htm
Virustotal will try and provide you with the hashes for the file you submit, however it does not have all hashing algorithms represented. Whether you want to gather hashes a different way or using a less common function one thing is certain, having the hashes of your malware is very important. When performing your analysis the hashes will serve as a unique identifier of your malware without having to use the actual file.
I have taken the liberty of putting in that neutered malware I used for the VirusTotal section into an online hashing page.
Linux, Windows, and OSX all have tools for doing this without the need for accessing a web page if you so desire.
Malicious programs will need strings in order to refer to things like libraries, FQDN, IP addresses, and other important elements of their execution. We could use a hex code viewer or even just notepad to look for these in the file, however we have tools like strings to automate the retrieval of strings. You can get this as part of the sysinternals suite or located here: https://docs.microsoft.com/en-us/sysinternals/downloads/strings
When you first run it you will be provided the usage, I recommend adding in the ‘-n’ flag and setting it to around 5 or 6 when you first run it.
Let’s run it on that neutered malware from earlier.
We can see here that it is importing Kernel32 which is a library that every binary, benign and malicious, will be using. We can also see a bunch of functions for handling files from its important libraries. We aren’t always to see all of these though, if the malware is packed we will get few strings:
With so few strings it is highly likely this portable executable is packed using some packer. Regardless of it being packed however, it is going to always need Kernel32, LoadLibrary, and GetProcAddress. As such, be on the lookout for those during string analysis of suspected packed malware.
Resource: https://www.aldeid.com/wiki/PEiD
Even if malware is packed that doesn’t mean we are out of luck. Using tools such as PEiD we can analyze how the malware is packed and discern the packer. If we do this, we can find the proper unpacker and get the code.
Using PEiD is extremely simple, simply provide it the malware and it will provide you its best guess as to the packer. We will use that Lab01-03 from before for this example:
At the bottom area where it says ‘FSG 1.0 -> dulek/xt’ is the packer being used. If the malware is not packed it will provide you the language used for compiling:
Resource: http://www.dependencywalker.com/
We mentioned earlier about how in strings we can see imported libraries. With Dependency Walker (depends.exe) we can actually view these in a hierarchical style that provides the functions imported and exported along with them. I am going to open up that neutered malware sample with it for an example:
We once again see Kernel32.dll, after clicking it we can see in the upper right all the imported function used. Directly below is all available functions from Kernel32. By clicking the plus to expand we can see the DLLs within Kernel32 itself:
This provides us with an all encompassing view of the malwares libraries and functions (assuming it isn’t packed or has been unpacked).
Resource: https://www.aldeid.com/wiki/PEView
This next tool will require some preliminary information on the PE (Windows Portable Executable) file format. Here are two figures helping explain the sections:
With that out of the way, let’s use PEView to view the insides of our neutered malware which is in PE format:
As you can see we have a hierarchical structure of sorts the breaks down the file into its various sections. The header provides us with data on the location of the sections by hex relative addresses. Two other important parts we will look at are the .text and .data sections:
This is the section that contains the compiled code. Since it is compiled we will not be able to read it. Let us look at .data:
Here we get some global data, and this is in a human readable format. This mostly holds the libraries being imported. Make sure to also take a look at the other sections for more information, such as the .text and .data headers.
Resource: http://www.angusj.com/resourcehacker/
Executables of course require various resources for their operation such as images, sound, video, and even version info. During our static analysis it will be important to look for these resources and we can do that with Resource Hacker.
In this example I will be using the calc.exe located in your Windows\System32 directory:
With resource hacker we are able to open up these pictures used for the executable as well as view the version info within:
All of this information will be vital for understanding the various parts of the malware.
After completing our static analysis it may be needed to start performing some analysis while executing the malware. These tools below will assist you in making the most of your basic dynamic analysis.
VM | A completely separate machine with its own independent resources. Hardest to scale. |
Sandbox | An integrated testing environment that depends on its host machines resources. After finishing its resources will be unlocked and whatever changes it made should be cleaned. |
Container | Requires a host to run but separates its own resources from it like a sandbox. It’s resources are not used again after it is done running. |
Procmon is a windows system internal tool that lets you view all program events occuring on the Windows system. This tool will at first provide you everything, which would be near impossible to wade through. As such you will need to use the filter properly which is located in the filter tab at the top. Here are some good filters to consider during your analysis
Procexp, another sysinternal, looks very similar to task manager and for good reason. It performs many of the same duties by listing all of your processes and the resources you are using. It adds many additional features for organizing based on CPU usage, searching, and more:
An important addition is available by right clicking on a process and selecting properties. Here you can view detailed data on what it is using and even view the strings in it!
Regshot is a tool that in essence should take a snapshot before malware execution and a snapshot after execution. In doing so it will compare these two snapshots and provide you with a HTML or TXT report detailing the changes made. This is very useful for determining what sort of files malware will be changing during its execution and any registry keys/values it may add or modify.
[Note: This tool can be a bit finicky when it gathers its information, so it may freeze]
[Quick note: A common Linux based alternative to this is INetSim]
When performing dynamic analysis of the malware it may attempt to reach out to the internet to download resources or get commands. In order for the malware to keep running and send the request we can use ApateDNS to route its request to our own local or remote machine are get its request. By gathering the requests we can discover information on how it talks to a control center .
By adding number onto that # of NXDOMAIN’s section we can specify how many times we will return not found for requests. This can be useful if we want to see what happens if it doesn’t successfully reach its desired location immediately.
By running Netcat to listen on the port that our malware will reach out to we can be ready to receive those requests as mentioned earlier. In this case, the malware is performing a simple HTTP request that is sent to us thanks to ApateDNS.
Wireshark is an important tool for network analysis and that can certainly be applied to malware analysis. When you know that malware will be making network activity having a Wireshark instance capturing traffic will let you review and save the traffic: