Archive for June, 2010

EnCase + RegRipper + dtSearch + … for incident response

June 6, 2010 5 comments

So there I was, working an IR case …. The forensics version of “It was a dark and stormy night.” For all the typical reasons, I cannot share the details, but I can share some “what worked” tips that may be helpful to others. Please bear in mind that these are just small pieces of a much larger IR response plan, toolkit, and process.

1) Keep a running log of everything you do. This is SOP for forensics, IR, etc for well known reasons. One additional reason that isn’t often mentioned is that it serves as a governor on your pace. If you’re taking the time to collect your thoughts into a log, more of your thoughts have a chance to catch up with you, make it onto the page, and join in building the overall picture of the event. Without this governor, a lot of information is never documented, possible leads aren’t explored, and you will feel less like you’re in control of your response.

2) Dump the registry hives as early as you reasonably can and set up a process for running them through RegRipper. I used a combination of tools to simplify this:

  • A batch file to create the default folder structure.
  • An EnScript to locate and extract all the registry hives
  • A Python script to walk through all the files in a given directory, run the appropriate RegRipper plug in on it, and write the output to a dedicated output directory.

This combination of tools allowed me to quickly process a system in a repeatable fashion while minimizing the chances of human error creeping in.

3) With all the RegRipper output organized by system, I pointed dtSearch at the folder containing all the output and indexed it. This allowed me to quickly search the RegRipper output from all of the systems for new information came in.

4) malware often stomps on the MAC times but may leave the information in the File Name attributes alone. There are a lot of ways of getting at this information, but I dumped the $MFT out, ran my analyzeMFT tool against it, and created a spreadsheet I could use to do further analysis. This is a very rough form of timeline analysis but, no matter how you do it, timelines are crucial and should be developed. Further, they should be developed with the most accurate data possible.

5) If you’ve got malware and don’t know anything about how it behaves, I suggest you take a look at Lenny Zeltser’s site and in particular¬† at his material on reverse engineering malware. He teaches a superb SANS course on the topic, but he also has a one hour video and a PDF of his slides on the site that will really help you get started.

As I said, this is hardly a definitive list of what to do when working an IR case, but it might give you some ideas to include in your response toolkit.

Categories: incident response