Ghost - Part Deux - How to detect its use

I decided to keep going a little farther with my research and see what I could come up with to detect ghost was used either in the past or to make an image that was being provided to an examiner. Plus, I had already shot half my weekend, so why not finish the whole thing off!

The first thing I will mention is the "fingerprint" that ghost can leave behind. A reader left a comment asking about using "-FNF" command line switch when making an image so that the ghost application does not mark the hard drive(s). I did not use the "-FNF" switch at any time when I made any of my images and as long as I used the "-IR" switch, an exact duplicate was made of the source disk each time and ghost did not modify the original hard drive. BUT, I was asked at the time ghost started up if I wanted to mark the hard drives with the following screen:



I answered "Continue without marking drives".

A hash baseline was taken of the source drive before ghost was ever used and the before and after hashes of the source remained constant regardless if I used the "-FNF" command line switch or not. When I did specify the "-FNF" switch, I was still prompted with the screen above. As long as I answered "Continue without marking drives" The original remained untouched.

By answering "OK" to the screen above, ghost DOES MARK ALL DRIVES it detects! Now obviously the source drive would most likely be connected via some type of write-blocking device so ghost would not be able to write this change to the source, but it may mark other drives connected to your system that you don’t want marked. If you do answer "OK" a "fingerprint" is placed one sector prior to the volume boot sector, typically at physical sector 62:



Once marked, ghost will stop asking the question at startup if you would like to mark the drives. I have not yet deciphered the “fingerprint” data written to this sector yet, but it appears the first dozen or so bytes remained constant between different markings, but the rest of the data changed each time I marked the drive, indicating some type of possible date stamp. When creating the image using the "-IR" command line option, if the source drive is marked, then the destination image will be marked as well.

The second part of my testing involved looking at how ghost copied files from one drive to a destination drive, either directly or through a ghost image file. If ghost was used with the "-IR" command line switch then ghost leaves everything in the same place as the original. My main focus was inspecting the changes with the default option of ghosting a source drive and then restoring it out to another drive like a typical user or IT professional would do. When I created a ghost image of a source drive and then restored that image, all the internal file system creation dates remained unchanged from the source's timestamps.



Looking at the screenshot above you can see the timestamps of the internal file system objects from the original drive have carried over to the ghost copy. This was true if I made a disk to disk image or a partition to partition image.

The only obvious artifact that ghost was used is the file extents field. The file extents field indicates how the file is fragmented. You can see in the original that the "Unallocated Clusters" object represents all of the unallocated clusters across the logical volume. In the source, there are 700+ "patches" of unallocated sprinkled around the drive. In the new ghost image, there are only three. The first is a small area consisting of 16 sectors immediately following the $AttrDef internal file. Then there is a large gap immediately following the $MFT, which is considered the "MFT zone" and is usually about 12.5% of the volume size. This area is reserved for use by the MFT as it grows. Immediately after the MFT zone are all the other remaining files on the volume, with no unallocated gaps in between them. Not all files are contiguous on the ghost image, but there are no files with unallocated before or after, except the ones I mentioned. The following screenshot is of the original source drive showing obvious signs of fragmentation:



Here is another contrasting example by viewing the file extents of the Unallocated Clusters object:



The newly ghosted drive only has the three aforementioned areas of unallocated space. There are still files present on the newly created ghost image that have multiple file extents (fragmented), but there are far fewer than on the source drive. This screenshot is of the drive that received the ghost image:



Summary:
Although there are a few indicators such as the presence of the "fingerprint" that indicated ghost has "marked" that drive at some point in the past, there is no surefire way to detect the use of ghost with certainty. As indicated above, the lack of unallocated area being fragmented around the drive would certainly be suspicious, but as the system gets used after a ghost image was restored, the system will begin to fragment like before, and so it will depend on the timing of the seizure. I would certainly look at the timestamps on the internal file system files, coupled with the date in the registry as to when the OS was installed to give me an idea of how long that file system and OS have been operating and then compare that with the absence of file fragmentation to help support the idea ghost was used.

Video demonstratinig adding an uncompressed ghost image file (.gho) into EnCase and then manually adding the VBR to have EnCase parse the volume then you can image like any other device.