Sunday, October 3, 2010

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.

8 comments:

ALEXANDRE Sunday, 03 October, 2010  

Hi Lance,

interesting post. We have been analyzing DeepFreeze for a long time, in fact, we are still in it. Some results were presented in the ENFSI meeting in Moscow last september.

I would'nt extent myself so much, but I would like to add a couple of assertions to help people to analyze Deep Freeze seized computers:

1-. DeepFreeze starts writing always in the same cluster after rebooting computer. These means that in every reboot overwrites information from the last session, so longer sessions means more writings and consequently less older evidence to find.

2-. Cluster address (Data runs) from MFT entries created in the free space by DeepFreeze for every single file, it's not related to the real address of the file header. If you look for the cluster address extracted from the MFT entry of a known file, you'll find that the file doesn't start in that cluster address. DeepFreeze uses some kind of offset or translating table to address correctlly the files to the hard drive (still under study).

Hope my little contribution will help!

Alex.

Lance Mueller Sunday, 03 October, 2010  

Hi Alex,

Thanks for the comments, but I dont necessarily agree with them based on what I have seen.

#1 - this is somewhat true, but when the drive is thawed, it is possible for data to land in an area where it has started before, therefore it will move.

#2 - look in the screenshots I provided in the original post. The one posted definitely points to the correct cluster number.

Thanks,
Lance

Jon Stewart Monday, 04 October, 2010  

So, DeepFreeze keeps track of filesystem metadata by writing MFT records to UC (given NTFS)? Are the MFT records written consecutively?

This is pretty interesting, as the course of action (trolling through UC for filesystem records) really is not specific to DeepFreeze...

Anonymous Monday, 04 October, 2010  

Lance,
This looks and sounds much like Altiris (now owned by Symanted) that would "capture" all changes performed during an install and mantaines that "clean install."... The only real difference would be that Deep Freeze "hides" the captures??

Grayson Lenik Tuesday, 05 October, 2010  

Lance,

I was wondering if you did any timeline analysis on the image? And if you did, could you see daily use info from the file timestamps? This might be helpful if you know a specific person or task was using the machine on a particular day and wanted to have a look at what they were doing.

Grayson

eyeonforensics.blogspot.com

Lance Mueller Tuesday, 05 October, 2010  

Grayson,

Yes, all the timestamps appear as normal, until the machine is rebooted. Then all the changes that occurred during the last active state are reset back to the baseline.

Lance

forensic engineers Tuesday, 02 November, 2010  

very interesting article. appreciate your time. i will have a good look round your site and articles
cheers

George Thursday, 03 February, 2011  

I've done a couple of Deep Freeze analyses, and rather than using an EnScript, have used the HstExt program from Netanalysis. Worked really well in collecting the history records.
- George W. -

Post a Comment

Computer Forensics, Malware Analysis & Digital Investigations

Random Articles