RegRipper was created and maintained by Harlan Carvey. RegRipper, written in Perl, is the fastest, easiest, and best tool for registry analysis in forensics examinations. RegRipper has been downloaded over 5000 times and used by examiners everywhere.

How can you make it better?

If you want RegRipper to be better, you can help by first sending in registry hives with specific information of what you need RegRipper to do with that hive to Harlan Carvey. Is it a P2P application of interest? Or USB devices? Or…?

What is the RegRipper?
RegRipper is *not*…it’s not a Registry Viewer. An examiner would not open a Registry hive file in RegRipper to “look around”.

Further, RegRipper is NOT intended for use with live hive files. Hive files need to be extracted from a case (or from a live system using FTK Imager…), or accessible via a tool such as Mount Image Pro or F-Response.

RegRipper is a Windows Registry data extraction and correlation tool. RegRipper uses plugins (similar to Nessus) to access specific Registry hive files in order to access and extract specific keys, values, and data, and does so by bypassing the Win32API.

How does RegRipper work?
RegRipper uses James McFarlane’s Parse::Win32Registry module to access a Windows Registry hive file in an object-oriented manner, bypassing the Win32API. This module is used to locate and access Registry key nodes within the hive file, as well as value nodes and their data. When accessing a key node, the LastWrite time is retrieved, parsed and translated into something the examiner can understand. Data is retrieved in much the same manner…if necessary, the plugin that retrieves the data will also perform translation of that data into something readable.

Who should/can use RegRipper?
Anyone who wants to perform Windows Registry hive file analysis. This tool is specifically intended for Windows 2000, XP, and 2003 hive files (there has been limited testing on Vista/Win2K8 hive files…everything has worked fine so far…).

How do I use RegRipper?
Simply launch rr.exe. Also, please be sure to read the RegRipper documentation.

Do I have to install anything to use the RegRipper?
Nope, not a thing. RegRipper ships as an EXE file, able to run on Windows systems. All you need to do is extract the EXE and DLL in the same directory. The source file (rr.pl) is also included, as are the plugins.

Further, RegRipper doesn’t make any changes to your analysis system…no Registry entries are made, nor are any files installed in odd, out-of-the-way locations.

HC

—————————————————————

RipXP

Installing
RipXP uses all of the same plugins available with RegRipper, so simply extract the files in this archive into the same directory with RegRipper (rr.exe) and rip (rip.exe).

Running
1. Using your tool-of-choice (I use FTK Imager), open the image and extract the hive files you’re interested in from the system32\config directory, as well as from user profile(s), into a directory (ie, D:\cases\case001\xp\config).

2. Using that same tool, within the image navigate to the directory where the Restore Point directories are located (usually C:\System Volume Information\{GUID}\). Extract all of the RP* directories into a directory on your analysis system (ie, D:\cases\case001\xp\restore).

3. To see the options used by RipXP, simply type:
C:\ripXP>ripxp

RipXP allows you to run one plugin across a designated hive file, and all corresponding hive files in the Restore Point directories.

RegRipperis an open source tool, written in Perl, for extracting/parsing information (keys, values, data) from the Registry and presenting it for analysis.

RegRipperconsists of two basic tools, both of which provide similar capability. TheRegRipper GUI allows the analyst to select a hive to parse, an output file for the results, and a profile (list of plugins) to run against the hive. When the analyst launches the tool against the hive, the results go to the file that the analyst designated. If the analyst chooses to parse the System hive, they might also choose to send the results to system.txt. The GUI tool will also create a log of it’s activity in the same directory as the output file, using the same file name but using the .log extension (i.e., if the output is written to system.txt, the log will be written to system.log).

RegRipperalso includes a command line (CLI) tool called rip. Rip can be pointed against to a hive and can run either a profile (a list of plugins) or an individual plugin against that hive, with the results being sent to STDOUT. Rip can be included in batch files, using the redirection operators to send the output to a file. Rip does not write a log of it’s activity.

RegRipperis similar to tools such as Nessus, in that the application itself is simply an engine that runs plugins. The plugins are individual Perl scripts that each perform a specific function. Plugins can locate specific keys, and list all subkeys, as well as values and data, or they can locate specific values. Plugins are extremely valuable in the sense that they can be written to parse data in a manner that is useful to individual analysts.

Note: Plugins also serve as a means of retaining corporate knowledge, in that an analyst finds something, creates a plugin, and adds that plugin to a repository that other analysts can access. When the plugin is shared, this has the effect of being a force multiplier, in that all analysts know have access to the knowledge and experience of one analyst. In addition, plugins remain long after analysts leave an organization, allowing for retention of knowledge.

How do I..

Go to the download site for RegRipperand get the archive that contains the most recent version of RegRipper(in this case, rrv2.5.zip). Extract the archive into a directory on your system, such as “C:\rr”.

Next get the latest plugin archive, based on the date of the archive, and extract everything in the archive into “C:\rr\plugins”.

