My approach - as usual - is different from most that you will find and my reasoning is as follows: Analyzing malware usually means identifying what occurred due to an application being run. (Remember, most malware will be some code that has managed to run on a machine). In analyzing what went on, you need to know the prior state of a given machine, and the current state of the machine. AFTER you have these two values, differentiate between the two (pre-machine state and post-machine state), to find what is different after the rogue program/application/code is run.

So I now quote a great MUST HAVE BOOK (at least if you're serious about malware/mwforensics) "Malware Forensics - Investigating and Analyzing Malicious Code" (Ch. 9 for those who have the book and are wondering which chapter this is from)


So how do you do this? From my POV... Configure a virtualized machine to run code on. This machine must be kept away from a live network as to NOT infect any other machines. Once your machine is configured, if using VMWare, take a snapshot, this allows you to revert back and forth.

So you have your clean spiffy new machine. Now you'd want to take a pre analysis of your machine prior to inection. Suggested tools...

Winalysis - after you start your spiffy new machine. Immediately take a snapshot of the machine configuration, then monitors for changes to files, registry, users, groups, rights policies, svcs, etc.

RPIER (MUST MUST MUST HAVE) - too many things to type on this

Nigilant32 (http://www.agileriskmanagement.com/publications_4.html)

PEiD (find out if someone packed or encrypted their crapware)

Mandiant Red Curtain

Wireshark

SysAnalyzer
FakeDNS

Netcat

This is a brief summary of what I would play with as a beginner. Be advised, it pays to have some form of debugging skills at the end of the day. I use WinDBG a lot (yes to you programmers (h1tm0nk3y) I also use ImmunityDBG and Olly but prefer WinDBG ) ... Debugging helps a lot since there will be points in time you will need to understand HOW something occurred, not soley: "Well it crashed IE, then boom!" ... HOW did it crash IE and trigger code execution? Where in mem did it occur and HOW did it do it

For help in the above (debugging), I suggest getting used to debugging by trial, error and reading. I visit DumpAnalysis.org (http://www.dumpanalysis.org/) a lot of obscure things since I found that they have the most information for specifics I look for, particularly heap and stack issues. If you have some money to spend though: MUST HAVE BOOK: Advanced Windows Debugging (http://www.amazon.com/Advanced-Windows-Debugging-Mario-Hewardt/dp/0321374460) its a great read and a book you will always reference.

Anyway this post is long enough for now, holidays are in full season here @ home, so happy holidays all (hannukah, kwanzaa, xmas, whatever one celebrates)