More Links, Updates

Meetup
Our 6 July NoVA Forensic Meetup went very well, and I wanted to thank Tom Harper for putting in the time and effort that it takes to provide his presentation, and to also thank the ReverseSpace folks for hosting our meetings!  This time, we had about 20 or so folks show up...some new...and I wanted to thank everyone who took the time out to come by and take part in our event.

What I liked about Tom's presentation was the fact that Tom's a practitioner, and he approaches solutions from that perspective.  Tom was at OSDFC, and after the conference mentioned that some of the presentations we saw that day were from folks from the academic side of DFIR, and not so much the practitioner side.  I agree with that sentiment...and Tom's approach is practical and all about gettin' the job done.

I should also note that the ReverseSpace location doesn't say "ReverseSpace" on the outside, nor is there a sign by the road.  The address is 13505 Dulles Technology Drive, Suite 3, in Herndon, VA, and the facility says "Cortona Academy" on the outside.  Don't worry about writing this address down...simply check out the "NoVA Forensics Meetup" page associated with this blog.

Our next meetup is scheduled for 3 August (same time, 7-8:30pm) and we're looking for presentation or discussion ideas, as well as presenters.  @sampenaiii suggested via Twitter that we have a discussion on LulzSec and the impact of their activities on security and forensics; this sounds like a great idea, and I think that we'll need to have a slide or two with some background for those who may not be familiar with what happened. 

Cory-TV
Cory Altheide recently provided a link to the video of a presentation he gave in Italy on 2 May 2011.  The presentation is titled, "The death of computer forensics: digital forensics after the singularity", and is very interesting to watch.  Cory is a very smart guy, and as Chris Pogue recently tweeted, Cory is the bacon of the DFIR community, because he makes everything better!

Cory presents some very interesting thoughts regarding what were once thought to be "forensics killers", and the future of digital forensic analysis. One of the things that Cory mentioned was the existence of metadata, which is not often removed, simply because the user doesn't know about it.  There have been some pretty interesting instances where metadata has played a very important role (here, and here), and I agree with Cory that it will continue to do so, particular due to the fact that we have new formats, devices, and applications coming out all the time.

Clearly, Cory talked about much more than just metadata in his presentation, and I simply can't do justice to it through any sort of concise description.  Instead, I highly recommend that you take the hour+ to sit down and watch it.  I think that the overall point that Cory makes is that as available drive space increased (every time it did) and decreased in price, and as platforms to be analyzed have become more complex and varied, there have been those who've claimed that these things would be the "death of digital forensics"; instead, analysts have adapted. 

MBR Analysis
Speaking of Chris Pogue, he recently posted to his blog regarding MBR Analysis, referring to a discussion he and I had had not long ago.  What I like about Chris's post is that he's talking about it, and by him doing so, my hope is that the things we talked about reach more analysts.  Chris is the author of the Sniper Forensics presentations (here's the one he gave at DefCon18), and he's been getting a lot of mileage from the series, and presents to a lot of people.  As such, my hope is that more people will hear about MBR analysis, how it can be used, and start looking at this as a viable part of a malware detection process/checklist.

When you read the post, don't get caught up in the terminology...what I mean by that is, to clarify a couple of things, the TSK mmls reads the partition table within an image of a physical disk (you don't have one of these if you acquire a logical image of the C:\ volume, for example), and provides you the offsets to the partitions.  The offset to the active partition is often 63 sectors (indexed at 0), not "0x63".

Speaking of the Sniper Forensics presentations, Chris also has another post up on the SpiderLabs Anterior blog that's worth a read.

Additional Thoughts
I recently posted some thoughts regarding how the structure that data is stored in (as well as where within that structure) can provide context to the data that you're looking at, and an email exchange with James, who commented on that post, led to some thoughts regarding timelines.

James (I hope you don't mind me pointing this out...) in a comment that log2timeline doesn't provide enough context.  I was curious about this, and in the ensuing email exchange, at least part of what James was referring to was things like, if an image file was created on the system, provide a link to that file, that would then be opened in a viewer.  In this way, the analyst would have access to additional context.

I thought that this was an interesting idea...and I still do.  Having my own process for creating timelines (taking nothing away from Kristinn's efforts with log2timeline, of course) I thought about how you could implement something like this...and got stuck.  Here's why...let's say that you completely restructured timeline creation and had the timeline itself available with either the image itself mounted as a volume, or files extracted from the image...would you provide links to all files that were created on the system?  I'm thinking not.  Also, if a file is modified, what do you link to?  What value or context is there if you don't know what was modified in the file?  The same would be true for Registry keys.

However, I do think that there are some benefits to this idea, but it really depends upon how you implement it.  For example, let's say that you found some time stamped data in the pagefile or in unallocated space, and wanted to include it in your timeline.  You could do that, and then include a link to the data...but not to the offset within the image; instead, extract the data (plus 100+ bytes on either side of the data) into a separate file, and provide a link to that file.  The same might be true for other files...for example, if your timeline analysis leads you to determine that the infection vector was spear phishing via a PDF file, rather than copying the PDF file out of the image and linking to it, maybe what you could do is copy the PDF file out of image, and parse the offending portions of that file out, emasculate them (i.e., extract them to a text format, etc.), and then link to that.  You might extract images, and link to those...it all depends on how you want to present the data.  But my point is, this may not be something that you would want to completely automate; instead, use the timeline to perform your analysis, and once you've isolated the appropriate entries in your timeline, provide links to relevant data (either the file, a portion of a file, or to your analysis of the file) in order to add context and value to your timeline.