Practical Malware Analysis: Basic Static Techniques
A writeup of the Chapter 1 Labs in Practical Malware Analysis by Michael Sikorski and Andrew Honig
This article assumes knowledge of virtual machines for malware analysis, types of malware, programming, and the PE file format. It is not a walkthrough of the labs, but rather my observations of the methodologies practiced in them.
Why analyze malware?
When faced with unwanted intrusion on a machine or network, malware is any form of software that causes harm or affliction to users, computers, or networks themselves. The methods that malware employs to do this includes a wide variety of techniques that are exploited for the gain of a bad actor.
It is important to be familiar with these methods and how they are executed programmatically, as the end goal would be to reverse engineer malicious programs in order to understand exactly what it is and how it works. This allows for better management of infected machines and networks after incidents, to harden devices and prevent further infection, and to also contribute to threat intelligence for an overall more knowledgeable grasp of what kinds of entities may be attacking any given organization or individual.
Basic Static Analysis
After capturing and securing malicious executables or dll files, the first step would typically be to perform a basic static analysis. This step is crucial before running the executable in a sandbox environment, as it offers glaringly obvious clues about the sophistication and functionality of the malware.
Basic static analysis can even indicate whether or not the specific files you have are already known and can be dealt with accordingly. It is the first glimpse into what types of problems the malicious files will present and what to look out for when taking action to restore whatever system it has damaged.
The Goal of Basic Static Analysis
Instead of diving head first into a full attempt to completely reverse engineer a program, basic static analysis can save time by allowing us to first identify if the malware is already known, hashed, and has a playbook for dealing with it accordingly.
However, unknown malware may present itself with a way for us to uniquely identify it. This identification, or signature, could include host-based and network-based signatures that could be indicative of infection.
But, primarily, the main goal of basic static analysis is to take a look at the obvious, as every second and bit of information counts when dealing with these types of threats.
Methods and the Information they Reveal
Antivirus Scan
An antivirus scan typically comes standard with most modern operating systems and performs these scans without the user even knowing. However, there are resources online that can allow for the parsing of multiple databases for specific files or their hashes. If it is known, malicious software, then it may be easier to deal with.
Strings
Binary data can be processed and read by tools in order to find strings within them. Given that the code itself isn’t heavily obfuscated or encoded unusually, bits of information from the strings alone can reveal a lot.
For example, if there is a string that contains a clear url, it may indicate that the program has networking functionality, can access the internet, and may even be able to manipulate the file system.
Strings can even be indicative of further executables and download link libraries being used by the program itself. This is a common way for malware authors to try to hide more functions that their programs can perform.
Detecting Packers or Obfuscation
Compression of files can be used to render data unreadable before it is decompressed. This is a particularly nasty form of obfuscation as it can sometimes bring basic static analysis to a dead end.
Examining the PE file headers can contain information about if a program is packed or not. Some indications would be the amount of space allocated for linking, or its virtual size, compared to the size of the raw data itself. Typically, if the amount of memory allocated is much larger than the amount of storage allocated for raw data on the disk, the program is most likely packed.
Luckily, when encountering packed malware, there are tools that can sometimes identify the packing method, which can lead to a way to unpack it for further static analysis before having to resort to actually running it.
Examining the Sections of a PE file
The PE file format is arguably the most important thing for malware analysts to look at, as it contains a wealth of information. The .text section, which contains the actual code, isn’t of too much importance until advanced static analysis techniques; however, the .rsrc, .rdata, and .data files can offer up many clues about the executables.
These sections are typically binary data, but viewing their strings or function calls can almost allow one to map out the code of the malware before even looking at it. It can contain actual function calls from dll’s, literally showing the malware’s functionality. Decent deductive reasoning can help us reach conclusions about what kind or malware it is that one is dealing with.
Any abnormal observations can also help create signatures for the malware if it is unknown. For example, it may be safe to assume that the malware visits a url and downloads more malware, based on observing the function calls and strings of a program. If the string indicates a specific url, and whatever files that it downloads, a network-based signature would be if there was traffic logged by the machine or network to the url. A host-based signature would be if there is the presence of the file that it downloads from the url on the machine. These types of signatures could then be used to diagnose more potentially infected machines.
Thank you for reading! Let me know if you learned something or if this interested you at: http://www.linkedin.com/in/colton-gabertan-463836209 !