That’s it…you’re done. Either launch rr.exe (the GUI) or run rip.exe (CLI) from the command prompt.

…get a list of all plugins?

This is actually pretty straight-forward. To list all of the plugins in the \plugins folder, simply open a command prompt, navigate to the folder where you installed RegRipper, and type:

rip -l

Another way to see what plugins are available is to launch the Plugin Browser (pb.exe), and navigate through the list of plugins, one at a time. In order to get a .csv listing of the available plugins, use this command:

rip -l -c > plugins.csv

You can then open the resulting file in Excel.

In order to get just a listing of plugins available for a particular hive file (in this case, the Software hive), type:

Perhaps one of the biggest misconceptions regarding the RegRipperplugins is whether or not it does specific things; that is, does it check for specific values, parse specific data, or enumerate the contents of specific keys? This isn’t the right question to ask.

From the beginning, RegRipperplugins have been created and updated based on needs. Some needs are relatively easy to meet, due to the availability of data; most Windows systems have a ‘Run’ key. Other plugins have been created/modified due to unique circumstances based on analysis; finding something new or unusual during an examination will very often result in a new plugin, or an update to an existing plugin.

Of those currently writing plugins, it appears that few have encountered systems on which the P2P application Ares has been installed and used. As such, the ares.pl plugin may be somewhat limited and not meet the complete needs of a specific examiner working on a specific case.

In short, the power of RegRipperis in the plugins, and for this to be a truly powerful tool, it depends on examiners sharing their needs and data before hand, rather than asking, “Does it do…?” after the fact.

If you have any suggestions, recommendations, or questions about RegRipper, just ask Harlan. Don't be afraid. Don't post all over the Internet that RegRipper doesn't do what you thought it would or is defective. Ask Harlan. http://windowsir.blogspot.com

This email address is being protected from spambots. You need JavaScript enabled to view it.

This section presents and discusses a list of artifact categories, as they relate to the RegRipper tools and plugins. As they are defined or described (see below), each of these categories applies specifically to artifacts found within the Windows Registry.

Many of the available Registry artifacts persist beyond file and program deletion, providing indications of system or user activity that occurred in the past.

Many artifacts can and may fall within multiple categories. For example, the File Access category by extension indicates Program Execution.

Multiple categories of artifacts can be used in analysis though the use of an analysis matrix.

Categories are identified within plugins as part of the configuration hash (%config) provided as part of the plugin. The use of categories in this manner does not obviate the use of profiles within RegRipper; instead, it enhances that capability.

Note: This should be considered to be a living document, subject to update and modification.

Category Definitions

What follows are some of the categories that have been identified, along with descriptions of each of the categories.

Where applicable, examples of available RegRipper plugins are provided.

Program Execution

Installed Programs

Installed Programs artifacts differ from Program Execution artifacts, in that many applications/programs are installed on a Windows system via a setup.exe file, or via an MSI file. As such, the program itself has artifacts in the Software hive, and then user-specific artifacts "live" in the user's NTUSER.DAT hive.

An example of this includes Adobe Reader; the Software hive will contain information about the system-wide application configuration, while the NTUSER.DAT hives will indicate not only which user(s) launched the application, but also maintain an MRU list of files that the user accessed.

Note: A program or application can be installed, but may not have been executed.

Example plugins: apppaths.pl

Storage Information

This category pertains to the usage of or access to storage media, including (but not limited to) USB devices, network shares, "cloud" storage, etc.

Example plugins:

Log Info

This category pertains to artifacts related to the configuration of log files on the system, which can include Windows Event Logs, as well as application specific logs.

Example plugins:

Malware

This category pertains to artifacts that specifically provide indications of malware infection or activity. This category differs from the AutoStart category, in that legitimate applications can make use of AutoStart artifacts. In many instances, the AutoStarts or Program Execution categories can be used to extract general information (i.e., contents of the Run key, etc.) that the analyst can review, plugins in the Malware category can be used to look for specific artifacts related to a variety of specific malware samples, or related to malware families.

Examples of a malware specific artifacts include:

Variants of Zeus have been known to add "sdra64.exe" to the UserInit Registry value

OSVerion

Example plugins: osversion.pl, zeus.pl

File Access

This category pertains to files that a user has accessed, which is most often through the use of a specific application. As such, artifacts within this category will indicate Program Execution (or usage), but the purpose of this category is to provide indications of files that a user specifically had access to, via downloading, or through creation or modification.

Example plugins: recentdocs.pl, trustrecords.pl

Communications

This category can be a subset of the Installed Programs and Program Execution categories, and is specific to programs/applications intended for off-system communications. While the Program Execution category may be used to look for indications of the use of ftp.exe or chat programs, this category is intended for communication application-specific artifacts.

Example plugins:

Analysis Matrix

The above listed categories can be used in an analysis matrix; several categories of artifacts may be used in specific types of analysis activities.

The following table is a notional analysis matrix, and is intended to serve as a starting point for both discussion and analysis:

