toolsmith: Registry Decoder
Binaries require no external dependencies; working from a source checkout requires Python 2.6.x or 2.7.x and additional third-party apps and libraries.
Merry Christmas: "Christmas is not a time nor a season, but a state of mind. To cherish peace and goodwill, to be plenteous in mercy, is to have the real spirit of Christmas.” -Calvin Coolidge
Readers of the SANS Computer Forensics Blog or Harlan Carvey’s Windows Incident Response blog have likely caught wind of Registry Decoder. Harlan even went so far as to say “sounds like development is really ripping along (no pun intended). If you do any analysis of Windows systems and you haven't looked at this tool as a resource, what's wrong with you?” When Registry Decoder was first released in September 2011, I spotted it via Team Cymru’s Dragon News Bytes mailing list and filed it away for future use. Then, in most fortuitous fashion, Andrew Case, one of the Volatility developers I’d reached out to for September’s Volatility column, contacted me regarding Registry Decoder in early November. Andrew co-develops Registry Decoder with Lodovico Marziale as part of Digital Forensic Solutions and kindly provided me with content for the remaining entirety of this introduction.
Registry Decoder is open source (GPL) and written completely in Python and is downloadable via Google Code projects. It was initially funded by the National Institute of Justice and now is funded by Digital Forensics Solutions.
Registry Decoder can analyze registry files from a number of sources and then provide a number of GUI-driven analysis capabilities. The current version of the tool (1.1 as this is written) can import individual registry files, raw (dd) disk images, raw (dd) split images, Encase (E01) images, and databases from the live tool. Once evidence is imported and pre-processed, the investigator then has a number of analysis tools available and new evidence can be added to a case at any time.
Registry Decoder’s analysis capabilities include:
· Browsing Hives (similar to Access Data’s Registry Viewer)
· Hive Searching (more on this below)
· Plugin System (similar to regripper)
· Hive Differencing
· Timelining based on last write time
· Path Based Analysis
· Automated reporting of all of the above
Registry Decoder automates all of this functionality for any number of registry hives and the reporting can handle exporting results from multiple hives and analysis types into one report.
Andrew’s favorite Registry Decoder use case is USBSTOR analysis. Almost every case involving investigating a specific employee requires determining which (if any) USB drives were in use. To do this with Registry Decoder, all an investigator has to do is create a case with the disk images or hives acquired, run the USBSTOR plugin, and then export the results. After pre-processing is done, it takes mere minutes to have a report created with the device name, serial number, etc. of any devices connected. Also, since Registry Decoder pulls historical files from live machines and disk images (System Restore & Volume Shadow Service), this analysis can be run across hives going back months or years.
Similarly, while investigating data exfiltration between multiple employees of a company, Andrew needed to know if they shared USB drives. To make the determination he took the SYSTEM files from each machine, loaded them into Registry Decoder and then used the plugin differencing ability on the USBSTOR plugin. It immediately revealed what drives were shared between computers, including their serial number. Another common use of the differencing feature is with the Services plugin as this quickly identifies malware if you difference your known good disk image vs. a disk image of a machine suspected to be infected.
Registry Decoder’s search feature is one of its strongest features. It allows you to search across any number of hives and filter by keys/values/names, last write time range, wildcard searching, and bulk searching with keyword files.
For a recent case, Andrew had to determine if a person was accessing files they shouldn’t have been looking at. They had a desktop and a laptop, both running XP and both with many System Restore Points. In less than 30 minutes with Registry Decoder, Andrew needed only load the disk images from the two machines into Registry Decoder, make a text file with all the search terms, and then search all the terms across all the hives in the case (including historical ones). This returned results that he then exported into one report and was finished. Another useful search is noted when viewing the search results tab, right click on any result, and immediately jump into the Browse view positioned at that key.
Another good use case includes path-based analysis which allows you to determine if a registry path exists in any number of files. For whichever files it is present in, one can then export the path and optionally its key/value pairs. This is extremely useful in two situations:
1. Determining if certain software is installed (P2P, cracked software, etc.), as you can simply search any of the paths that the program creates and then export its key/values inclusive of when and where the software was installed.
2. During malware analysis as most malware writes to the registry. Searching across numerous suspect systems for the malware’s path allows investigators to immediately determine the extent of infection.
Registry Decoder’s roadmap includes more analysis plugins and added support for memory analysis (integrate with Volatility’s existing in-memory registry functionality).
The developers also want to add support for analyzing previously deleted keys and name/value pairs within hives. The library utilized for enumerating hives, reglookup, already supports this functionality so it is just a matter of integration.
Running the Registry Decoder online acquisition component
I ran regdecoderlive32 on a 32bit Windows XP SP3 virtual machine infected with Lurid and regdecoderlive64 on a Windows 7 SP1 64bit machine.
One note for regdecoderlive32 on Windows XP systems with drives formatted with NTFS. Even when running regdecoderlive32 with administrator privileges the hidden System Volume Information directory is protected with unique ACLs. To circumvent this issue, issue cacls "C:\System Volume Information" /E /G
:F from a
command prompt at the root of C: (this assumes the OS is installed on C:).
As seen in Figure 1, running regdecoderlive is as simple as executing and defining a few parameters including description, output directory (must be empty) and check boxes for acquisition of current and backup files.
|Figure1: Registry Decoder Live|
Once acquisition is complete, the results directory will be populated with registryfiles/acquire_files.db and related files. This results directory can (should) be written to portable storage mounted on the target system or a network share, which can then be consumed by Registry Decoder for offline analysis.
Running the Registry Decoder offline analysis component
Registry Decoder can consume individual registry files, raw (dd) disk images, and Encase (E01) images, including split images. Building a case is as easy as adding a case name and number, investigator, comments, and case directory. Adding evidence to a case after initial processing is created is quite simple; you’ll be prompted to add new evidence after choosing Start Case and opening an existing case.
I only tested Registry Decoder with the acquisition database acquired from a Lurid-infected Windows XP VM via Registry Decoder Live.
Initial processing can take some time depending on the number of restore points or volume shadows.
Once initial processing is complete however, Registry Decoder is nimble and effective.
I mimicked some of Andrew’s use cases in this analysis of a Lurid victim. From runtime analysis of the Lurid sample I had (md5: 84d24967cb5cbacf4052a3001692dd54) I knew a few key attributes to test Registry Decoder with. Services and registry keys created include WmdmPmSp. As the search functionality is a strong suit, I selected CORE from the current snapshot acquired and searched WmdmPmSp. Right-click search results and select Switch to File View then navigate to the Browser tab for key values, etc. as seen in Figure 2.
|Figure 2: Registry Decoder search results|
I made use of the timeline functionality and was amply rewarded. Imagine a scenario where have a ballpark time window for a malware compromise or unauthorized access. You can filter the timeline window accordingly and produce output that is compliant to the SleuthKit’s mactime format. It’s not human readable currently (next release) so read it in with Autopsy or TSK. Timeline gathering and results are combined in Figure 3. It clearly identified exactly when Lurid wrote to HKLM\SYSTEM\CONTROLSET001\SERVICES\WmdmPmSp.
|Figure 3: Registry Decoder timeline results|
I also tested USBSTOR (unrelated to Lurid) on both acquisitions (Windows 7 and Windows XP) and the results were accurate and immediate in both cases as seen Figure 4.
|Figure 4: Registry Decoder USBSTOR results|
Explore the Plugins options included with Registry Decoder, the possibilities are endless. SYSTEM will provide you a nice summary overview as you begin, IE Typed URLs is great for inappropriate browser use, Services with Perform Diff enabled is excellent for malware hunting, System Runs will give you instant gratification regarding what’s configured to run on startup, ACMRU queries the registry keys that have been typed into the Windows Search dialog box, and on and on and on. J Brilliant!
I’m extremely excited about this tool and imagining its use at scale to be of incredible use for enterprise incident responders and forensic examiners. I’ve been chatting with Andrew at length while writing this and he continuously mentions pending features including some visualization options and the aforementioned Volatility interaction. I can’t wait; check out Registry Decoder out for yourself ASAP.
Ping me via email if you have questions (russ at holisticinfosec dot org).
Cheers…until next month.
Andrew Case, Registry Decoder developer and project lead