Review date: 15 February 2013
For those familiar with digital forensics and incident response, the registry – the Windows database of user, hardware and software configuration – is known as an important source of evidence in investigations of Windows systems. If your registry parsing is limited solely to the active registry stores, however, you’re only ever going to see only part of the story. Registry artefacts are also found in restore points, volume shadow copies, in live memory, page file, hiberfil.sys, and in unallocated space. The question is, how to restore these so that they are searchable for values of interest?
Registry Recon, a tool developed by Mark Spencer of Arsenal Recon, aims to answer this by harvesting registry data from these ‘alternative’ locations, reconstructing the hives where possible and so allowing the examiner to analyse registry keys at particular points in time – an intriguing prospect for digital investigators.
The installation of Registry Recon is very straightforward. If the system you are installing the software on is missing prerequisites such as Microsoft’s .Net Framework 4.0 or Microsoft Visual C++ 2010 Redistributable then users will be alerted during setup and asked to download them. An internet connection is required to validate the install, though there is an option to email the vendors for assistance with validating the licence if you’re installing it on a computer not connected to the internet. By default, Registry Recon utilizes space in the same directory as it is installed for output logging, database generation and hives carved from unallocated and swap space.
I’ve a fairly good handle on navigating Windows software, so I always consider the first test in looking at new software I’m assessing is to see how far I can get without referencing the manual. On starting up Registry Recon, you are presented with a pleasantly designed interface with the first button on the menu titled Evidence. That sounds good to me. Clicking on this Evidence button prompts you to add evidence.
The three local hard drives installed in my laptop were auto-detected very quickly. Alternatively, I could have chosen to mount a forensic image (including EnCase (version 1) .E01, .dd, raw, .001 or VHD (virtual hard disk)) or browse to a directory where, for example, an exported hiberfil.sys file could be parsed.
Being impatient to see what Registry Recon can do, and even more so on my own laptop, which I consider to be relatively ‘clean’, I picked the local drive hosting my install of the Windows 7 operating system. Here I was made to pick the physical drive, not the logical ‘C’ drive: this makes sense if you want the most thorough examination, but there will be situations where the examiner would only want to select, for example, one volume or one file. I presume that this would be an easy feature to add. When the processing had completed there were a few unexpected results in the log file, for example “Failed to import hive file ‘C:\WINDOWS\system32\config\SOFTWARE’ – The process cannot access the file because it is being used by another process.” Following correspondence with Arsenal Recon I discovered that they didn’t recommend running it against your local system – this was a shame, as it also means that it would not be possible to run the app in a ‘live’ forensics situation (unless, for example, used over a network in conjunction with a tool such as F-Response).
Needing to test the software in a different manner, I therefore used an image of an 80GB hard drive, which mounted easily using the mounting facility Registry Recon offers. There isn’t an ability as yet to select what will be scanned, therefore the entirety of the image gets examined for registry artefacts. I think that there may well be examiners who, facing operational or time constraints, may be allowed to only look at a limited data set. I asked Mark Spencer about this and he replied: “The whole point of Registry Recon is aggressively finding as much registry information as possible in a piece of evidence, then processing that information in a way that the user sees only unique values over time.” This was is a good answer, but even so I was pleased to hear that selective data parsing is something that they are considering.
Picture 1: The mounted disk image is presented in this case as Physical Drive 4
After mounting the evidence, being asked to name it, and clicking ‘OK’, the evidence begins to be processed. Straight in – no chance to select the output directory, investigator name and agency etc., as you (and certainly I) may have expected. Late on I discover that you need to navigate to Tools\Configuration to select the output directory. In my experience most investigators use a different output directory for each case, so it would definitely suit most people’s workflows if the location of the output directory was offered as an option at the adding evidence stage.
Picture 2: Importing hives – here hives from Windows restore points are being processed
The laptop I used to test the software was running Windows 7 installed on a Samsung SSD 830 256GB hard drive, with 16GB of RAM, and an Intel i7 3520M processor. The mounted 80GB image was on a USB 3 external hard drive attached to a USB 3 laptop port. Using this configuration Registry Recon took two hours and six minutes to parse the 80GB image. Registry Recon recorded a surprisingly (for me at least) high amount of hive data processed from this image at 4GB, of which 3.8GB was extracted from restore points, 84MB from the active registry, 69MB from allocated space (which I am presuming is from hiberfil.sys and similar) and 125MB carved from unallocated space. That’s quite impressive.
Picture 3: Processing complete – almost 4GB of hive data processed
Opening Registry Recon the following day and attempting to return to this case wasn’t as straightforward as I expected. There appeared to be no option to open an existing case. After a short while I figured it out: under the same menu option (‘Evidence’) used to add new evidence you return to a previous case by selecting ‘Browse Evidence’. I found this unintuitive, when the standard, and simple, ‘New case’ and ‘Open case’ could be used instead.
Picture 4: A loaded case, after processing
Once the case was loaded I was presented with the above screen. In this instance, the image is called ‘Test Image’ and Registry Recon has discovered that alongside the active Windows installation there was a previous Windows installation (entries not present in the current registry are displayed in red), which it has enumerated from the data that it carved from unallocated space. In each instance Registry Recon has extracted the operating system install date next to the name of the operating system. Registry Recon displays reconstructed registry keys, subkeys and values in the same fashion as you’d expect for the active registry. This is a great feature.
The Key History Pane in the interface (as shown in Picture 5 below, showing the contents of a User’s RecentDocs) shows all occurrences in time of the selected keys/subkeys.
Picture 5: Key history
Right-clicking any entry in the Key History pane enables any of these instances to be viewed in the View Pane, where values can be sorted and filtered by date or other fields using the filter editor as shown in the right-hand pane below, in Picture 6:
Picture 6: The view pane on the right of the screen showing the filter editor
A useful feature of Registry Recon is being able to apply pre-defined reports to the registry under examination. At present there are two predefined reports that can be run: one extracts information about USB Storage Devices and the other data on recently accessed documents.
Picture 7: USB Storage Device pre-defined report
This a useful feature that I think could be further improved if the offset location where the registry entries populating the report were found was also listed. If you wish to export the report elsewhere there is a wide number of options available: it can be produced in pdf, mht, rtf, xls, xlsx, csv, txt or as an image (picture) file. I’m sure that users of Registry Recon would welcome a few more pre-defined reports, so let’s hope they are forthcoming in future releases.
In conclusion, Registry Recon offers a very simple method to extract a huge amount of registry data from an image, and presents the data in an easily viewable format where key values can be viewed at various points in time. This is a unique offering as far as I am aware. I’ve pointed out a couple of areas where the tool could be even more straightforward to use, and I understand that these will be addressed by the developers. I would thoroughly recommend that you try it for yourself using the 14-day fully functional version available to download from their web site.
Registry Recon version 2.0.0.0530 is currently available for US $399.00 from http://arsenalrecon.com