Malware Detection

Data Exfil

Unauth Use

Illicit Images

Program Execution

X

X

Malware

X

X

File Access

X

X

Storage Info

X

X

Comms

X

X

Tool Architecture

RegRipper is actually a suite of tools that all rely on a core set of functionality.

Helper Functions

The main user interface (UI) tools for RegRipper (ie, the RegRipper GUI and the rip CLI tools) provide a number of functions to the plugins. These functions are included in a separate .pl file, and are accessed by the UI code via the require pragma (allows the code to be loaded at run-time). This allows for the following:

The one set of code is available to the UI tools in a uniform manner.

The helper function code can updated and made available without requiring the tools themselves to be completely recompiled.

The code is completely transparent; anyone can open the helper files and see what the code is doing.

Note: In order to make the code portable and usable by the widest range of users, any modules required to use the helper functions (ie, Time::Local) will be compiled into the UI.

Time

This secton is about how time is treated on Windows systems, as well as the various time formats found on Windows systems.

Formats

Time in recorded in a number of formats on Windows systems. Even though MS maintains a page that discusses time formats, there are other formats available, as well.

Unix Time

Unix epoch time - yes, there are time values recorded on Windows systems in the 32-bit Unix epoch time format, which is the number of seconds since midnight UTC, 1 Jan 1970.

This time format has a granularity of 1 second.

This time format is found in Windows XP/2003 Event Log records, as well as some Registry value data.

To convert this time format to something readable, use the built-in gmtime() function.

UUID

UUID - Windows systems maintain volume GUIDs, particularly those associated with volumes beneath the MountedDevices and MountPoints2 keys, in UUIDv1 format. Part of this format specification includes a 60-bit time value, which indicates the number of 100-nanosecond intervals since 15 Oct 1582 (this date is described in the RFC as the date of Gregorian reform to the Christian calendar).

This time format has a granularity of 100 nanoseconds.

Note: This format also includes a "node" value, which for several of the volume GUIDs is a MAC address that was available on the Windows system at the time that the GUID was generated.

FILETIME

FILETIME - A 64-bit time value representing the number of 100-nanosecond intervals since midnight UTC, 1 Jan 1601. Used pervasively throughout Windows systems, and can be found:

$STANDARD_INFORMATION and $FILE_NAME attributes within MFT records

Registry key properties

Registry value data

This time format has a granularity of 100 nanoseconds.

Perl code for translating a FILETIME object into a Unix epoch time (borrowed from Andreas Schuster):

SYSTEMTIME

SYSTEMTIME - 128-bit format, and according to MS, "The time is either in coordinated universal time (UTC) or local time, depending on the function that is being called." This time format is used in a number of artifacts on Windows systems, including (but not limited to) in XP Scheduled Task/.job files, as well as in value data beneath the Vista/Win7 NetworkList key (within the Software hive).

It is important to note that this value can be stored in the Registry in either UTC or localtime format. Beneath the NetworkList key, for example, the value is stored in localtime format.

Shellbags

MS KB 813711 describes what actions cause data to be added to the Shell Bags values.

The structure of shell items is very important to understand, as these structures are used in multiple locations on Windows systems, not just in the Shell BagMRU subkeys within the Registry. For example, the structures are used in the shell item ID list section in Windows shortcut LNK files, as well as within the LNK streams in .automaticDestinations-ms Jump List files on Windows 7. These structures are also used within the data of values beneath the OpenSavePidlMRU keys within the Windows 7 NTUSER.DAT hives (full path is "HKU\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\OpenSavePidlMRU").

As such, being able to recognize and parse these structures is essential to being able to fully understand the data that you're looking at, and what it's telling you.

GUIDs

The Variable type (type == 0x00) data structures can contain a variety of information, in various formats. One of the data structures, in particular, can be seen (when viewed in hex) to contain "1SPS" in several places. If the data is broken up, using "1SPS" as a separator (ie, via Perl's split() function), the first 16 bytes of each section appears to be a GUID.

Apparently, this GUID applies to both desktop and Metro-style (Win8) apps, and is referred to as both a SHCOLUMNID and a PROPERTYKEY structure. The contents of the subsection of data that begins with this GUID can be further parsed using a distinct set of rules.

Links

Alerts

The purpose of adding alerts (or an alerting function, via alertMsg()) is to provide a facility for identifying items of interest (from previous analyses) within the vast wealth of data available within a Windows system, and in particular the Registry. This allows an analyst to identify "low-hanging fruit" that may be of value to an examination.

This page will serve as a facility for collaboration amongst the admins of this site, to add, revise, and hone the information alerted on within various plugins.

Plugins

Many plugins provide path information that can be searched via grep() for specific indicators of suspicious or malicious activity:

Checking for Encryption

MountedDevices key - check value data for "TrueCryptVolume"; access to a TrueCrypt volume often results in a volume GUID within the MountedDevices key that includes "TrueCryptVolumeN" in the data (with N being a volume letter)