The Windows Incident Response Blog is dedicated to the myriad information surrounding and inherent to the topics of IR and digital analysis of Windows systems. This blog provides information in support of my books; "Windows Forensic Analysis" (1st thru 4th editions), "Windows Registry Forensics",
as well as the book I co-authored with Cory Altheide, "Digital Forensics with Open Source Tools".

Wednesday, November 23, 2011

Stuff

Online Meetups
Usually when I ask online for input into the NoVA Forensics Meetups, I most often get back responses from folks who have not attended the meetups, but want to, and most of those responses are from people who live too far away to attend the meetups...so they ask me when I'm going to start a meetup in their area. I had a chance to speak with Mike Wilkinson (teaches at Champlain College) while we were both out at PFIC 2011, and not long ago, Mike posted a survey to see if folks would be interested in attending or presenting at online meetups. Mike posted the results of the survey recently, and posted a schedule of presentations, as well.

Based on the results, Mike will be running the online meetups on the third Thursday of each month, at 8pm EST, starting on 15 Dec 2011.

NoVA Meetup
While we're on the topic of the meetups, I thought I'd throw out a reminder to everyone about the next NoVA Forensics Meetup on Wed, 7 Dec. I'm looking forward to this one, as Sam Brothers will be presenting on mobile forensics.

Case Notes
Corey posted a narrative version of case notes for an exam he recently worked. Corey does a great job of walking the reader through the process of discovery during the exam, and if you look at what he's doing, you'll see his process pretty clearly, starting with his goal of determining the IIV for the malware infection. He even went so far as to post his investigative plan.

Another aspect of Corey's post that I really liked was this:

Some activities were conducted in parallel to save time.

I can't tell you the number of times I have seen examiners with several systems (a Mac Pro Server and two MacBook Pro systems) do nothing but start a CCN search against the one image they have, using EnCase, and state that they can't do anything else because the image is in use. When you've got multiple systems, you can easily extract designated data from within the image before subjecting it to a long-running process (AV or CCN scans, etc.)...or simply create a second working copy of the image. Or, instead of starting the long-running processes at the beginning of your day, start them when you know you're going to have some down-time, or even before you leave the lab.

As part of his analysis process, Corey did two other really impressive things; he made use of the tools he had available, and he created a timeline. One of the things Corey mentioned in his post was that he created a batch file to run specific RegRipper/rip.exe plugins and extract specific data; this is a great use of available tools - not just RegRipper, but also batch file scripting - to get the job done. Also, Corey walks through portions of the timeline he created, opening it in Excel and highlighting (in yellow or red) specific entries.

I'll leave the rest of the post to the reader...great job, Corey!

Tools
Scalpel was updated a bit ago...if you do any file carving, check it out.

After I posted my macl.pl tool, I received an email regarding wwtool v0.1, a CLI tool for listing available wireless networks, from WiFiMafia. While not specifically a tool for DFIR work, I can easily see how this would be useful for assessment work.

6 comments:

A student in one of my graduate classes suggested something in one of our discussions that is related to Corey's post.

When using EnCase, File Mounter is a taxing time consumer. If you close EnCase, it could take hours to reopen the case. What the student suggested was mount all of the file types you're interested in, but create a Logical Evidence File (LEF) and then add that separately into your case. This is an option with the EnCase V6->present enscript. This will speed things up considerably.

You can then add the L01 into EnCase with your evidence or on a separate machine and not have to wait for the files to mount each time you re-open your case.

Scalpel is great! The only downfall is that I don't think there is a current cut-and-paste list of additional file types to carve for beyond what comes in the .conf file. Someone needs to format EnCase's signature table into scalpel format, as well as the signatures collected by Gary Kessler. Another project to add to the list :-)

using EnCase...they can't do anything else because the image is in use. When you've got multiple systems, you can easily extract designated data from within the image...

Of course, you can use a different tool. For example, I can run 3-4 instances of X-Ways and accomplish different tasks in each against the same image (only one XWF case is writable). I then can carry over my ressults, if relevant, to my primary case. The ability to run multiple instances of a tool is invaluable.

That aside, you may not have to export data from an image to run tasks. Some tools, e.g., HstEx, AVs, Internet Evidence Finder, VMware, etc., can be run against an image or mounted image. In the meantime, you can run lengthy tasks in Encase/FTK. Call it "Image Ergonomics." We can implement our tools and exam approach to best fit the the image.

I use EnCase along with "other tools". RegRipper being one of those tools. I will extract all the data that I need for the other tools to rip through first, and then fire off my heavy processing for EnCase to perform. In parallel, I am then ripping all the other data I extracted earlier. Seems kinda basic to me doing things in parallel. See what happens if you spend too much time in one tool!!