Every file system handles MAC times slightly differently, however sleuthkit (as well as other forensics software products) use the same acronym/fields no matter which file system you’re analyzing. Here’s a quick run-down of some popular file systems and what the M, A, C, and B mean:

Harlan Carvey recently wrote a post on his blog called Accessing Volume Shadow Copies, which provided some excellent instruction on how you can go about accessing Volume Shadow Copies (VSCs) from an existing image without having to use expensive tools (in fact, his solution uses completely free tools). In Windows 7 and Vista, VSS is turned on by default and thus additional artifacts are possibly just waiting to be discovered. Accessing a system’s VSC(s) can be highly useful in an investigation and can possibly help you get your hands on older copies of registry hives (i.e. being able to get historical UserAssist data, etc) as well as other older file snapshots (pictures, etc), which can come in very handy. So, needless to say, if you’re not presently looking for VSCs as part of your forensics workflow, you probably should be…

In the process of testing Harlan’s procedure, I started to wonder how Windows, by default, decides to generate these VSCs (and what is included). I came up with some data and I thought that I’d go ahead and post my findings (feel free to comment if I’ve gotten anything wrong here):

A scheduled task (named SR in Win7) controls when a snapshot occurs. By default, the task is set to run at 12:00AM every day and 30 minutes after every system startup, but will only execute when the system is plugged in and has been idle for 10 minutes. If the system is not idle, the task will continue to wait for idle for 23 hours.

If a restore point/snapshot has not been successfully created in the last seven days, system protection will create one automatically.

And finally, a restore point may be created “automagically” as part of certain software installation/driver installation processes.

The bottom line: it is basically impossible to predict with any degree of certainty when a snapshot will occur.

All files/folders are covered in a volume snapshot, except for those defined under the HKLM\System\CurrentControlSet\Control\Backup Restore\FilesNotToSnapshot registry key.

If a file is modified several times between snapshots, only the version that was current when the restore point/VSC was made will be available to you for analysis. Mind you, there may be multiple VSCs available, so that can be helpful with getting further historical revisions.

I’ve used searching in my previous PowerShell posts, but I thought that it deserves a dedicated “Quick Tip” posting. I know that folks coming from a *nix background will be very familiar with using grep to search for pretty much anything and seemingly not having access to this tool can be disappointing for those trying to use Windows as their primary OS (for the one or two of you out there that have decided to come to the “dark side” 😎 ). But…do not fret! There are a number of ways to run equivalent searches within Windows out of the box. Since I’ve been on a PowerShell kick lately, let me introduce you to a decent grep alternative that is built into PowerShell: select-string.

Select-String is a built-in cmdlet in PowerShell that will allow you to search files, piped input, objects, etc for a pattern (which is, by default, a regular expression). Select-String can take in a number of options, but can be quite simple to use. For example, if you want to search for the text “evildoer” within all files in the current directory, you can use the following command:

select-string .\*.* -pattern "evildoer"

It is important to note that by default, select-string is case-insensitive; so, if you need a case sensitive search, add in the -CaseSensitive parameter.

Ok, now let’s do something a bit more complex. I want to look for anything that looks like an email address in all txt files recursively under C:\. So, to make that happen we need to do a little more work:

First, I need to use get-childitem (think DIR) to recursively go through the drive and return only files matching *.txt. Then I pipe these returned objects to select-string and search their contents by using a basic regex that will match on things that look like email addresses.

Of course, there are a number of other ways to use select-string but since this is a “quick tip” I’ll keep things brief. If you’d like more details, you can find additional information in the PowerShell documentation on TechNet.

So – you’re working on creating a timeline for a new disk image and you’re finding that the subject accessed a large number of unrelated files in quick succession. Perhaps they were up to no good, but before utilizing this evidence to support any findings, let’s step back and think. When analyzing a timeline, if you find a number of files that were accessed in quick succession, you should immediately consider that some sort of program/process actually accessed the files and that they were probably not intentionally accessed by the subject. The usual suspects can include backup software, antivirus software, and any other software/malware that “scans” a filesystem. Of course, once you find the presence of one of these tools, you’re going to need to note it in your findings and if you would like to use accessed times in the timeline to build a case, you’re going to need to prove that the timeline was not affected by this tool. Some strategies to proving that your access times are relevant include:

Analyzing and including the AV scan log (if available on your image) that shows that an “on-demand” scan was not running during the time in question.

Analyzing and including a backup log (if available) that shows a backup was not running during the time in question.

Performing and documenting searches for other automated tasks/processes that may affect the accessed time in the timeline.

It’s interesting to note that most likely due to the proliferation of “scanning tools” and thus the reduction of relevance that an access time can have in an investigation, Microsoft has decided that by default, in Windows Vista and Windows 7, that the OS does not modify the last accessed time when a file is accessed (this behavior can be modified via GPO and/or the local registry).

My personal reccomendation is that unless you have a very specific reason to use the access time to support your findings, given the active use of tools that automatically access/scan files, you may find that your results are more clear and less challengable if you do not base investigative findings on this timestamp.