Malware Trivia: Episode 4

If there is something that is always of interest in the AV industry, it is the virus researcher, the white knight that is always on duty and ready to save the day. Most of the times, these guys are seen from the outside as an interesting combination of sorcerer and programming guru, but rest assured, a malware analyst is only one percent sorcerer and 99 percent rocket scientist. This week’s session of question and answers focuses on the steps and tools we take to analyze a piece of malware in order to issue a signature to protect our customers.

Just wanted to know, how do you statically explore malware? What are your methods? Disassembly, decompilation, what? – Question asked by Jeet

Most of the malware we process is dealt with in an automated manner, as the sheer number of variants and families is impossible to be processed "by hand". This is just one case when advanced heuristics and behavior technologies play a key role in offering a better level of protection than the conventional signature filters.

Of course, most of the times, advanced malware analysis calls for the intervention of a human specialist, and one of the biggest challenges is unpacking the piece of malware to expose the offending file(s) inside. In order to do so, we use a combination of public tools such as unarchivers, as well as scripts especially written for unpacking files wrapped with custom algorithms.

The rest of the static analysis process goes by following typical scenarios, depending on what we find inside the packer. Most of the work is done through disassembly and trace for native binary files; sometimes, we manage to decompile binary files (especially those written in .net languages), then follow the resulting code step-by-step, since it is more readable than the disassembler output.

As far as platforms are concerned in static analysis, Windows, Mac or Linux byte-code is handled in a similar manner: a regular disassembler should do the trick for x86 code. For Java-based malware things look a little bit different, as Java analysis requires special tools such as a decompiler for the mentioned platform.

Apart from tools that are openly available for the public (such as TCP/IP packet "sniffers", process monitors, disassemblers and / or decompilers, we also use a wide range of proprietary tools developed in-house, which allow us to analyze malware faster and more effectively. And if you’re wondering why I’m not giving specific names for these publicly-available applications enumerated above, this is because we have an open tool policy which allows any malware researcher to use the tools he or she is most experienced with.

As for preserving the malware samples we analyze, the answer comes as a strong “yes, we do”. Keeping tabs on what we've investigated is a critical step in our operation, and it dramatically helps us deal with false positive claims and even monitor the evolution of a specific family of malware.

All product and company names mentioned herein are for identification purposes only and are the property of, and may be trademarks of, their respective owners.