Wednesday, April 15, 2009

Timeline Analysis - RegRipper

In my last post on timeline analysis, I described using file system data (via TSK's fls.exe), Event Log data (via a custom Perl script) and Recycle Bin/INFO2 file data (also via a custom Perl script) to generate a timeline of activity on the system. One of the sources that is missing is, well, Registry hive file data...but that's changing.

The Registry contains a great deal of timestamped data that can be extremely useful when added to a comprehensive timeline.

First, here's the output of the acmru plugin as is currently seen by RegRipper (or more appropriately,
C:\Perl\forensics\rr> -r d:\cases\ntuser.dat -p acmru
ACMru - Search Assistant

Software\Microsoft\Search Assistant\ACMru
LastWrite Time Mon Sep 26 23:02:08 2005 (UTC) 5603 [Mon Sep 26 23:32:56 2005 (UTC)]
000 -> port*
001 -> sol.exe
002 -> hacker*

003 -> hack*

004 -> lad*

5604 [Mon Sep 26 23:33:30 2005 (UTC)]

000 -> disk
001 -> ha*

What the above output tells us is that this particular user ran searches (via Start->Search->For Files and Folders...) on 26 Sept 2005, looking for "port*" and "disk", at 23:32 and 23:33 UTC, respectively. I've bolded the most recent searches, as those are on the searches that correlate to the LastWrite times of the keys (seen directly above the bolded text). The other searches were run at some other time, and like most MRUs, do not have a specific time associated with them; therefore, for the purposes of generating a timeline, they will most likely be of little use...although there's no doubt that overall, they'd be useful.

Now, here's what the timeline information looks like:

C:\Perl\forensics\rr> -r d:\cases\ntuser.dat -p acmru -t 1127775728|REG||jdoe|M... Software\Microsoft\Search Assistant\ACMru 1127777576|REG||jdoe|M... Software\Microsoft\Search Assistant\ACMru\5603 (000 = port*) 1127777610|REG||jdoe|M... Software\Microsoft\Search Assistant\ACMru\5604 (000 = disk)

You can see here that I've output the information in the familiar five field (time, type, server, user, description) format. Redirecting this information (and all other timeline information) to the overall event file will allow you to parse this data right along with the file system and Event Log timeline data, as well as data from any other source (such as the Recycle Bin INFO2 files, etc.). This can be extremely important, as a user launching an application will be visible near the file system activity associated with the results of that application. In the case of the example above, a recent search can account for a number of files all having last accessed times relatively close together.

Part of what these updates to RegRipper/rip allow the code to do is 'guess' which hive file is being accessed. If the hive file is a user's hive, the code will attempt to extract the username and SID for later use (as with the timeline information above...the 'jdoe' username was automatically populated). Similarly, if the hive is a System hive file, the code will extract the ComputerName value from the hive file for use in the timeline information. However, the server and username values will not be able to be populated for every hive file; for example, the Software, Security and SAM hives do not contain an easily-referenced value for the system or server they're on, and do not apply to a specific user. The way around this is to allow the user to enter this information via the '-s' and '-u' switches to

Adding this capability to ripXP will allow a plugin to be run across all of the hive files within the System Restore Points, extracting historical data for inclusion in the timeline. Very, very sweet.

1 comment:

cosimo said...


this is really cool! I was already planning to modify to make it write its outputs into an SQLite database for timeline processing, and having the plugins already able to directly generate timeline points will greatly ease my task.