There are some great tools out there for viewing the Registry in an acquired image. EnCase has this, as does ProDiscover (I tend to prefer ProDiscover's ability to parse and display the Registry...) and AccessData's Registry Viewer. Other tools have similar abilities, as well. But you know what? Most times, I don't want to view the Registry. Nope. Most times, I don't care about 90% of what's there. That's why I wrote most of the tools available on the DVD that ships with my book, and why I continue to write other, similar tools.
For example, if I want to get an idea of the user's activity on a system, one of the first places I go is to the SAM hive, and see if the user had a local account on the system. From there, I go to the user's hive file (NTUSER.DAT) located in their profile, and start pulling out specific bits of information...parsing the UserAssist keys, etc...anything that shows not only the user's activities on the system, but also a timeline of that activity. Thanks to folks like Didier Stevens, we all have a greater understanding of the contents of the UserAssist keys.
Now, the same sort of thing applies to the entire system. For example, one of the tools I wrote allows me to type in a single command, and I'll know all of the USB removable storage devices that had been attached to the system, and when they were last attached. Note: this is system-wide information, but we now know how to tie that activity to a specific user.
On XP systems, we also have the Registry files in the Restore Points available for analysis. One great example of this is the LEO that wanted to know when a user had been moved from the Users to the Administrators group...by going back through the SAM hives maintained in the Restore Points, he was able to show approximately when that happened, and then tied that to other activity on the system, as well.
So...it's pretty clear that when it comes to Registry analysis, the RegEdit-style display of the Registry has limited usefulness. But it's also clear that there really isn't much of a commercial market for these kinds of tools. So what's the answer? Well, just like the folks who get their rides or cribs pimped out on TV, specialists bring a lot to the table. What needs to happen is greater communication of needs, and there are folks out there willing and able to fulfill that need.
Here's a good question to get discussion started...what's good, easy-to-use and easy-to-access format for a guideline of what's available in the Registry (and where)? I included an Excel spreadsheet with my book...does this work for folks? Is the "compiled HTML" (ie, *.chm) Windows Help format easier to use?
If you can't think of a good format, maybe the way to start is this...what information would you put into something like this, and how would you format or organize it?
10 comments:
Ok I will start it off. My preference would be (I know this is a shock) in a database (sqlite, open source and very flexible for this type of thing and cross paltform as well) and Autoit for reporting and data entry. You could also use this to drive other formats if needed (XML, CSV, HTML, etc..).
Putting some thought and analysis you could also associate groups to different types of registry keys. For example if you associate the IE keys with the type "CP" and anything else you can think of that goes with "CP" then when you want to see the registry entires you should look at all you do is pick the group from a drop down box in autoit gui and it will displays all the keys you should look at. Now certain keys may have multiple groups and that is ok since you are using a database and that is what it was ment for.
Mark,
Thanks for the comment.
How would you suggest going about getting this set up? It does sound interesting...and I can see how the "CP" example applies.
My concerns about this project (and maybe you can suggest some ways to overcome these) are these:
1. How do you get someone to set up and maintain this? How is that handled? Is this something you (or others) would be willing to pay for to support?
2. What happens when there is an imaging viewing application installed that is not covered by the list of Registry keys in the database? The user clicks a button, doesn't see anything, and thinks that there isn't anything there...but there is an application with Registry entries in an MRU list of some kind...
Being a bit of a unix guy I prefer things to be command line based, and I prefer my configuration files to be text based.
I think I would like to see a text file or series of text files that describe what is in the various registry keys. I know that sounds silly at first, but I think it would be cool if the text file could also be used as the configuration file for a registry acquisition tool. That way if I wanted to read up on what is availabe in the registry, I can turn to my config file. If I want to gather just the user assist keys I could use a command like
utility -UserAssist >> output.txt
The -UserAssist option would direct the utility to point to an area of the file that is labelled UserAssist. One of the nice things about this is that it is simple and extensible. For example, at my organization we might be using an application called Foo.exe that adds a bunch of keys to the registry. It would be nice if I could edit my text file to include a section header for Foo and list out the keys that pertain to foo and then just run
utility -Foo >> output.txt
There is also no reason why a single registry key couldn't live under multiple headings. If I have a key that pertains to User Assit and Foo.exe, then I just list that key in each of the headings. Add comments liberally to document what the keys are doing and write up some good man pages.
Harlan and Kevin,
Lets see if I can hit both you your comments at the same time.
My suggestion for the database would be as the main repository. If we design the database properly we should be able to accomodate any manner of request to create a source file be in ini files, csv files, xml files or straight text files that can then be used by any program. Now adding to Kevins utility I would look at adding another flag to state what source you are using, DB, text files, etc.. to get the keys you want.
Now for the question on who will maintain this I do not see why we could not create a sourceforge project and have a list of maintainers that volunteer their time to do this, I would certainly be willing to lend my time to do this. Once the initial work is set up there should not be much work to keep maintaining it.
As for Harlans #2 point what happens today with something like this. I do not think we will ever get around this problem as long as some people are only willing to push buttons.
I think one of the greatest aspects of this is that we as a community (LE and Private) can come together on a project like this and come up with a pretty comprehensive list of keys to look at and groupings.
Now hopefully this all makes sense.
Mark
I think that this would be a very useful project. Being in LE, I don't have the budget to continually buy small tools to help along the way. In this regard, I think a Sourceforge project would be great.
What I've been currently doing is creating Summary Report files within AccessData's RV to automatically create reports from the registry depending on the case. I think creating a platform independent project would be much more useful - and I can make sure that I didn't miss something that someone else finds useful.
Good comments, all...I'll leave it up to you guys (in particular Mark) to see who wants to get the initial project defined and then set up on SourceForge...
All,
I will start and get the ball rolling and let everyone know when I have something and then will take volunteers and such. I will post on my blog and then tell Harlan at the same time so he can post as well.
Mark
i would also be up on helping in that i do manage and work in an ascld/lab-international digital lab for my law enforcement agency and could see this being really helpful.
hey harlan, this is jerryfrom charleston, sc pd..we have spoken a few times
Jerry,
Thanks for the comment.
What would you be willing to assist with specifically?
Thanks.
Since I have not received any comments from anyone about what I posted on my blog for the registry project I will post here maybe someone will have the email post on and take a look at it and give me some feedback. My post is here
Registry Repository. Either leave your feedback on my site, as a comment here (if harlan does not mind or send me an email mark dot mckinnon at sbcglobal dot net. Thanks
Post a Comment