Links

File Initialization
Eoghan had an excellent post on issues/pitfalls of file initialization, particularly on Windows systems. After reading through this post, I can think of a number of exams I've done in the past where I wish I could link to this post in the report. In one particular instance, while performing data breach exams, I've found sensitive data "in" Registry hive files, and a closer look showed me that the search hits were actually in either the file slack or the uninitialized space within the file. During another exam, I was looking for indications of how an intruder ended up being able to log into a system via RDP. I ran my timeline tools across the Event Log (.evt) files extracted from the image, and found that I had RDP logins (event ID 528, type 10) in my timeline that fell outside of the date range (via evtrpt.pl) of the Security Event Log. Taking a closer look, I found that while the Event Logs had been cleared and one of the .evt file headers (and Event Viewer) reported that there were NO event records in the file, I found that the uninitialized portion of the file was comprised of data from previously used sectors...which included entire event records!

More than anything else, this concept of uninitialized space really reinforces to me how process and procedures are important, and how knowledgeable analysts really need to be. After all, say you have a list of keywords you're searching for, or a regex you're grep'ing for...when you get a hit, it is really in the file?

Unexpected Events
I ran across a link to Lenny Zeltser's site recently that pointed to a presentation entitled, How To Respond To An Unexpected Security Event. I'll have to put my thoughts on Lenny's presentation in another post, but for the most part, I think that the presentation has some very valid points that may often to unrecognized. More about that later, though.

Regtime
Following a recent SANS blog post (Digital Forensic SIFTing: SUPER Timeline Analysis and Creation), I received a couple of requests to release regtime.pl. This functionality was part of RegRipper before regtime.pl was included in SIFT. You can see this if you use rip.pl to list the plugins in .csv format, but instead of sending them to a file, pipe the output through the "find" command:

C:\Perl\forensics\rr>rip.pl -l -c | find "regtime" /i
regtime,20080324,All,Dumps entire hive - all keys sorted by LastWrite time

If you need the output to be in a different format, well, it's Perl and open source!

Timeline Creation
Chris has posted part 2 of his Timeline Analysis posts (part 1 is here), this time including Registry data by running regtime.pl from the SANS SIFT Toolkit v2.0 against the Registry hives. It's really good to see more folks bringing this topic up and mentioning it in blogs, etc. I hesitate to say "discussion" because I'm not really seeing much discussion of this topic in the public arena, although I have heard that there's been some discussion offline.

Looking at this, and based on some requests I've received recently, if you're looking for a copy of regtime.pl, you'll need to contact Rob about that. I did provide a copy of regtime.pl for him to use, but based on the output I saw in Chris's post, there appear to have been modifications to the script I provided. So if you're interested in a copy of that script, reach out to Rob.

Also, one other thought...I'm not a big proponent for adding information from the Registry in this manner. Now, I'm not saying its wrong...I'm just saying that this isn't how I would go about doing it. The reason for that is that there's just way too much noise being added to the timeline for my taste...that's too much extra stuff that I need to wade through. This is why I'll use RegRipper and the Timeline Entry GUI (described here) to enter specific entries into the timeline. By "specific entries", I mean those from the UserAssist and RecentDocs keys, as well as any MRU list keys. My rationale for this is that I don't want to see all of the Registry key LastWrite times because (a) too many of the entries in the timeline will simply be irrelevant and unnecessary, and (b) too many of the entries will be without any context whatsoever.

More often, I find that the really valuable information is what occurred to cause the change to the key's LastWrite time, and in many cases, that has to do with a Registry value, such as one being added or removed. In other cases, the truly valuable data can come from the binary contents of a Registry value, such as those within the UserAssist\Count subkeys.

Again, I'm not saying that there's anything wrong with adding Registry data to a timeline in this manner; rather, I'm just sharing my own experiences, those being that more valuable data can be found in a more tactical approach to creating a timeline.

AfterTime
I received an email recently from the folks at NFILabs, out of the Netherlands, regarding a tool called AfterTime, which is a Java-based timeline tool based on Snorkel. This looks like a very interesting tool, with evaluation versions running on both Windows and Linux. Based on some of the screenshots from the NFILabs site regarding AfterTime, it looks like each event has a number of values that relate to that event and can provide the examiner with some context to that event.

AfterTime also uses color-coded graphics to show the numbers and types of events based on the date. I've said in the past that one of the problems with this approach (i.e., illustrating abundance) is that most times, an intrusion or malware incident will be the least frequency of occurrence (shoutz to Pete Silberman of Mandiant) on a system. As such, I'm not entirely sure that a graphical approach to analysis is necessarily the way to go, but this is definitely something worth looking at.