Registry Analysis

First off, what is “analysis”?

I submit that “analysis” is what happens when an examiner has investigative goals and context, and applies this, along with their knowledge and experience, to a data set. This can be anything, from a physical image of a mobile device, to a triage collection from an endpoint, to logs from a device, or various devices. 

IMHO, this distinction is valuable, because what we often call “analysis” is really nothing more than parsing. For example, someone may recommend (or state as part of their process) that we open a Registry hive in a viewer, and navigate to a particular path by clicking through the UI. Now, there are ways that this could be accomplished in a much more efficient manner (I didn’t say “easier”, because the command line isn’t “easier” for some), but in the end, looking for one value, dumping all of the values from a user’s Run key is still just parsing; there’s no “analysis” unless the investigator can articulate how this action and their finding applies to their goals. 

Registry Analysis
That being said, again…what we most often think of, or refer to as “Registry analysis” really amounts to nothing more than simple parsing. Few are actually conducting analysis of the files that comprise the Windows Registry, largely because the knowledge of and experience with these files is often somewhat limited. For example…and you don’t need to raise your hands…but how many analysts are incorporating Registry hive file metadata into timelines? Or incorporating deleted keys and values in their overall analysis plan?

The Windows Registry includes a great deal of information related to the configuration of the endpoint, and for each user, contains information related to that user’s activities. Not only does the Registry contain considerable metadata, but some of the values found within the Registry can contain valuable information regarding pre-existing states/conditions of the endpoint. For example, what we refer to as “shellbag” artifacts are comprised of shell items, strung together in shell item ID lists. Some of these shell items themselves contain considerable metadata, such as time stamps from folders, preserved at the time the “shellbag” artifacts were created. 

Something else to consider is that very often, information stored in the Registry will persist beyond the point where applications and files are deleted/removed from the endpoint. 

Content was cut in order to protect the source.Please visit the source for the rest of the article.