Wednesday, August 16, 2006

Where to start?

Ever have one of those days when you load up an image, check your notes...and simply have no clue where to begin? I'm not talking about your general brain, you simply have no idea where to start. Kind of like when someone hands you a drive and tells you to find "all the bad stuff". Oy.

Many times, simply looking into the file system may get you started...what applications are installed (based on the directory structure), what users are there and seem to be active, etc. However, this sort of meandering may only get you so far, and it you're on an hourly clock, it's also going to get you in hot water with the boss (be it your boss-boss, or your customer/boss).

So, what do you do? The approach I generally take is to try and narrow down the time window for the incident, either by interviewing the client, or reviewing their incident report. Look for things that within the report (or via the interview) that narrow down the time frame...when did you first notice something? Some folks have monitoring software on their network and/or systems that logs or emails them alerts...these generally have a time stamp of some kind. This is a good place to start, but one HUGE caveat is not think that this sort of thing is the cornerstone of your analysis. I have seen time and time again where something will happen that makes the client think they've been compromised, and once you start your analysis, you see clearly that the system had really been compromised much earlier, perhaps even multiple times.

I know a lot of folks who check the "usual suspects" when it comes to Registry keys, primarily looking for recently viewed documents and checking autostart locations. Also, running searches of the Registry and file system, using keywords derived from process names and application pop-ups is a good idea.

One thing that I've found to be a really good step to add to my methodology is to go into the Registry and sort the Services subkey in the appropriate ControlSet, based on the LastWrite times of the keys. Most of the keys will show times from when the OS was installed, but I've used this several times to successfully locate backdoors and even rootkits.

Another thing I like to do is use the File::ReadEvt Perl module to generate statistics about the Event Logs. The module ships with two scripts, one to get simple statistics, and another to simply output the event records to STDOUT. Over time, I will be posting additional scripts (based on what I've developed for various analysis tasks), and I will also be including them in my next book. Another thing that's very helpful with parsing and analyzing the contents of the Event Logs is a subscription to Besides things like logins, etc., another event you may want to look for is Dr. Watson...many times, this may be an indication of an exploit being run.

Gotchas - when working with times, a big GOTCHA is accounting for time zones. One thing that can throw you is how your analysis tool displays the times...ProDiscover gets the UTC/GMT times from Windows FILETIME objects, and displays them using the time zone settings of the analysis workstation. Many of the tools (Perl scripts, as well as ProScripts) I've written display times in UTC/GMT format. One of the things on my personal TO-DO list is to update tools that display times so that the ActiveTimeBias can be retrieved from the Registry and passed as an argument (in the case of ProScripts, retrieve this value automatically). Also, many text based logs (IIS, A/V tools, etc.) write times to ASCII text files using the current settings on the system, including the time zone settings. If I have an image of hard drive from, say, the Pacific Standard Time (PST) time zone, and I'm in EST, and some of my tools are displaying the times in UTC/GMT...while the times themselves are "accurate", they still need to be translated.

So what do you do when you're stuck? What are some tips you have for getting out of a rut when analyzing an image of a Windows system?


Dave Nardoni said...

It might be obvious to some, but I try and investigate some of the ways that information could leave the system. Such as Remote Desktop, VNC, ftp, ssh, etc. Many of these applications or services have logs or registry entries that can lead to additional evidence.

Anonymous said...


Great comment. Can you provide locations for those log files, for each of the applications you mentioned? I think that would be helpful to a lot of folks.


Geoff said...

I find that when I'm stuck on a forensic exam, the best thing for me to do is to shut EnCase down, open up sol.exe and mindlessly waste away for about 2 hours :)

But on a serious note... Ditto Dave's comments.
As far as a location for log files or registry entries - I can't remember until I'm sitting front of my forensic machine actually looking for that data. BUT - I would be very eager to help set up some sort of online database for forensic examiners that could point people in the right direction. It would be great if it were wiki-esque in nature so that any user could input new information.
Whaddya think?

Anonymous said...

I try to decompress or get my mind off of things for a bit if I'm stuck on an exam, as well. I do the same thing with reports (and I found it to be very effective in the military when I was writing personnel reviews)...write some stuff down, and then put it away and don't touch it for a day or two...and come back.

I think that the kind of resource you're referring to is already there...the ForensicWiki
. There can either be a section about log files, or as application specifics/artifacts are added, the location of the log files, and even how to interpret them can be addressed, as well.