Sunday, March 2, 2008

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:

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.


Anonymous Tuesday, 04 March, 2008  


This topic actually dovetails into an issue I'm having in a corporate environment with Ghost. Based on your post, however, I started looking at sector 62 a little more closely.

My research (using Ghost Suite version 8.2) revealed much more data at Sector 62 - though that may be a result of the switches used during imaging.

At offset 16, there were two text characters -'FD'. Using Ghosts finger utility shows 'File to Disk' as the type. I've also seen 'PD' at this location, and am presuming it may mean 'Partition to Disk', though I have not confirmed yet.

Also, at offset 18 for a length of 4, there is a time encoded string that translates to the date the machine was imaged. In my environment machines are booted just after receiving the image, and the $winnt$.inf file shows as modified approximately three minutes after tis date.

Directly following, at offset 22, appears to be another 4 byte time reference. Though I have not yet confirmed, I believe this to be the date of the image file itself. So, while the first 4 bytes might show that the machine was imaged on 03/01/08, for example, the 4 bytes at offset 22 may show 06/01/07 as the date when the image file itself was created.

I am still looking into any correlations I can find between some other plain text strings noted in this Sector and Ghost. I'll let you know if I find anything.

Jason DeMent

Lance Mueller Tuesday, 04 March, 2008  


Thanks for the info. Any chance you can send me a screenshot of that sector, I can then post it for reference to others.

Normally, sector 62 is completely empty (not taking into account residual data).

Anonymous Thursday, 06 March, 2008  

Thank you for taking the time to dig into this issue. The content you've provided is excellent and will help many others in the forensics realm with their jobs. I'm going to run some tests with Ghost 10 and see how it compares to your findings.

Lance Mueller Thursday, 06 March, 2008  


Feel free to send me anything you find or post them in the comments for others.

Craig Ball Monday, 05 May, 2008  

One way I've found to detect the use of Ghost (or other imaging applications employed as antiforensic tools) is to examine the ENUM/IDE key in the SYSTEM registry hive. Especially when dealing with a laptop drive, seeing two drive keys typically correlates with insertion of a Ghosted drive clone because the Registry from the source gets carried over and then is updated to include the new hardware. Not foolproof, but helpful. Thoughts?

Anonymous Tuesday, 28 October, 2008  

Good words.

Unknown Wednesday, 28 January, 2009  

I had this very problem recently in a case, I used Craig Ball's suggestion and looked at the ENUM\IDE key in the SYSTEM registry hive. In this case it certainly helped as the information I found correlated with that provided by the manufacturer.

I also replaced the hard drive of a laptop and checked the same key and noted that there was only one entry.

Home and dry I thought however a note of caution must be shared. What I found is (sorry if people already know this) the ENUM\IDE key registers any IDE or SATA drive drive directly connected to a system(I did not test SCSI or SAS).

So for desktops that have multiple drives directly connected to the motherboard, this key will not be as useful. What must also be considered are the new laptops with eSATA or combo USB/eSATA ports on them. I checked the key on my laptop which has such a port and I could see 8 entries even though the hard drive has never been changed.

So in short, the suggestion helped in my case but beware of new hardware!


Post a Comment

Computer Forensics, Malware Analysis & Digital Investigations

Random Articles