Forensic analysis of "Frozen" hard drive using Deep Freeze

First, I apologize for the delay in updating the blog. It has been two months since my last post, it seems like it has gone by so fast. Since my last post I have essentially circumnavigated the world working on various projects from Bangkok to the US to South America to Malaysia and back to Bangkok.

One of the recent topics that came up that I felt was worth sharing was a forensic analysis of a computer using Deep Freeze. Deep Freeze is a tool produced by Faronics that is used by many organizations to maintain a installation of Windows at a defined state. It is also commonly used by Internet cafes and other public Internet locations to help protect privacy. If you are unfamiliar with it, it basically takes a "snapshot of the hard drive(s) and then lets the user install, create, change or modify the system at will, but then when the system is rebooted, it goes back to its original "state".

Over the past few years I have been approached by several organizations asking about deep freeze and how to do forensics on a machine that has it installed. I have also spoken to several examiners who have said "well, deep freeze is installed so there is no use doing a forensic exam".........FAIL... epic fail.

This review is by no means a comprehensive analysis. It is a summary of my findings and should serve as enough information to get a person started when thinking about examining a computer that has Deep Freeze installed. Deep Freeze uses a kernel level driver, as described here, to redirect the data being written when the drive is being protected to an area that the Deep Freeze program controls. When the computer reboots, any files or data that was created in the previous sessions is gone.... or is it?

Essentially, this program takes a  large chunk of unallocated an uses it to store the data that is created or changed during the session when the drive is "frozen". When the computer is rebooted all the file system records (MFT for NTFS or Allocation table for FAT) that were previously created "disappear".

In reality what this means is that the data is still out there in unallocated. Essentially, the data is in the same state as a newly formatted drive.  The file system tracking system (MFT or FAT) no longer has any knowledge of the data, but its still sitting there in unallocated. Better yet, with NTFS, the MFT record is also out there in unallocated, with all the necessary information to reconstruct any file, even heavily fragmented files.

Even better, Deep Freeze tends to use very high cluster numbers in unallocated. This means that data that is written during the frozen state, ends up near then end of the partition. Recently, when examining a drive using Deep Freeze, a quick search of MFT records in unallocated revealed 40,000+ hits in high cluster numbers.

MFT Record of GIF file that was created several "sessions" earlier.

Data run of MFT record



GIF data is still intact on disk.

Old Internet history can easily be found by searching for Internet history and then check the "comprehensive search" option in EnCase. This will cause EnCase to search unallocated for Internet history records.

Data that is created during the "frozen" state obviously becomes fragile after a reboot since the data is now stored in unallocated like any other type of deleted data. Quick seizure and review is key to recovering the most possible amount of information after the system has been rebooted, but like all data that gets deleted, it depends on the amount of usage after the reboot.

For a really interesting perspective, view a live machine that is running Deep Freeze using a forensic tool that can view the logical device and also the physical device and compare some sectors in unallocated. 

One of the the easiest "recovery" solutions that comes to mind when dealing with a drive utilizing Deep Freeze, would be to use an EnScript (you didn't think you were going to get through this post with me using that word did you??) to parse out all the MFT records in unallocated. Then, get the data runs from the MFT record and piece the files back together. You could even correlate each cluster as you are rebuilding to see if it is currently allocated to indicate if part of the file had been overwritten in certain areas.



Good luck.