Registry Mining

You're probably asking, "what is Registry mining?" Well, have you heard of "data mining"?This is where companies hire consultants and build huge databases of business data, and then "mine" it for business intelligence, trending information, etc. I'd like to discuss how this sort of thing can be used with the Registry.

One way to look at the Registry is the way Microsoft presents it. You know, that little warning at the beginning of all KB articles that mention the Registry that read something like, "Abandon hope, all ye who enter here." Hey, just kidding! The Registry is a binary database of information about the configuration of a Windows system. The Registry replaces the use of the text-based configuration files that you're familiar with from Windows 3.1. Yes, Virginia, there was a Windows before Windows 95! (As a historicalnote, I have actually seen Windows 3.0 running...seriously!)

In some ways, the Registry can also be considered to be a log file, of sorts. Before you think I've gone off of the deep end, consider this...when certain activity occurs on a Windows system, the Registry will be updated; keys will be added or deleted or simply updated. One way to track those changes is to take successive snapshots of the Registry over time. Since most of us don't do that, another way of tracking changes to the Registry is to get the LastWrite time from Registry keys. This value is similar to the last modification time on files, in that the time indicates when the key was last modified. This information can be retrieved (I haven't *yet* found a public API for setting or modifying this value) and used to correlate other times (ie, file MAC times, times Event Log entries are created, etc.) on your system. I wrote a Perl script called "keytime.pl" that's included in my book, and will retrieve the LastWrite time from keys that you pass to it. Also, the latest version of the First Responder Utility (FRU) includes this capability inherently as part of the functionality.

Now, on to the mining portion of this entry. ;-) The Registry is full of data relating to how the system is configured. For example, the HKLM\System\MountedDevices key
maintains a database of persistent volume names mounted to the NTFS file system. This includes CDs/DVDs, USB-connected storage devices, etc. Whenever a volume is mounted and assigned a drive letter, the assignment is listed in this key. If you want to tie that information to a specific user, check the HKEY_USERS key...specifically, HKEY_USERS\{SID}\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2. You'll find a lot of subkeys beneath this key, in many cases, and the names of those subkeys will be GUIDs (those long strings of characters encapsulated in curly brackets). You'll also find subkeys whose names are standard drive letters (C, D, etc.). There's a subkey named "CPC\Volume", beneath which are subkeys that look like GUIDs. If you open these keys, then right-click on the Data value (choose "Modify Binary Data" to open a dialogue that will let you see the...uh...data) in RegEdit, you'll see information similar to what you saw in the MountedDevices key.

There's more information like this in the Registry, but unfortunately, it's not really catalogued, per se. Part of the reason for this is that there is very little, if any, data or information about the myriad of Registry keys, and how they relate to each other, if at all. Much of this kind of information is maintained in-house, either as proprietary research, or simply because the information is speculative, or not supported by vendor documentation (ooops!).

When digging into some of the aspects of the Registry, I use Google and the Microsoft Advanced Search facility. Other tools I like to use on systems when I'm looking into autostart locations include AutoRuns, SilentRunner, and AutoStart Viewer.

Another tool that looks like it has some promise is Beau Monday's FirstOnScene.

One final note to forensics analysts...

On dead or imaged systems, some of the Registry keys won't be visible. This is due to the fact that some hives/keys are generated at run-time and are volatile. See KB256986, Description of the Windows Registry for more information.