In this post let’s take a look at the basic methods of analyzing a file statically. Static methods of execution involve those methods of analysis in which the file is not executed. Though it is highly probably that a malware sample currently in the wild will not yield substantial information on being statically analyzed, it provides a good starting point. Let’s take a look at some of the steps that are involved in preliminary static analysis.
Step 1: Multi-AV scanners
Most people have an anti-virus installed on your devices. Though most people expect it to be a golden bullet against malicious software it is not so. Hence why depend on the result of analysis of one anti-virus engine, when you could have the file scanned by multiple anti-virus software. This is where multi-AV online scanners come in. Most of these websites are free and the software is regularly kept up to date. These websites scan the uploaded files using all the anti-virus engines they have and present a comparative reasult. Here is a list of some common multi-AV online scanners:
Step 2: Detecting if sample is packed using PEiD
Malware authors may often pack(obfuscate/encrypt/distort the actual byte pattern) to make preliminary analysis of the assembly level code hard/impossible. Since the original byte patterns are now modified, disassemblers will read alternate instructions if at all. This leads to significant loss of information that can be learnt statically. Though packed malware are very common nowadays, the good thing is that malware is often constructed by putting together modules, i.e. the packing function may be written by an author, the viral engine by another and so on. Hence there are certain behavioral or structural patterns that a software called PEiD uses to detect if the sample has been packed using a common packer, if so the corresponding unpacker could be used. Note: Not all packers can be detected using PEiD, the main usefulness of PEiD is that it can detect the packer/compiler used to produce the program. The information about whether the sample is packed or not can also be inferred by digging into the hex code or import/export tables in the Portable Executable.
Step 3: Mining the Portable Executable using PEview
The portable executable stores a lot of valuable information about the executable including details about when the executable was compiled, the functions it imports and the dll’s it imports from and so on. This information is presented in a nice format by the tool PEview. The things to notice in the portable executable headers are whether the compilation time is a valid time, whether the file alignment and the section alignment seem reasonable or indicate compression or packing, the size of segments, discrepancies raw data size and virtual size of sections and so on.
Step 4: Checking the dependencies of the executable using Dependency Walker
The easier way to analyze all the functions that are imported by an executable is using a software called Dependency Walker. We can try to predict the family or action of the sample file simply by analyzing the functions that it calls. A lack of functions almost always indicates obfuscated/ packed sample.
Step 5: Looking at the strings defined in the programs
Sometimes some important information such as the ip address of the command and control server, or the file that is created as an infection marker etc. are harcoded. Hence looking at all the strings in the executable might give us valuable information.
These steps only provide a very basic static analysis mechanism, though if any information is gained here, it is of substantial value. Future posts may detail advanced methods.