Wednesday, November 21, 2007

Alternative Methods of Analysis

Do I need to say it again? The age of Nintendo Forensics is gone, long past.

Acquiring a system is no longer as simple as removing the hard drive, hooking it up to a write blocker, and imaging it. Storage capacity is increasing, devices capable of storing data are diversifying and becoming more numerous (along with the data formats)...all of which are becoming more ubiquitous and common-place. As the sophistication and complexity of devices and operating systems increases, the solution to the issue of backlogs due to examinations requiring additional resources is training and education.

Training and education lead to greater subject-matter knowledge, allowing the investigator to ask better questions, and perhaps even make better requests for assistance. Having a better understanding of what is available to you and where to go to look leads to better data collection, and more thorough and efficient examinations. It also leads to solutions that might not be readily apparent to those that follow the "point and click execution" methodology.

Take this article from Police Chief Magazine, for example. 1stSgt Cohen goes so far as to specifically mention the collection of volatile data and the contents of RAM. IMHO, this is a HUGE step in the right direction. In this instance, a law enforcement officer is publicly recognizing the importance of volatile data in an investigation.

It's also clear from the article that training and education has led to the use of a "computer forensics field triage", which simply exemplifies the need for growth in this area. It's also clear from the article that a partnership between law enforcement, the NW3C and Purdue University has benefited all parties. It would appear that at some point in the game, the LEs were able to identify what they needed, and were able to request the necessary assistance from Purdue and NW3C...something known in consulting circles as "requirements analysis". At some point, the cops understood the importance of volatile memory, and thought, "we need this...now, how do we collect it in the proper manner?"

So what does this have to do with alternative methods of analysis? An increase in knowledge allows you to seek out alternative methods for your investigation.

For example, take the Trojan Defense. The "purist" approach to computer forensics...remove the hard drive from the system, acquire an image, and look for files...appears to have been less than successful, in at least one case in 2003. The effect of this decision may have set the stage for other similar decisions. So, let's say you've examined the image, searched for files, even mounted the image as a file system and hit it with multiple AV, anti-spyware, and hash-comparison, and still haven't found anything. Then lets assume you had collected volatile data...active process list, network connections, port-to-process mapping, etc. Parsing that data, wouldn't the case have been a bit more iron-clad? You'd be able to show that at the time the system was acquired, here are the processes that were running (along with their command line options, etc.), installed modules, network connections, etc.

At that point, the argument may have been that the Trojan included a rootkit component that was memory-resident and never wrote to the disk. Okay, so let's say that instead of running individual comments to collect specific elements of memory (or, better yet, before doing that...), you'd grabbed the contents of RAM? Tools for parsing the contents of RAM do not need to employ the MS API to do so, and can even locate an exited or unlinked process, and then extract the executable image file for that process from the RAM dump.

What if the issue had occurred in an environment with traffic monitoring...firewall, IDS and IPS logs may have come into play, not to mention traffic captures gathered by an alert admin or a highly-trained IR team? Then you'd have even more data to correlate...filter the network traffic based on the IP address of the system, isolate that traffic, etc.

The more you know about something, the better. The more you know about your car, for example, the better you are able to describe the issue to a mechanic. With even more knowledge, you may even be able to diagnose the issue and be able to provide something more descriptive than "it doesn't work". The same thing applies to IR, as well as to forensic analysis...greater knowledge leads to better response and collection, which leads to more thorough and efficient analysis.

So how do we get there? Well, someone figured it out, and joined forces with Purdue and NW3C. Another way to do this is through online collaboration, forums, etc.

8 comments:

Anonymous said...

I agree that live acquisition can be essential in some cases, but it's not going to happen in the vast majority of LE investigations. The philosophy envisions a trained examiner being on the scene of every search in which a computer may be running.

The hypothetical Q&A in the article simply brings home what happens during every moderately astute cross examination. It's exaggerated. You can't prove a negative conclusively in most instances. You and I could easily construct some similar Q&As to attack an examiner who did a proper live acquisition:

Defense Attorney: So, when you ran your live acquisition tool, you overwrote some memory that contained another person's confession.

The article has merit, but is idealistic in today's world. Tomorrow, it may be realistic.

