Links and what not

Case Notes
Chris posted on writing and maintaining case notes a bit ago, using Case Notes. One of the things that is sorely overlooked many times is note taking and documenting what you're doing during an examination.

This is perhaps one of the most overlooked aspects of what we (IR/DF folks) do...or perhaps more appropriately, need to be doing. Many times, so little of what we do is documented, and it needs to be, for a number of reasons. One that's mentioned many times is, how are you going to remember the details of what you did 6 months later? Which tool version did you use? Not to pick on EnCase, but have you been to the user forum? Spend a little time there and you'll see why the version of the tool makes a difference.

Another aspect that few really talk about is process improvement...how do you improve upon something if you're not documenting it? As forensics nerds, we really don't think about it too much, but there are a lot of folks out there who have processes and procedures...EMTs, for example. Let's say you're helping someone with some analysis, and you've worked out an analysis plan with them. Now, let's say that they didn't follow it...they told you that...but they can't remember what it was they did do. How do you validate the results? How can you tell that what they did was correct or sufficient?

A good example is when a customer suspects that they have malware on a system, and all you have to work with is an acquired image. How do you go about finding "the bad stuff"? Well, one way is to mount the image read-only and scan it with AV. Oh, but wait...did you check to see which AV, if any, was already installed on the system? Might not be a good idea to run that, because apparently it didn't work in the first place. So what do/did you run? Which version? When was it updated? What else did you do? You will not ever reach 100% certainty, but with a documented process you can get close.

When you document what you do, one of the side effects is that you can improve upon that process. Hey, two months ago, here's what I did...that was the last time that I had a malware case. Okay, great...what've I learned...or better yet, what have other folks learned since then, and how can we improve this process? Another nice side effect is that if you document what you did, the report (another part of documentation that we all hate...) almost writes itself.

In short, if you didn't document what you did...it didn't happen.

Raw2vmdk
Raw2vmdk is a Java-based, platform independent tool for mounting raw images as VMWare vmdk disks. This is similar to LiveView, and in fact, raw2vmdk reportedly uses some of the same Java classes as LiveView. However, raw2vmdk is a command line tool; thanks for JD for taking the time to try it out and describe it in a blog post.

MFT $FILE_NAME Attributes
Eric posted to the Fistful of Dongles blog, asking about tools that can be used to extract/retrieve $FILE_NAME attributes from the MFT. I mentioned two tools in my comment that have been around and available for some time, and another commenter mentioned the use of EnScripts.

Tool Updates
Autoruns was updated on 15 June; perhaps the most notable update is the -z switch, which specifies an offline Windows system to scan. I really like Autoruns (and it's CLI companion, autorunsc.exe), as it does a great job of going through and collecting information about entries in startup locations, particularly the Registry. The drawback of the tool is that there isn't much of an explanation as to why some areas are queried, leaving it up to the investigator to figure it out. This is pretty unfortunate, given the amount of expertise that goes into developing and maintaining a valuable tool like this, and usually means that a great deal of the information that the tool collects is simply overlooked.

If you're interested in USB device histories on your system, check out usbhistory.exe. The web page provides a very good explanation of how the tool works and were it goes to get it's information. Overall, if this is information that you're interested in, this would be a very good tool to add to a batch file that collects information from a live system.

USB Devices
Speaking of USB device history, there's a topic I keep seeing time and time again in the lists that has to do with when a USB device had last been connected to a system. In almost all cases, the question that is posed indicates that there has been some issue determining when devices had been attached, as the subkeys beneath the Enum\USBStor key all have the same LastWrite times.

While there is clearly some process that is modifying these subkeys so that the LastWrite times are updated, these are not the keys we're interested in when it comes to determining when the devices were last attached to the system. I addressed this in WFA 2/e, starting on pg 209, and Rob Lee has covered it in his guides for profiling USB devices on various versions of Windows.