ThinkTank Forensics

Volume shadow copies in Vista are often the elephant sat in the corner in many cases. We know they exist and we know they can contain lots of data, but we often choose to ignore them.

A recent case required some keyword searches and an examination of picture files. A the completion of the keyword search most of the hits were within files with names similar to

{bab9c293-d150-12dc-a44f-021d253da909}{3708876a-d176-4f38-b7bb-05036c6bb821}

The view pane within Encase 6.14 displayed the contents in a nice light blue colour which I now know is a new feature in 6.14 to indicate the contents of uninitialised files. The files were all located within the System Volume Information folder on the root of the volume and are the Vista Volume Shadow Copies. By default 15% of the capacity of the volume is allocated by Vista to store these copies. The C4P graphics extractor enscript carved most of the notable pictures out shadow copies also.

At this stage I have known examiners report their findings alluding to the fact that that the notable artefacts are within the file {bab9c293-d150-12dc-a44f-021d253da909}{3708876a-d176-4f38-b7bb-05036c6bb821}. In most cases I think you need to drill down further. In order to do this I mounted my Vista image with Encase PDE and used Liveview 0.7b to create a working VM using VMWare Workstation 6. Having logged into my suspects account I ran a command prompt as administrator and entered the command

vssadmin list shadows /for=c:

This provided a nice list of available shadow copies. Having selected one I entered the command

mklink /d c:shadow_copy7 \?GLOBALROOTDeviceHarddiskVolumeShadowCopy7

This created a symbolic link in the root of C which in Windows Explorer at any rate appears exactly like a shortcut to a folder. Clicking on it produced the error message shown below

I believe this error is probably generated by a permissions issue, however I was not able to overcome it and Rob Lee over at Sans Computer Forensics suggests this methodology does not work. I think Jimmy Weg however has had some success with a program written by Dan Mares - VSS.exe. I therefore turned to ShadowExplorer version 0.4.382.0. This program allows the user to view the contents of Volume Shadow Copies that exist on any volumes within the installed system. The contents are displayed in an Explorer like view allowing the user to export out any file or folder to an export directory. I exported the User profile I was interested in to an export directory. Unfortunately it seems that only the Last Written date is preserved in this process and all other time stamps are tripped. I then tried to copy this export directory out of the VM to my workstation and encountered errors (probably due to files within the profile with illegal windows file names). To overcome this I zipped up the export directory and copied the zip out of the VM. Once unpacked I then added the exported folders into Encase as single files and created logical evidence files from them.

Having done this I was able to resolve most of my keyword search hits and pictures to actual files as opposed to being simply within a volume shadow copy.

References
http://blogs.msdn.com/adioltean/archive/2008/02/28/a-simple-way-to-access-shadow-copies-in-vista.aspx
http://sansforensics.wordpress.com/2008/10/10/shadow-forensics/

Probably not an entirely accurate title but I came across two enscripts the other day both of which are aimed at quickly triaging the results of a comprehensive Internet History search. Users of this functionality within Encase version 6 will know that often you can be faced with reviewing hundreds of thousands of entries on the records tab. Many times all you need is evidence of user inputted search terms. There are conditions available to start sorting the wheat from the chaff however it is difficult for these conditions to be totally focussed due to the variation in url formation. This is where both enscripts come in as they are both designed to parse the actual search term used from a variety of search engine urls.

Searchterms V 1.1 parses out the search term used and where possible the time and date it was carried out into note bookmarks. The enscript has been written to support a claimed 145 separate search engines.

Internet Search Term Finder parses out unique search terms to Log Record bookmarks and stores the term along with its associated url. The script is in fact an Enpack so it is difficult to determine exactly how it works, however it seems to base its search on elements from the query url. A neat feature is that it is configurable, allowing the addition of a new prefix (to the query string) to cater for a different or new search engine.

Within an XP Pro SP3 VM I carried out a series of searches utilising the Firefox v3.0.11, Internet Explorer v8, Opera v9.64 and Safari v4.0.2 browsers. I ran the Search for internet history Comprehensive search option within Encase 6.14 and established that all my searches had been parsed into the records tab, with the exception of those carried out with Safari v4.0.2. It turns out that Encase 6.14 does not support parsing internet history from this version of Safari.

