Apprehending malware red-handed is a very exhilarating feeling for an analyst. Debugging technology provides a wealth of information about a malware's inner construction and layout, and, most importantly, its modus operandi. You can take the metaphor of an ultra-high-speed camera used to capture a slow motion video of a moving bullet that plots its trajectory as a projectile, which hits its intended target and the effects thereof, and compare that with a debugger used to capture the execution trace of a malware instruction by instruction. Things are seldom that simply extrapolated, and hence you could also compare an analysis session as a criminal interrogation (analyst/debugger/target sample) in a Spook black-site (sandbox) where you have the liberty to extract information in any manner you want, while dealing with the myriad obfuscations, retaliations, and unwillingness of the participant.

The primary methodologies in malware analysis are static and dynamic analysis, with the terms static and dynamic having dual overtones to their definition for our purposes. Static analysis can denote investigation of the executable format or the overall container of the binary code (as in other kinds of malware such as PDF/js/flash/HTML malware containing exploits) in order to identify anomalous attributes that will help in further investigation. This usually involves fingerprinting the malware, or its container and its various sections (figuratively and as per the PE format, literally), as well as scanning for outstanding executable format properties that point toward anything malicious. Static analysis also supports the act of reading assembly code extracted by a disassembler, which is analyzed manually by the analyst or using an inbuilt or integrated emulator without actually executing the malware in any major way. The exploit shellcode and in-disassembler unpacking can be analyzed, exposed, and made redundant without resorting to immersion and execution of the malware sample in the ideal OS environment. Emulator automation and debugging scripts can be written and deployed as the next steps in the tool or framework of your choice to assist in such excursions.

Conversely, dynamic analysis can represent manual debugging of the malware sample in a debugger, mostly in tandem with reading assembly code in a debugger. The dynamic session can also typify using a sandbox specifically engineered to automatically monitor the interactions of the malware on execution, with the OS environment and the outside world, to give an eagle eye view of the gathered information that acts as a fast-track malware analysis procedure.

Many if not all of the malware are obfuscated, compressed, or encrypted with creative techniques (or plagiarizing) implemented by the malware authors. Analyzing a malware in a debugger while exacting and precise can often become time consuming, which is sometimes more of a luxury than you can afford, and hence techniques such as sandboxing are in vogue. Both processes function as a trade-off in time required and the information procured. On the contrary, when used in tandem, they provide supporting evidence for each other further strengthening the investigation.

In this section, we shall see the process from the perspective of an analyst session and how he/she might use the myriad tools and techniques in the process to best find what the malware sample does in the fastest time possible.

From this chapter, you will learn how to:

Fortifying your debrief

Before we start with the analysis, let's explore our reporting tool Scrivener from Literature and Latte. This is quite a deep tool and you are recommended to visit their website at http://www.literatureandlatte.com/scrivener.php.

This amazing software is more popular with literary types (aka novelists and writers, many well-known names too) and academics, and not so much widespread within the computer security community. Some of the well-distributed tools for security research include MS Word, Notepad++, Ultra Edit, FreeMind, and Dradis among a slew of other text editors and such. However, it is strongly recommended that you use Scrivener for reasons that will become apparent the moment you start using it. Some of the useful features are a hierarchical note repository called Drafts managed in a Binder toward the extreme left which is a metaphor for a book binder with notes. You also have Research folder inside the Binder. The Drafts and Research components cannot be deleted. There is another metaphor called a corkboard that displays chapters as index cards. You fill data into the cards using the Inspector. You can use inbuilt utilities to capture the screen and import documents, PDF files, and images into the Research folder. You can open multiple views and watch them vertically or horizontally and build your analysis. File export is a major plus with your Scrivener projects compiling to .docx, .epub, and various e-book formats that work easily. You can work with the available templates and publish your work immediately or set word goals and work toward finishing each component of a report.

If you have had the privilege of visiting malware labs in and around Europe and Middle East, you will observe another tool in vogue—Total Commander (http://www.ghisler.com/). This behemoth of a file manager utility for Windows deserves a mention as it does everything you can possibly expect from working in an environment—packing/unpacking features, persistent multi-file selections, bulk renaming, regex search, inbuilt editors and plugins, and remote FTP connections among others, and the ubiquitous dual pane explorer panes along with a huge set of features make this a pleasure to work with during malware analysis sessions. File organization and management is of paramount priority when dealing with hundreds of samples at a time and Explorer.exe just does not cut it. You must have this tool in your arsenal.