Registry Analysis

When you see the words, "Registry analysis", what comes to mind? 

Okay, now...what actually happens when we 'do' this thing we call "Registry analysis"?  More often than not, what this refers to manifests itself as opening a Registry hive file in a viewer, "looking around", or maybe doing some searches or sorting based on dates.  But is that really Registry analysis, or is it simply parsing and viewing?

Often, when you get right down to it and peel back all of the layers (like an onion), "analysis" (in general) from an operational perspective manifests as:

• Get a data source, often based on a list provided by an external resource
• Open that data source in a viewer, or parse it and open the output in another application (Excel)
• Locate specific items, again often based on an externally-provided list; this can include conducting a search based on some items (time) or keywords
• Do the same with another data source
• Lather, rinse, repeat

For example, an analyst might extract the MFT, parse it via a tool such as AnalyzeMFT or MFTECmd, search for specific files, or for files created or modified during a specific time frame, and then manually transpose that information into a spreadsheet.  If other data sources are then examined, the process is repeated, and as such, the overall approach to getting to the point of actually conducting analysis (i.e., looking at the output from more than one data source) is very manual, very time intensive, and as a result, very expensive.

To that point, 'cost' isn't just associated with time and expense.  It's also directly tied in with what's included in the analyst's final spreadsheet; more specifically, the approach lends itself to important artifacts and TTPs being missed.  OSINT regarding a threat actor group, based on analysis of the malware associated with the group, most often focuses on IOCs does not account for TTPs and behaviors (i.e., how the malware and tools are used...).  This includes not just of the threat actor's behaviors on the system, but also as a result of the threat actor's interactions with the ecosystem in which they're operating.  OSINT is not intrusion intelligence, and if the analyst uses that OSINT as the totality of what they look for, rather than just the beginning, then critical data is going to be missed.

One way of overcoming this is the use of automation to consume and correlate multiple data sources simultaneously, viewing them in relation to each other.  Some have looked at automation tools such as log2timeline or plaso, but have experienced challenges with respect to how the tools are used. Perhaps a better approach is a targeted, 'sniper forensics' approach, rather than the usual "spray and pray" approach.

For many analysts, what "Registry analysis" means is that they may have a list of "forensically relevant" items (i.e., keys and values), perhaps in a spreadsheet, that they use to manually peruse hive files.  As such, they'll open a hive in a viewer and use the viewer to navigate to specific keys and values (Eric's Registry Explorer makes great use of bookmarks).  This list of "forensically relevant" items within the Registry may be based on lists provided to the analyst, rather than developed by the analyst, and as such, may not be complete.  In many cases, these lists are stagnant, in that once they are received, they are neither extended, nor are new items (if determined) shared back with the source.

Rather than maintaining a list of keys and values that are "forensically relevant", analysts should instead consider what is "forensically relevant" based on the analysis goals of the case, and employ a process that allows them to not only find the items they're looking for, but to also 'see' new things.  For example, I like to employ a process that creates a timeline of activity, using Registry key LastWrite times, as well as parsing specific values based on their associated time stamps.  This process correlates hive files, as well...doing this using the Software hive, user's NTUSER.DAT and USRCLASS.DAT, as well as the AmCache.hve file, all in combination, can be extremely revealing.  I've used this several times to 'see' new things, such as what happens on a system when a user clicks on an ISO email attachment.  Viewing all of the 'events' from multiple sources, side-by-side, in a consolidated timeline provides a much more complete picture and a much more granular view than the traditional "manually add it to a spreadsheet" approach.

Adding additional sources...MFT, Windows Event Logs, etc...can be even more revealing of the overall TTPs, than simply viewing each of these data sources in isolation.