Friday, May 21, 2010

Analysis Tips

I wanted to throw out a couple of things that I've run across...

MFT
I've worked a number of incidents where malware has been placed on a system and it's MAC times 'stomped', either through something similar to timestomp, or through copying the times from a legitimate file. In such cases, extracting $FILE_NAME attribute times for the file from the MFT have been essential for establishing accuracy in a timeline. Once this has been done, everything has fallen into place, including aligning the time with other data sources in the timeline (Scheduled Task log, Event Logs, etc.).

$LogFile
In a number of instances, this NTFS metadata file has been a gold mine. I worked on an exam last year where we thought that the intruder had figured out the admin password for a web-based CMS. I had a live image of the drive, and found the contents of the password file in $LogFile, which clearly demonstrated that the admin password was blank. BinText worked great for this.

$I30
This index file appears in directories when you're using FTK Imager, and in a number of instances, has been indispensable. During a recent exam where, due to lack of temporal proximity, I found the directory used by an intruder, but it was apparently empty. The $I30 file contained references to the artifacts in question.

Thoughts on Analysis
When working on an engagement...IR, forensic analysis, etc...we often loose site of what the term "analysis" means. We're supposed to be the experts, and the "customer" is relying on use to extract, review, and distill that extremely technical data into something that they can understand and use. Running through gigabytes of IIS logs and dumping out the entries that appear to indicate SQL injection and giving those to the customer from them to research and interpret is NOT analysis.

Let me break it down so you can put this on a t-shirt:

Run tool + dump output != analysis

Make sense?

2 comments:

Chris said...

Agreed. What does the data or output actually mean? You find a suspicious file or a suspicious folder in System32 and your tool shows that. Analysis of the data could show the user account that was used to create that, which could lead to the lapse of password controls, which could lead to a bigger user id administration issue. I find that its these bigger issues that we need to bring to our customers attention. Customers pay big bucks for incident response analysis. The output of the analysis should help our customers drive the changes their information security programs need to prevent or at least reduce the impact a future incident will have.

Ask the questions...what is the impact...how did it happen and most importantly, answer the questions your customers want answers to.

Chris Hague said...

Run tool + dump output = data extraction