Pages

Friday, March 28, 2008

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.

17 comments:

  1. Anonymous7:40 AM

    I sense a new tool in the making, can I sign up as a beta tester?

    ReplyDelete
  2. Anonymous9:37 AM

    I normally avoid say " Me too please" to these kind of requests, but for something like this I would stand in a line outside in the rain for a chance to get this tool. Harlan ! Save us...
    Cheers,
    mitch impey

    ReplyDelete
  3. Anonymous10:08 PM

    HC, just came across your blog, been reading posts and using your stuff for at least a half decade. Keep up the good work, can't wait to see this registry ripper.

    why the hell can't encase with all their millions of dollars make something good like this? Why is one smart guy out doing a mutli-million dollar company with hundreds of employees?

    ReplyDelete
  4. ErikC

    why the hell can't encase with all their millions of dollars make something good like this?

    I'm doing it b/c it's something I do...and it started out as a tool that I use. At a certain point, it just made sense. Large, corporate-backed tools don't do it, likely b/c not enough of their user's do Registry analysis.

    ReplyDelete
  5. Didier and Mitch...

    Send me an email address...

    H

    ReplyDelete
  6. HC, this sounds excellent. This has always been a gap in automated analysis. I've been to five of large vendor's classes in the last four years, and they just brush the surface.

    Looks like you're getting beta testers. If you want another...I'd certainly be willing.

    Keep up the great work!

    ReplyDelete
  7. Martin,

    Let's say, for the sake of argument, that someone wanted to send you something via email...how would they go about doing that?

    ReplyDelete
  8. Definitely a very useful tool. Our team here does registry analysis but because it is time intensive we just go for specific keys based on the specifics of the case. A tool that would extract all of the information in a report format would be much more useful on an investigative level. If you're looking for testers we're up for it =)

    ReplyDelete
  9. "...because it is time intensive..."

    This is one of the big myths (no, I don't have a lisp) of Registry analysis! Registry analysis is like anything else...there is a learning curve, and until this form of analysis is more widely accepted and practiced, it's going to be viewed as "time intensive". Dude, learning to drive a car is "time intensive"...until you actually do it! However, folks learn to drive cars out of necessity/passionate desire. The same holds true for a good deal of computer forensic analysis...folks learn to do it out of need or desire. The same needs to be said for Registry analysis.

    ReplyDelete
  10. True but that isn't what I meant by time intensive. I need to clarify better - what I meant is that the time needed to examine the registry overall versus the value of the information discovered is currently too high. That is what I meant by time-intensive. In other words, I have many, many useful places in the registry I can look at. But given that a small percentage of them are relevant and I have many cases to process it simply isn't worth the time to look at them all on the off-chance it might be useful information for a specific case. With a reporting tool available this equation changes - hence our interest. We'd obviously prefer to be more thorough but it isn't practical to examine every possibility at the moment.

    ReplyDelete
  11. "...the time needed to examine the registry overall versus the value of the information discovered is currently too high."

    Again, I couldn't disagree more...tools such as RegRipper (and an associated CLI utility I've added called rip.exe) make looking in those "many, many usual places" quick and efficient. I've said over and over again that one of the uses of Perl that I so enjoy is to automate repetitive tasks, increasing speed and efficiency, and decreasing the chance of making mistakes.

    ReplyDelete
  12. Not to put too fine a point on it, but I never was taking beta testers. It's great that you offered, but I have no way of getting in touch with you (except via postings to the blog), nor of sending anything to you.

    ReplyDelete
  13. HC,

    It's sippy. Could you email me the prog, so i could check it out. Feedback promised :)

    i would email u, but i managed to lock myself out of my yahoo account.

    thnx
    sip

    ReplyDelete
  14. Sippy,

    How do I email you? All I have is your Yahoo account... ;-)

    ReplyDelete
  15. sry i should have clarified - plz email yahoo acct, it will unlock automagically in 12-24 hr, whilst i nervously tap my feet.. thnx!

    ReplyDelete
  16. It sounds like you have identified an area that has always been lacking with PC Analysis. I would really like to check out your tool and give you feedback.

    ReplyDelete
  17. RegRipper is posted here, as file "rr-040708.zip".

    The package includes all current plugins, an FAQ file, a whitepaper, as well as the EXE (both need to the included DLL) and Perl source for the utilities.

    ReplyDelete