I then ran both Enscripts and can report that both parsed out my test search terms from the records tab. The results can be viewed within bookmarks. For me the output of the Internet Search Term Finder is preferable and it usefully creates a Log Records bookmark which allows the easy export of results into a spreadsheet. Both successfully hit the spot in respect to users quickly reviewing search terms within internet history.

A recent case involved the download of a contraband file and I was asked to establish what happened just before the download in order to try and establish who was responsible. This scenario is fairly commonplace and I usually start with a timeline analysis of the file system activity around the event in question. An invaluable enscript for this is Geoff Black's Timeline Report which can also be found within the Guidance Software Enscript Resource center. The html report produced by this script is particularly cool.

In my case my analysis showed there were a number of link files in a number of system restore points all created at a time and date just before the download. They were all named in the form A000XXXX.lnk (xxxx being a variable number) and I could see from a rough and ready examination of the data that they all pointed to one particular file saved on the users desktop. As these link files were stored within restore points the first hurdle to overcome was to establish the link files original name and path. This information is stored within the changelog files of each respective restore point. Manually searching through this file for the restore point file name (e.g. A000XXXX.lnk) will reveal the files original path. There used to be an enscript for parsing the changelog files but it was written for version 5, however I was able to track down a version that worked in version 6 at Paul Bobby's excellent blog/web site (this enscript can also be found within the Guidance Software Enscript Resource Center). The changelog files contain a lot of information and all I really needed was the original filename and path - the scripts output may be a little bit of an overkill*. Another utility out there is the Mandiant Restore Point Analyzer. I used this utility to determine the original paths and file names.

All of the link files related to one link file stored within a users Recent folder. In my case the file the link file linked to was created and stored upon the desktop, thus causing the initial link file to be created. Over a period the target file was opened and additional information written into it, thus causing the link file to be updated. Harry Parsonage's paper on link files illuminates this further.

I copied the link files out of my image and loaded them into Sanderson Forensics Linkalyzer. This program decodes and displays the contents of link files into a grid much like a spreadsheet ( I was going to post a screenshot but sanitising the contents became too much of a pain) and very quickly allowed me to see that the target file was being regularly accessed and modified. Because the target file size is also stored within the link file I could also see that the file size was growing over time. The program produces good reports and has many other abilities beyond the scope of this blog post, but in short I thoroughly recommend it.

Now as far as my case was concerned the target file was clearly linked to the suspect and it proved worthwhile delving into those restore point link files.

References
http://computerforensics.parsonage.co.uk/downloads/TheMeaningofLIFE.pdf
Forensic Analysis of System Restore Points in Microsoft Windows XP

*Now what would be really useful is an enscript that simply parsed out the original path and filename of only all user selected (blue checked) files sitting in restore points. I would envisage the output to be a three column csv file - Current Filename, Original Path and Filename, Restore Point Creation Date.

Paul Sanderson's VidReport has been referred to here and there lately. C4M also is regularly brought up in conversations I have with people (such an interesting life I lead). Triage is certainly the flavour of the month right now. So I thought it worth writing a few lines about my recent experiences of triaging videos.

I have often voiced the opinion that reviewing a couple of hundred video files in a case is not that bigger a deal and on that basis I have not been too keen on using C4M. Anyhow I've just had a case with about 170 video clips to review and thought it would be a good case to try out the video triage approach. My normal approach is to use VLC as a file viewer in Encase to preview each video. This took about an hour and a half (some of the videos were quite good ;-) ).

I then used John Douglas's video triage program (which I think he supplies free to LE) to review the same video clips. To use this program you copy out the clips you wish to review and point the program at the folder containing them. It processes each clip by taking a screen capture at a configurable interval and putting each screen capture into a subfolder named after the videos file name. Once the program has processed all the clips you will have a sub folder for each one, containing the screen captures. I then simply dragged the folders into Encase as single files and previewed the contents of each folder in gallery view. I previewed all the clips in fifteen minutes. My scepticism of video triage was clearly unfounded.