Registry Analysis - What Is It??
That's right...what is this thing we call "Registry analysis"? When someone performs "Registry analysis", what are they doing?
Okay...raise your hand if, for you, Registry analysis consists of looking for strings (using strings, or BinText, or your favorite tool), or maybe using grep() to do regex searches for IP addresses, email addresses, or something else.
Great, thanks. You can put your hands down.
Now, raise your hand if when performing Registry analysis, you open the hive files you're interested in with one of the popular Registry viewers (EnCase, FTK, ProDiscover, or even good ol' RegEdit), and "look around for anything interesting". Keep it up there if you use some sort of checklist or spreadsheet of Registry keys that may be of interest for your case or exam.
Okay...great. Go ahead and put your hands down.
So, what's wrong with either of these methodologies? Cumbersome? Inefficient? In some cases, ineffective? Ever wonder what you're missing? How about...A LOT?
The fact of the matter is, I really believe that Registry analysis isn't being performed today nearly as much as it should because it isn't "easy". I mean, sure, you've got this file that contains all this data, all this potential "evidence" (depending upon the audience, of course), but you don't know (a) how to get it, and maybe even (b) how to interpret it. After all, Registry viewers don't give you what you need, do they? They just present the data as is...it's up to you, the investigator or analyst to make heads or tails of it.
What if you just want to get the most recent document accessed...not just by the user, but via various applications, such as RealPlayer, maybe an image viewer, Excel, Adobe Reader, or even just by one of the common dialogs? If you're just looking for documents accessed, there are a LOT of places to look in the Registry...and using a checklist can take a long time. Also, due to encoding used by various vendors, regular ASCII/Unicode string searches won't work. So what if your "checklist" could be run against the Registry hive file itself?
What about those times when you have to correlate between multiple Registry keys, such as when you're trying to find out about those installed BHOs, or trying to determine when a USB thumb drive was last plugged into the system? How cumbersome is that?
How would you
like to rip through your Registry analysis, getting just what you need, presented in the way you need it, or at least a way that's usable? Forget spreadsheets and checklists...how about plugins (stuff like Nessus and Metasploit use plugins, right?) that reach out and get what you want? How about...in order to update this tool, plugins just need to be dropped into a directory, and they're ready to use? How about it this all came with a GUI and a nice "FindAllEvidence" button?
What if you could also get timestamped data (ie, most recently accessed documents, UserAssist entries, etc.) so that you could import it into a format such as Excel, or even XML (for use with Simile TimeLine)?
Know what's really cool about the timestamped data? In order for it to be placed in the user's Registry hive file (NTUSER.DAT), the user account needs to be logged into the system. Sounds pretty simple, doesn't it? Hit most public lists, though, and you'll see questions such as, "how do I tell when a user was logged on if auditing of logon events isn't recorded in the Security Event Log?" (I'm paraphrasing, of course). Well, in most cases, when someone logs on, they do something...right? Look at all of the user activity that is recorded (I say 'recorded" because in many ways, the Registry is a log file, of sorts) in the user's hive file...and then correlate that to other activity (Internet browser history, etc.) that may be available.
Sound pretty cool? How about flippin' sweet?!?
The fact is, there's "lookin' at" the Registry, and then there's doing real Registry analysis and getting the data you need.
Addendum
Some might be wondering, "What is it about Registry analysis that's so hot? After all, I get all of the information/evidence I need from the file system." Well, I can only speak to those things that I've determined through Registry analysis...logon history, files accessed, files NOT accessed, applications that had been installed, run, and then uninstalled, etc. There is a great deal of information...much of it historical, much of it associated in some way with a time stamp...right there in the Registry.
Addendum, 1 Apr
Okay, this isn't a joke...but I added three plugins to the RegRipper last night. One for the Uninstall key in the Software hive (all entries sorted based on the key LastWrite times), as well as one for the USBStor key, and another for the DeviceClasses keys...both in the System hive.
Adding a plugin for the Protected Storage System Provider is going to be problematic until I get some info how to decrypt the data in the "Item Data" values.
Okay...raise your hand if, for you, Registry analysis consists of looking for strings (using strings, or BinText, or your favorite tool), or maybe using grep() to do regex searches for IP addresses, email addresses, or something else.
Great, thanks. You can put your hands down.
Now, raise your hand if when performing Registry analysis, you open the hive files you're interested in with one of the popular Registry viewers (EnCase, FTK, ProDiscover, or even good ol' RegEdit), and "look around for anything interesting". Keep it up there if you use some sort of checklist or spreadsheet of Registry keys that may be of interest for your case or exam.
Okay...great. Go ahead and put your hands down.
So, what's wrong with either of these methodologies? Cumbersome? Inefficient? In some cases, ineffective? Ever wonder what you're missing? How about...A LOT?
The fact of the matter is, I really believe that Registry analysis isn't being performed today nearly as much as it should because it isn't "easy". I mean, sure, you've got this file that contains all this data, all this potential "evidence" (depending upon the audience, of course), but you don't know (a) how to get it, and maybe even (b) how to interpret it. After all, Registry viewers don't give you what you need, do they? They just present the data as is...it's up to you, the investigator or analyst to make heads or tails of it.
What if you just want to get the most recent document accessed...not just by the user, but via various applications, such as RealPlayer, maybe an image viewer, Excel, Adobe Reader, or even just by one of the common dialogs? If you're just looking for documents accessed, there are a LOT of places to look in the Registry...and using a checklist can take a long time. Also, due to encoding used by various vendors, regular ASCII/Unicode string searches won't work. So what if your "checklist" could be run against the Registry hive file itself?
What about those times when you have to correlate between multiple Registry keys, such as when you're trying to find out about those installed BHOs, or trying to determine when a USB thumb drive was last plugged into the system? How cumbersome is that?
How would you
like to rip through your Registry analysis, getting just what you need, presented in the way you need it, or at least a way that's usable? Forget spreadsheets and checklists...how about plugins (stuff like Nessus and Metasploit use plugins, right?) that reach out and get what you want? How about...in order to update this tool, plugins just need to be dropped into a directory, and they're ready to use? How about it this all came with a GUI and a nice "FindAllEvidence" button?What if you could also get timestamped data (ie, most recently accessed documents, UserAssist entries, etc.) so that you could import it into a format such as Excel, or even XML (for use with Simile TimeLine)?
Know what's really cool about the timestamped data? In order for it to be placed in the user's Registry hive file (NTUSER.DAT), the user account needs to be logged into the system. Sounds pretty simple, doesn't it? Hit most public lists, though, and you'll see questions such as, "how do I tell when a user was logged on if auditing of logon events isn't recorded in the Security Event Log?" (I'm paraphrasing, of course). Well, in most cases, when someone logs on, they do something...right? Look at all of the user activity that is recorded (I say 'recorded" because in many ways, the Registry is a log file, of sorts) in the user's hive file...and then correlate that to other activity (Internet browser history, etc.) that may be available.
Sound pretty cool? How about flippin' sweet?!?
The fact is, there's "lookin' at" the Registry, and then there's doing real Registry analysis and getting the data you need.
Addendum
Some might be wondering, "What is it about Registry analysis that's so hot? After all, I get all of the information/evidence I need from the file system." Well, I can only speak to those things that I've determined through Registry analysis...logon history, files accessed, files NOT accessed, applications that had been installed, run, and then uninstalled, etc. There is a great deal of information...much of it historical, much of it associated in some way with a time stamp...right there in the Registry.
Addendum, 1 Apr
Okay, this isn't a joke...but I added three plugins to the RegRipper last night. One for the Uninstall key in the Software hive (all entries sorted based on the key LastWrite times), as well as one for the USBStor key, and another for the DeviceClasses keys...both in the System hive.
Adding a plugin for the Protected Storage System Provider is going to be problematic until I get some info how to decrypt the data in the "Item Data" values.
