You've probably noticed a huge gap between posts...sorry about that. Contrary to popular belief, I don't just sit around all day writing books. ;-) In addition to actually working, I like to think about ways to make my job easier, and to make the final product of my analysis better. Like many, I've known for sometime that considerable, valuable data exists in the Registry...there's a quite a bit there, whether you're looking for evidence of devices attached to the system, or of user activity. One of the things I've noticed is that there are a good number of tools available that allow you to do Registry data extraction...that is, pull data from the Registry, presenting the data found in a key or value. AccessData has their Registry Viewer, tools such as EnCase and ProDiscover allow you to visualize the Registry data...however, all of these are just tools, and each has their own strength and weakness.
One of the issues that confronts us today is knowing what we're looking at or looking for. Having a tool present data to us is nice, but if we don't know how that data is populated, then what good is the tool when some one-off condition is encountered? If the analyst does not understand how the artifact in question is created or modified, then what happens when the data that he or she expects to see is not present? Remember Jesse's First Law of Computer Forensics and my own subsequent corollary?
Why is this important? Well, for one, there's been a great deal of discussion about antiforensics lately, starting with a couple of articles in CIO and CSO magazines. "Antiforensics" and "counterforensics" (thanks to Richard for definitions) are not new concepts at all...the use of such activities has been around for quite some time. However, systems are becoming more and more complex, and at the same time, feature-rich. One of the benefits of Windows XP, for example, is that the feature-rich nature of the operating system goes some lengths in offsetting the inherent antiforensic features of the operating system.
So...let's try to come full circle...Registry analysis comes into play in assisting the investigator in determining what happened, and in many cases, when. Registry analysis can provide key or corroborating data. No tool out there will provide everything an investigator needs...it's up to the investigator to understand what's needed (ie, which Registry keys pertain to a particular P2P client, or which show the files most recently accessed with an image viewing utility?) and then understand how to get it. There are tools out there that do not have pretty GUIs and buttons you can push that will provide you with that information.
Saturday, September 15, 2007
Conference Presentations
I noticed from Anton's blog that the DFRWS 2007 papers were posted and available. I agree with Anton, a couple of the presentations are interesting. I was aware of Andreas's work with the Vista Event Log format, and transforming them into plain text...cool stuff.
Rich Murhpey had a paper entitled Automated Windows event log forensics, which I thought was interesting. In his paper, Rich points to "repairing" Event Log files that have been corrupted, using the method made available by Capt. Stephen Bunting. I can't say that I agree fully with this, as the Event Log files can be easily parsed directly from their binary format. Rich provides the beginnings of this in his paper, and more detailed information is available in my book. Rich also goes into extracting event records from unallocated space using Scalpel, but the file header he uses specifically targets the header and not event records in general (again, check out Windows Forensic Analysis for details on this). Extracting event records (and other objects that contain timestamp information, such as Registry keys) from unallocated space, the pagefile, or a RAM dump takes a bit more work, but it's definitely an achievable goal. Knowing the structure of these objects, we can locate the "magic number", perform some checking to ensure that we indeed have found a valid object, and then extract the information. Oh...wait...that's how the brute force EProcess parsing tools work on RAM dumps! ;-)
For those interested in time synchronization, check out A brief study of time...no, Stephen Hawking did not present this year - though, how cool would that be?! Not only is he one of the greatest minds of our time, but he's been portrayed on The Simpsons, and he's appeared in a quite funny excerpt from Star Trek:TNG! A complete set of media appearances can be seen here. For a brainiac, king-of-all-nerds kind of guy, he really rocks!
Going back to Rich's paper, the theme of DFRWS 2007 was "file carving", and the forensic challenge seems to have gone off fairly well. If you're at all interested in some of the cutting edge research in file carving, take a look at the challenge and results.
Rich Murhpey had a paper entitled Automated Windows event log forensics, which I thought was interesting. In his paper, Rich points to "repairing" Event Log files that have been corrupted, using the method made available by Capt. Stephen Bunting. I can't say that I agree fully with this, as the Event Log files can be easily parsed directly from their binary format. Rich provides the beginnings of this in his paper, and more detailed information is available in my book. Rich also goes into extracting event records from unallocated space using Scalpel, but the file header he uses specifically targets the header and not event records in general (again, check out Windows Forensic Analysis for details on this). Extracting event records (and other objects that contain timestamp information, such as Registry keys) from unallocated space, the pagefile, or a RAM dump takes a bit more work, but it's definitely an achievable goal. Knowing the structure of these objects, we can locate the "magic number", perform some checking to ensure that we indeed have found a valid object, and then extract the information. Oh...wait...that's how the brute force EProcess parsing tools work on RAM dumps! ;-)
For those interested in time synchronization, check out A brief study of time...no, Stephen Hawking did not present this year - though, how cool would that be?! Not only is he one of the greatest minds of our time, but he's been portrayed on The Simpsons, and he's appeared in a quite funny excerpt from Star Trek:TNG! A complete set of media appearances can be seen here. For a brainiac, king-of-all-nerds kind of guy, he really rocks!
Going back to Rich's paper, the theme of DFRWS 2007 was "file carving", and the forensic challenge seems to have gone off fairly well. If you're at all interested in some of the cutting edge research in file carving, take a look at the challenge and results.
Monday, September 03, 2007
More on (the) UserAssist keys
Didier Stevens has continued some of his excellent work regarding the UserAssist keys in the Registry. This morning, he posted an entry that explains part of the value names that appear when you decode (ie, un-ROT-13) the names. He has added the capability of providing an explanation to his UserAssist tool.
When you decode the value names from beneath the UserAssist\{GUID}\Count keys, you see that the value names begin with "UEME_" and include names like "RUNPIDL" and "RUNCPL", to name just a few. Since research into these Registry entries began, no one has really known or explored what these refer to...until now. Didier has done an excellent (say "excellent" the way Mr. Burns...more data on Wikipedia...does from "The Simpons", while tenting your fingers...) job of digging into what they mean, as well as providing that explanation via his tool.
If you get a chance, please be sure to thank Didier for his work, and if you see him at a conference, buy him a beer!
Addendum, 5 Sept: Rich over at ForensicZone.com has an interesting web page posted about extracting UserAssist key value names from memory dumps. This is a very interesting move on Rich's part...I've been looking at memory dumps and finding the "magic numbers" for Registry keys and values, but I have yet (due to time constraints) to go as far as writing code to pull out the key/value structures. The interesting thing about this (I think...being the complete nerd that I am) is that if we dump the contents of physical memory and then are capable of parsing out images used by each process as well as the memory used by each process, we can then (potentially) find Registry keys and values that we can associate with a specific process, but have yet to be written to disk! In addition, we know from the Registry key structure that the keys (albeit not the values) have a timestamp associated with them, increasing their evidentary value. Great catch, Rich! I hope you and Didier keep up the great work you've been doing!
Addendum, 7 Sept: Wow, when things get rolling, it's amazing! Didier and I have exchanged a couple of emails discussing various aspects of the UserAssist keys and some of the more esoteric settings that are out there, and according to some, have actually been used! Didier's a veritable fountain of energy and enthusiasm when it comes to researching this kind of thing, so keep an eye on his blog for more good things!
When you decode the value names from beneath the UserAssist\{GUID}\Count keys, you see that the value names begin with "UEME_" and include names like "RUNPIDL" and "RUNCPL", to name just a few. Since research into these Registry entries began, no one has really known or explored what these refer to...until now. Didier has done an excellent (say "excellent" the way Mr. Burns...more data on Wikipedia...does from "The Simpons", while tenting your fingers...) job of digging into what they mean, as well as providing that explanation via his tool.
If you get a chance, please be sure to thank Didier for his work, and if you see him at a conference, buy him a beer!
Addendum, 5 Sept: Rich over at ForensicZone.com has an interesting web page posted about extracting UserAssist key value names from memory dumps. This is a very interesting move on Rich's part...I've been looking at memory dumps and finding the "magic numbers" for Registry keys and values, but I have yet (due to time constraints) to go as far as writing code to pull out the key/value structures. The interesting thing about this (I think...being the complete nerd that I am) is that if we dump the contents of physical memory and then are capable of parsing out images used by each process as well as the memory used by each process, we can then (potentially) find Registry keys and values that we can associate with a specific process, but have yet to be written to disk! In addition, we know from the Registry key structure that the keys (albeit not the values) have a timestamp associated with them, increasing their evidentary value. Great catch, Rich! I hope you and Didier keep up the great work you've been doing!
Addendum, 7 Sept: Wow, when things get rolling, it's amazing! Didier and I have exchanged a couple of emails discussing various aspects of the UserAssist keys and some of the more esoteric settings that are out there, and according to some, have actually been used! Didier's a veritable fountain of energy and enthusiasm when it comes to researching this kind of thing, so keep an eye on his blog for more good things!
Subscribe to:
Posts (Atom)