Interview Excerpt from "Practical Malware Analysis" Author and Mandiant Technical Director Michael Sikorski

Recently, Mandiant's Technical Director, Michael Sikorski was interviewed for [IN]SECURE magazine. In his interview Mike discusses the inspiration for his book, "Practical Malware Analysis," his process for analyzing malware and offers advice for those interested in entering the field of malware analysis.

Following is an excerpt taken from the interview.

How do you approach the process of analyzing a new piece of malware? What tools do you use on a daily basis?

I start my analysis by running the malware through our internal sandbox and seeing what the sandbox outputs. At Mandiant, this happens automatically as we have internally developed two sandboxes over the last couple of years to which our incident responders directly submit malware found in the field.

After that, I spend time using basic static analysis techniques. This includes running tools like Strings, looking at the PE structure, and all the functionality the malware imports. This part of the analysis provides leads for the more in-depth analysis I perform.

After basic static analysis, I perform basic dynamic analysis. This includes running the malware in a safe environment, like a virtual machine. I use tools such as FakeNet, Procmon, and Process Explorer to see what impact the malware has on a system.

Next, I use the results from the basic analysis to help kick start and drive my analysis of the next phase - full disassembly. This is where the real software reverse engineering begins. I turn the binary data into assembly code I can read by a process called disassembling. The best and most popular tool for this is IDA Pro. IDA Pro allows me to browse around the code while annotating and keeping track of the in-depth analysis I perform at this level. If needed, I can use debuggers like WinDbg and OllyDbg to unpack malware or watch the malware as it runs at the code level live on a system.

In this phase you might have to fight against attackers trying to derail your analysis by using obfuscation, anti-debugging or anti-disassembly techniques. This often slows down the reverse engineering process. At the end of the day, the code must run and do bad stuff so we always figure it out sooner or later.

Be sure to download the latest issue of [IN]SECURE magazine at to read the full interview.