Using best practices best defends the trojan defense. Still, what do you say when asked whether a root kit might have existed at one time? All the "possibility" questions may not achieve their advocate's intent if he or she doesn't present some proof that Bug X existed. I've been there, and a competent trial attorney will recap the case and emphasize testimony and fact over speculation. You may recall a recent post on a well respected forum that failed to produce any findings of any malware ever having downloaded child pornography to a system. The problem, however, is what would you say, if I asked you whether it is possible?

As you said, "greater knowledge" is the key. Your blog, help, and writings advance that goal.

H. Carvey said...

Jimmy,

Thanks. I agree that collecting volatile data isn't always possible or practical...even in the non-LEO world. There are many times when the system has been taken offline, scanned, rebooted (several times), etc. Live acquisitions turn out to be more common for me, it seems...the system cannot be taken down, there is no write-blocker for the hard drives, etc.

I've always had an issue with arguments that included "a competent defense attorney would tear that apart"...largely b/c a competent prosecutor would ensure that the case did not hinge on a single piece of "evidence".

Your blog, help, and writings advance that goal.

Any thoughts on how to improve any of those would be greatly appreciated.

Anonymous said...

Any thoughts on how to improve any of those would be greatly appreciated.

I think that a paper or guide on event logs would help many of us, who may not routinely review this data. Something like your registry spreadsheet comes to mind, if there can be a straightforward reference. Vista, of course, expands the value of these logs, so they may be more important than before.

H. Carvey said...

Jimmy,

I think that a paper or guide on event logs would help many of us...

What suggestions would you have toward modifying or updating the material in my book?

Anonymous said...

I haven't had a chance to check out the web sites you cited as references on event IDs, but that's largely what I had in mind. (I didn't want to ignore your question.) A reference on activities/events that are logged may be more important. That may be overly broad, but I'd guess that many folks are unaware of the value of logs because they don't know what can be found. Event logs may not be essential to many cases that LE typically work, but perhaps their value is under estimated. Most training programs only touch upon logs superficially.

H. Carvey said...

A reference on activities/events that are logged may be more important. That may be overly broad, but I'd guess that many folks are unaware of the value of logs because they don't know what can be found.

It all comes back to knowledge, and a willingness to develop and learn.

Event logs may not be essential to many cases that LE typically work, but perhaps their value is under estimated (sic).

I think that in many cases, the Event Logs are simply not considered as a source of valuable information, and b/c they aren't examined or analyzed regularly, most likely consider it too time consuming an endeavor anyway.

Most training programs only touch upon logs superficially.

That's unfortunate. I did some work not to long ago, and the only source of data to answer a question was the Event Logs.

Event Log analysis goes, at least in part, hand-in-hand with Registry analysis. The Security Registry hive file will tell you what the audit policy was on the system, as well as when it was modified. The System hive file will give you info regarding the size and retention of the Event Log files.

Because Event Log analysis isn't being performed regularly now, it is likely that the potential value of the Vista Event Logs will be lost entirely.

Anonymous said...

I agree. However, many of us are willing to learn, but depend on others to provide resources. "Log File Forensics." A book? A four-hour course? An entire program could revolve around Vista log analysis.

The logs can be a valuable source of information, but I don't think that, most likely consider it too time consuming an endeavor. I do think that many don't realize the value of the logs, because, in part, there hasn't been a effort to develop some training in this aspect of forensics. Those of us who focus on image analysis of single machines may need some examples of what the logs can provide.

I have checked out EventID.net and found it very helpful. At least there's a source to explain the events in a friendly format. Recognizing which events warrant study is the key.

H. Carvey said...

However, many of us are willing to learn, but depend on others to provide resources.

I can completely understand that, Jimmy, but I have to admit, I don't see a great deal of questions along these lines. I monitor a couple of lists and forums, and accept direct emails, and I don't see much in the way of questions about Event Logs. In fact, I haven't seen any.

...there hasn't been a effort to develop some training in this aspect of forensics.

Puh-lease don't say that it's a case of "someone didn't tell us this was important"! ;-)

But seriously...who would sign up for the training. One of the biggest issues I've seen is that while I've got the material and would be more than happy to provide the training, it is extremely difficult to break even, revenue-wise.

However, I do see the direction you're going. The biggest issue is that for someone to provide that kind of material...descriptions of what the Event Log (Win2K3 and Vista) can provide...it's going to require some considerable resources.