More to the point, if you thoroughly document what you do, and your findings can be reproduced, why wouldn't they be able to be used in court?
I still believe that far too many folks are stuck on the question of "can it be used in court", without ever considering that there are plenty of things that at one point were not used in court, but are now commonplace…fingerprints, DNA, etc.
The difference is that rather than being frozen into inaction by the question, the folks who brought those types of evidence forward realized the value of the evidence, and applied rigor and structure to the analysis and the evidence so that the findings could be reproduced.
KeyDet for president \o/
The difference is that rather than being frozen into inaction by the question, the folks who brought those types of evidence forward realized the value of the evidence, and applied rigor and structure to the analysis and the evidence so that the findings could be reproduced.
And for those who don't know, Harlan was one of the leading voices along with folks like Rob Lee and others who led the community on this issue. When people like Harlan get an idea in their head and decide to advocate for it, it's a good thing for all of the rest of us. Harlan was the one who opened my eyes up to the possibilities relating to memory forensics.
I recently completed SANS SEC508 OnDemand with Rob Lee. Rob mentioned something that really has stuck with me that I'd like to share. He made a very important point about how in most circumstances, it's not a matter of if your response is going to change the evidence, but how it's going to change it.
Think about it. Rob points out that the old school method was to just pull the plug to preserve the evidence on the hard disk, but that also destroys all of the really good data in memory. These days, that means we're talking about gigabytes of data lost by pulling that plug. In light of that, is it really so awful changing some of the data on a disk by doing something like using FTK Imager Lite to image to a USB device that you installed in a machine or to a network share somewhere?
I think it might have been Ovie Carroll (someone correct me if I'm getting the attribution wrong on this) who pondered whether some attorney someday will make the case that by not preserving memory a mistake was made in the evidence collection process.
I've used ForensicUserInfo from http//
I recently completed SANS SEC508 OnDemand with Rob Lee. Rob mentioned something that really has stuck with me that I'd like to share. He made a very important point about how in most circumstances, it's not a matter of if your response is going to change the evidence, but how it's going to change it.
Excellent point.
Also, keep in mind that a responder's inaction can be as detrimental to response as their actions, even misguided ones (ie, running AV, deleting files, etc.). A great deal occurs on a system when you do nothing more than just watch it…processes complete executing, network connections change state/terminate, and in general, volatile data decays.
On Windows XP in particular, every 24 hrs, a System Restore Point is created, and if appropriate, one or more may be deleted. Every three days, a limited defrag of the disk is run. Both of these are documented behaviors…documented by MS.
Rob's dead on point…responders need to understand what effect their actions will have on systems.
I think it might have been Ovie Carroll (someone correct me if I'm getting the attribution wrong on this) who pondered whether some attorney someday will make the case that by not preserving memory a mistake was made in the evidence collection process.
I'd think that this would occur sooner rather than later.
Thanks- sounds like the typical CYA documentation and testing- not much different in the US )
00AC refers to the offset (172 decimal). I can't remember if Access Data Registry Viewer shows offsets in decimal or hex, but either way, if you have the V key open and get to the offset mentioned, the value 14 indicates that a password is present.
I did some research on this. Offset 172 seems accurate most of the time. I found an an XP Administrator account that had an offset of 14 but in fact the password was blank (likely had a password at one time). For me, PRTK or ophcrack that are capable of showing the NT Password field (either as blank or recovered / failed) as well as ForensicUserInfo have been accurate every time thus far on 3 different cases (confirming with LiveView).