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 cramp...no, 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 this...do 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 EventID.net. 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?
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 this...do 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 EventID.net. 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?