Wednesday, February 23, 2011

Time Stomping is for Suckers

OK...So I have been seeing this more lately, so I feel like it's time to post about it again.

Chronological data about the files on a Windows system are stored in something called the Master File Table or $MFT. This is the place that the operating system and various GUI utilities (Insert Forensic GUI Utility of choice) pulls timeline, or MACB times. As a refresher, MACB stands for:

M - Modified
A - Accessed
C - Created
B - Birth

Now...there are two places in the MFT that store this chronological data. One is the $Standard_Information ($S_I) attribute, and the other is the $File_Name ($F_N) attribute. So now you are asking yourself, why are there two places that store this data, and why do I care...well...I will tell you...

The data is stored in two different places because they are accessed by two different parts of the system (loosely). The $S_I is accessed by the OS, various applications, and the user. So, it is able to be modified or stomped. THEREBY " fooling ANY and ALL forensic utilities. ALL OF THEM...since they all pull the chronological data from the $S_I. So, if a file has been modified, and you sort in your little GUI column sorter, the malicious file(s) that has (have) been stomped will be sort in like 2008, 1969, or whatever date the attacker decided to give it.

Sucks to be you right? Wrong! Sucks to be a crappy tool...not a smart investigator!

Here is why...

While the $S_I attribute is able to be modified by the OS and stuff, the $F_N attribute is not. So what does that mean? It means you can use this hand-dandy little perl script called, ""from none other than the illustrious Harlan Carvey to parse the MFT and just pull out the $S_I and $F_N attributes (Which incidentally, Harlan was nice enough to post on Google Code...THANK YOU HARLAN). Then, when you compare the two values, you can see right away if the MACB times have been modified!

Here is the syntax to use

C:\tools>Perl $MFT_from_suspect_system > ripped_mft.txt

Now if you cat or strings that file, it will look like a bunch of nonsense, so here is what I suggest:

C:\tools> strings ripped_mft.txt | grep -A 6 -B 6 -i filename_you_are_looking_for

