Deleted Keys in the Registry

Have you ever thought, what happens when keys are deleted from the Registry? Yeah, me, too. Where do they go? Well, as it turns out, they appear to hang around, in Registry hive file "unallocated space".

A bit ago, Jolanta Thomassen asked me to help with ideas (and be her sponsor) for her master's thesis, and I threw out Registry "slack" or unallocated space recovery...which she picked up and started running with right away. So far, she's done a great job of locating "deleted" Registry cells, the most interesting (to forensic examiners) of which are cells representing Registry keys, as keys have pointers to their parent keys (so that you can reassemble the full path of the key), timestamps (aka, LastWrite time), as well as pointers to their values. All of these maybe useful to a forensic examiner.

Not only that, but she's writing her code in Perl! This makes it easy for me to understand, add print() statements to (ie, "poor man's debugger"), and modify. For example, I've borrowed her search code, and added in my own code for parsing the key cells, etc., so that I can better see and understand what's going on. In some ways, it's not too different from looking for processes in a memory dump using a brute force approach...you read in values, and make decisions about the type of cell you've found based on those values.

Okay, so I've focused on Registry keys, as I tend to think that they are the most useful to a forensic analyst, for the reasons stated above. By themselves, Registry values found in hive file "unallocated" space may not be entirely useful...without any time-based information, or anything else to reference to (ie, like a key), they're about as useful as finding some text in the pagefile or file slack.

Addendum: Got some code working (finally!) to track backwards through the hive file once a "deleted" key has been found, and attempts to reassemble the full path name of the key. Jolanta already has this working, but I wanted to give it a shot. Below is an excerpt from my code outupt (still with debug info showing):

0x0008e474 456
Software\Microsoft\Windows\CurrentVersion\Explorer
\MountPoints2\{2490fb13-f08b-11d8-958e-806d6172696f}\
Shell
LastWrite = Mon Sep 26 23:37:22 2005
Subkeys = 0
Values = 1
Ofs_LF = 0xffffffff

0x0008e4e4 344
Software\Microsoft\Windows\CurrentVersion\Explorer\
MountPoints2\{2490fb13-f08b-11d8-958e-806d6172696f}\
Shell\AutoRun
LastWrite = Mon Sep 26 23:37:22 2005
Subkeys = 0
Values = 1
Ofs_LF = 0xffffffff

0x0008e32c 784
Software\Microsoft\Windows\CurrentVersion\Explorer\
CD Burning\Current Media
LastWrite = Mon Sep 26 23:34:10 2005
Subkeys = 0
Values = 6
Ofs_LF = 0xffffffff

Notice with the first two keys above, the second is a subkey of the first, yet actual data from the first key's structure states that there are no subkeys available. Interestingly, names, LastWrite times and links to values are retained when a key is deleted, but links to subkeys are not.

Another interesting artifact retained in deleted Registry keys can be seen in the output of one of the code samples Jolanta sent me:

$$$PROTO.HIV\Software\Microsoft\Windows\CurrentVersion\
Explorer\CD Burning\Current Media
Last modified: Mon Sep 26 23:34:10 2005
-->REG_BINARY; TotalBytes; 00 88 10 00 00 00 00 00;
-->REG_BINARY; FreeBytes; 00 00 00 00 00 00 00 00;
-->REG_DWORD; Media Type; 2;
-->REG_DWORD; UDF; 1;
-->REG_SZ; Disc Label; PDServer25;
-->REG_DWORD; Set; 1;

Interesting...it looks as if on 26 Sept 2005, someone burned a CD with the label "PDServer25". This demonstrates some pretty interesting potential for time-based information that may be useful to a forensic examiner.