Forensic Analysis Process/Procedures
I've seen posts recently on some of the lists regarding processing forensic data...in most cases, the original question seems to center around, what is (are) the first thing(s) you do with your forensic data?
I thought I'd approach a response from a couple of different perspectives...
Goals
The VERY first thing I start with, regardless of what type of work I'm doing...IR, data collection, CSIRP development, forensic analysis...whatever...are the customer goals. Always. Every time.
Customer goals are documented early on in the engagement, most often from the very first call. They're also revisited throughout the engagement, to ensure that the on-site responder or the analyst is on track, and also ensure that the customer's expectations for the engagement are managed properly. It's a pretty bad feeling to have no communication with the customer, and deliver a report, only to have them say, "...uh...I thought you were going to do X..."
The thing about customer goals is that I can go on-site and back up a Ryder rental truck and acquire images of 300 or 500 systems...but for what? At what expense? If the customer needs an immediate answer, by telling them, "hold on...I've gotta image all of these systems first...", I've already done my customer a huge disservice. The customer's goals dictate everything about the engagement...how many responders are sent on-site, which ones, which analysts will be engaged, how long the engagement will take, etc.
Another thing about goals is that an analyst can easily consume 40 to 80 hours just analyzing an acquired image, and never answer the questions that the customer asked. Not only does the analyst need to be sure to keep the customer's goals in the forefront of their minds, but they also need to ensure that the goals are clear, understandable, and achievable. One popular issue is the customer who ask the analyst to, "...find everything suspicious...", and the analyst takes that and starts analysis...without ever determining what constitutes "suspicious". I've analyzed systems used by pen testers, and systems used by administrators...for these systems, the existence of tools like MetaSploit, pskill, psexec, etc., wouldn't necessarily be "suspicious". What if you find password cracking tools on a system, and spend considerable time determining and reporting on their use...only to find out that the user was an admin whose job it was to test password strength?
Makin'
Copies
Pretty much the first thing I do once I have my images in the lab is make working copies and secure the originals. This is a basic step, I know...but for me, all I need to happen is to get caught once with going on-site and then not being able to access my data. I'm one of those guys that tries to learn from the mistakes of others, rather than my own. I'm not always quite as successful as I'd like to be, but I was almost caught by this once, so I learned my lesson. I had just copied and verified an image from a USB external wallet drive, and began working on the copy. After a day of processing, I went to get a file off the USB ext HDD, and Windows asked me if I wanted to format the drive. For some reason, something had happened to the drive...I have no idea what it was. The point was, however, that I had made my working copy...I had copied the image file, verified the file system, and used Jesse's md5deep to ensure that the image file had completely and correctly copied.
Documentation
Before addressing the actual analysis of an acquired image (or any other data), I make sure that my documentation is in order. At this point in my case management, this usually means that I've started my case notes...the first thing at the very top of my case notes is usually the customer goals. This helps me focus my analysis efforts...I usually even outline an analysis plan to get myself started at this point.
Documentation is a consistent aspect of engagements, beginning to end. Documentation keeps me on track, and also allows me to pass off the work to someone else in case of an emergency, without having them start over completely. It also allows an analyst to pick up a case 6 months or a year later and see how things went...particularly if they need to go to court. Documentation should be clear, concise, and maintained in a thorough enough manner that the analysis is repeatable and can be verified by another analyst.
Analysis
After all that, the very first thing I like to do before doing any actual analysis is to extract specific files from the image...Registry hives, Event Logs, etc...and to look for specific items (i.e., AV logs, MRT logs, etc.). Depending upon the goals of my analysis, I may even run TSK's fls.exe to generate a bodyfile, ultimately for inclusion into a timeline for analysis.
I tend to do this sort of thing if I have something that may take a while...AV scans of a mounted image, keyword searches, etc...because I don't want to go back to the customer and say, "sorry it took so long, but I was running a scan and couldn't do anything else." To me, that's simply unprofessional...analysts are hired as "experts" or at least relied upon as professionals, and should conduct themselves as such. That, in part, means doing analysis tasks in a parallel, rather than serial, fashion should simply be part of what we do. So, if I have a process that I need to run that's going to take some time, I'll extract pertinent files first so that I can continue with my analysis with the other task is running.
Of course, this all ties directly back to the goals of the engagement. In fact, depending upon the goals, I may make two working copies of the image file...one to work on while the other is being scanned. Or, I may not even run AV scans...I've found the malware that the customer described without having to run any scans.
So...what are your first steps?
I thought I'd approach a response from a couple of different perspectives...
Goals
The VERY first thing I start with, regardless of what type of work I'm doing...IR, data collection, CSIRP development, forensic analysis...whatever...are the customer goals. Always. Every time.
Customer goals are documented early on in the engagement, most often from the very first call. They're also revisited throughout the engagement, to ensure that the on-site responder or the analyst is on track, and also ensure that the customer's expectations for the engagement are managed properly. It's a pretty bad feeling to have no communication with the customer, and deliver a report, only to have them say, "...uh...I thought you were going to do X..."
The thing about customer goals is that I can go on-site and back up a Ryder rental truck and acquire images of 300 or 500 systems...but for what? At what expense? If the customer needs an immediate answer, by telling them, "hold on...I've gotta image all of these systems first...", I've already done my customer a huge disservice. The customer's goals dictate everything about the engagement...how many responders are sent on-site, which ones, which analysts will be engaged, how long the engagement will take, etc.
Another thing about goals is that an analyst can easily consume 40 to 80 hours just analyzing an acquired image, and never answer the questions that the customer asked. Not only does the analyst need to be sure to keep the customer's goals in the forefront of their minds, but they also need to ensure that the goals are clear, understandable, and achievable. One popular issue is the customer who ask the analyst to, "...find everything suspicious...", and the analyst takes that and starts analysis...without ever determining what constitutes "suspicious". I've analyzed systems used by pen testers, and systems used by administrators...for these systems, the existence of tools like MetaSploit, pskill, psexec, etc., wouldn't necessarily be "suspicious". What if you find password cracking tools on a system, and spend considerable time determining and reporting on their use...only to find out that the user was an admin whose job it was to test password strength?
Makin'
CopiesPretty much the first thing I do once I have my images in the lab is make working copies and secure the originals. This is a basic step, I know...but for me, all I need to happen is to get caught once with going on-site and then not being able to access my data. I'm one of those guys that tries to learn from the mistakes of others, rather than my own. I'm not always quite as successful as I'd like to be, but I was almost caught by this once, so I learned my lesson. I had just copied and verified an image from a USB external wallet drive, and began working on the copy. After a day of processing, I went to get a file off the USB ext HDD, and Windows asked me if I wanted to format the drive. For some reason, something had happened to the drive...I have no idea what it was. The point was, however, that I had made my working copy...I had copied the image file, verified the file system, and used Jesse's md5deep to ensure that the image file had completely and correctly copied.
Documentation
Before addressing the actual analysis of an acquired image (or any other data), I make sure that my documentation is in order. At this point in my case management, this usually means that I've started my case notes...the first thing at the very top of my case notes is usually the customer goals. This helps me focus my analysis efforts...I usually even outline an analysis plan to get myself started at this point.
Documentation is a consistent aspect of engagements, beginning to end. Documentation keeps me on track, and also allows me to pass off the work to someone else in case of an emergency, without having them start over completely. It also allows an analyst to pick up a case 6 months or a year later and see how things went...particularly if they need to go to court. Documentation should be clear, concise, and maintained in a thorough enough manner that the analysis is repeatable and can be verified by another analyst.
Analysis
After all that, the very first thing I like to do before doing any actual analysis is to extract specific files from the image...Registry hives, Event Logs, etc...and to look for specific items (i.e., AV logs, MRT logs, etc.). Depending upon the goals of my analysis, I may even run TSK's fls.exe to generate a bodyfile, ultimately for inclusion into a timeline for analysis.
I tend to do this sort of thing if I have something that may take a while...AV scans of a mounted image, keyword searches, etc...because I don't want to go back to the customer and say, "sorry it took so long, but I was running a scan and couldn't do anything else." To me, that's simply unprofessional...analysts are hired as "experts" or at least relied upon as professionals, and should conduct themselves as such. That, in part, means doing analysis tasks in a parallel, rather than serial, fashion should simply be part of what we do. So, if I have a process that I need to run that's going to take some time, I'll extract pertinent files first so that I can continue with my analysis with the other task is running.
Of course, this all ties directly back to the goals of the engagement. In fact, depending upon the goals, I may make two working copies of the image file...one to work on while the other is being scanned. Or, I may not even run AV scans...I've found the malware that the customer described without having to run any scans.
So...what are your first steps?
