Daily Blog #260: Sunday Funday 3/9/14 Winner!

Sunday Funday by David Cowen - Hacking Exposed Computer Forensics Blog

Hello Reader,
Another week another challenge answered. I'm hoping I can get Mark Spencer from Arsenal to expound on his version of an answer but Kyle Rhodes put a good answer this week explaining the structures used to recover deleted registry hives from freespace. Enjoy this week's answer I look forward to hitting 100 blog posts left to write in two posts.

The Challenge:

The idea of recovering deleted registry entries from within a registry is well known and implemented well in Harlan's perl scripts and yara. To show you understanding of what Mark Spencer and his team discovered answer the following questions:

1. How is it possible that registry recon can recover deleted registry entries from unallocated space
2. Where do these recoverable registries come from?
3. What additional analysis points can you determine from these recoverable keys?

The Winning Answer
Kyle Rhodes
1. How is it possible that registry recon can recover deleted registry entries from unallocated space? 

Like any other file we might want to carve out of unallocated space, registry hives contain a standard header which marks the beginning of the file. The header is ‘regf’ or 0x66676572 in hex. By simply searching unallocated space for this string of binary characters, a program like Registry Recon can identify a potentially recoverable registry hive. 

However, the recovery work doesn't stop there. Any time we find remnants of a previously existing file in unallocated space, it is possible that any part or all of the registry hive has been overwritten by other data. Further, how do we know where the end of the registry hive is on the disk? Fortunately, the structure of registry hives is helpful in that regard.

As described in Harlan Carvey's book, Windows Registry Forensics, after the ‘regf’ header in a registry hive, every 4KB is a self-contained bin of data marked off by the 4 byte binary representation of the string ‘hbin’. This means, as long as you continue to jump forward 4KB increments on the disk and find ‘hbin’, there is a high likelihood that you are looking at an intact, contiguous, registry hive. Once a 4KB offset contains something other than ‘hbin’, stop and carve out what you found. Somewhere after the last ‘hbin’, you either reached the end of the registry hive, it's been overwritten by other data, or the entire registry hive did not live in contiguous clusters on the disk.

2. Where do these recoverable registries come from?

Recoverable registries can be found in unallocated space due to hives that have been deleted in some fashion whether manually, via formatting a drive and reinstalling the OS, by anti-forensics programs, or by the OS when it is making and committing changes to the registry. They can also be found in restore points, volume shadow copies, pagefile.sys, and hyberfil.sys in unallocated or allocated space. Finally, if they are in the pagefile.sys and hyberfil.sys, they can obviously be found in memory as well.

3. What additional analysis points can you determine from these recoverable keys?

Being able to recover all of this additional data is great for us information junkies, but the fun comes when we can use it to solve our cases. Here are some ways I thought this information could be helpful, in no particular order:

                1. See which USB devices were associated with the same drive letters over time
                2. Get more than the last 20 entries from the OpenSaveMRU key
                3. Use historical registry key last write times to determine when entries were added to various MRU lists
                4. Find registry keys that were wiped
                5. Determine whether Windows has been installed multiple times
                6. Compare historical registry data over time to see anomalies created by anti-forensics tools
                7. Determine if a forensic analyst had the USB write protection turned on when imaging evidence in the past (you can never be too careful)

If you can think of any other ways historical registry data would be helpful, please tell me below in the comments!


Also Read: Daily Blog #259

Post a Comment