This will give you the six (6) lines both before and after the hit in the MFT. The MACB times on the top are from the $S_I attribute, while the ones on the bottom (as indicated by the little "FN" are from the $F_N attribute.

So, if the top does not match the bottom, you have a file that has had its MACB times modified by something. Then you can indicate that, and show that the times on the bottom are the correct ones. Use those in your case timelines.

So you see, Time Stomping is for suckers! You can fool a tool, but you CAN'T fool an investigator.

Well...I guess technically you CAN, but it would have to be an investigator who is relying on the tool to solve his case for him and not his brain. In which case, I would refer to that person as more of a click monkey than an actual Investigator...but I digress...

Happy Hunting!

Named Top 25 Blog!

I was just informed that TheDigitalStandard was named one of the top 25 Forensics blogs! Nice!

This distinction comes from

Thank you! Notice a couple of other names in the computer forensics world? Namely Harlan and Grayson...great work fellas!

Monday, February 21, 2011

Thursday, February 17, 2011

Dumpy Goodness

OK...I know the title sounds a bit wonky, but I really think a lot of you are going to find this post interesting and useful. my quest to be ever more efficient in my volatile data acquisition I stumbled upon (thanks to Harlan and Troy) a tool that is resident to Windows systems that has proved to be extremely helpful. It's called reg.exe, and it's pretty freaking sweet.

Normally, when extracting volatile data from a Windows system, I would dump RAM, run my volatile collection script, then fire up FTK Imager (usually in conjunction with F-Response if against a live system) and manually extract the registry hives and ntuser.dat files. I thought this was pretty efficient, but it always bothered me that I could not script the process. I mean, how quick and easy would it be if my data collection script dumped RAM, gather volatile data, extracted the registry hives and ntuser.dat files, AND...for good measure...ripped them for me with RegRipper!

That would not only save me time, but it'd be freaking I set my mind to figuring this problem out. After a couple of days of poking around and trial and error, I got it to work! So, here's how...

reg.exe is resident to all Windows releases that I have in my lab (2000, XP, 7, Vista, Server 2003, and Server 2008), but just to be safe, I copied it from my lab XP system to the same directory with all of my tools. Then, when I scripted it into my batch file, it looks like this...

@ECHO Dumping Registry Hives
@ECHO Dumping SAM Hive
@reg save HKLM\SAM %DST%\%NAME%\vol\%NAME%_SAM_Hive
@md5deep.exe -b %DST%\%NAME%\vol\%NAME%_SAM_Hive > %DST%\%NAME%\vol\%NAME%_SAM_Hive.md5

@ECHO Dumping SYSTEM Hive
@reg save HKLM\SYSTEM %DST%\%NAME%\vol\%NAME%_SYSTEM_Hive
@md5deep.exe -b %DST%\%NAME%\vol\%NAME%_SYSTEM_Hive > %DST%\%NAME%\vol\%NAME%_SYSTEM_Hive.md5

@md5deep.exe -b %DST%\%NAME%\vol\%NAME%_SECURITY_Hive > %DST%\%NAME%\vol\%NAME%_SECURITY_Hive.md5

@md5deep.exe -b %DST%\%NAME%\vol\%NAME%_SOFTWARE_Hive > %DST%\%NAME%\vol\%NAME%_SOFTWARE_Hive.md5


@ECHO Ripping SAM Hive
@rip.exe -r %DST%\%NAME%\vol\%NAME%_SAM_Hive -f sam > %DST%\%NAME%\vol\%NAME%_SAM_Hive_ripped.txt

@ECHO Ripping SYSTEM Hive
@rip.exe -r %DST%\%NAME%\vol\%NAME%_SYSTEM_Hive -f system > %DST%\%NAME%\vol\%NAME%_SYSTEM_Hive_ripped.txt

@ECHO Ripping Software Hive
@rip.exe -r %DST%\%NAME%\vol\%NAME%_SOFTWARE_Hive -f sam > %DST%\%NAME%\vol\%NAME%_SOFTWARE_Hive_ripped.txt

@rip.exe -r %DST%\%NAME%\vol\%NAME%_SECURITY_Hive -f sam > %DST%\%NAME%\vol\%NAME%_SECURITY_Hive_ripped.txt

Nice huh! So now, you can add this little snippet to your own volatile collection script. For more on reg.exe, you can also just run, "reg /?"...

C:\tools>reg /?

Console Registry Tool for Windows - version 3.0
Copyright (C) Microsoft Corp. 1981-2001. All rights reserved

REG Operation [Parameter List]

Operation [ QUERY | ADD | DELETE | COPY |

Return Code: (Except of REG COMPARE)

0 - Succussful
1 - Failed

For help on a specific operation type:

REG Operation /?



As you can see from my script, I used reg save...

C:\tools>reg save /?

Console Registry Tool for Windows - version 3.0
Copyright (C) Microsoft Corp. 1981-2001. All rights reserved

REG SAVE KeyName FileName

KeyName ROOTKEY\SubKey
SubKey The full name of a registry key under the selected ROOTKEY
FileName The name of the disk file to save. If no path is specified, the
file is created in the current folder of the calling process


REG SAVE HKLM\Software\MyCo\MyApp
Saves the hive MyApp to the file in the current folder

***Remember...I am running this against a LIVE system! As far as I know, without either using reg.exe or something like FTK Imager, you cannot access the registry hives from a live system.***

Now, you would pretty much repeat the same process for ntuser.dat files, only instead of entering the hive information, you would use HKU (instead of HKLM) followed by a backslash and the SID of the specific user. Here is what the syntax looks like for the admin account on my XP box...

c:\tools>reg save hku\S-1-5-21-746137067-1547161642-839522115-500 outputfile.dat

Now, this may be "old new" to some of you, but I will tell you that for me...and I have been doing this for about seven years now...I had not heard of or used reg.exe until this week. AND, I have never seen it scripted before as part of a volatile collection script. It's not to say that it hasn't been done already, just that I have not seen it., you can easily write a batch file that will dump RAM, grab volatile data, copy the registry hives and parse them, and copy ntuser.dat files and parse them. Total time saver!


Happy Hunting!

Monday, February 14, 2011

Windows Registry Forensics Released!

I received my copy of Harlan Carvey's, "Windows Registry Forensics" over the weekend and I am really excited to start reading it!

The registry is a GOLD MINE of forensic artifacts that can really put some teeth in your investigations. If you do not have this book yet, BUY IT!!! Harlan has not disappointed yet with any of his published works, and I don't expect this will be any different.

Look for a book review from me in the coming weeks. But seriously, if you are doing forensic investigations on Windows systems, and you don't yet have a copy of this book, you are really missing something. You have NO IDEA how useful this information can be!