Saturday, June 20, 2009

Live Analysis Part I - Changing of the Guard

There has been a drastic paradigm shift in the forensic community that folks like myself, Harlan Carvey, Jibran Ilyas, Colin Sheppard, Cory Altheide, and Don Weber have been a major catalyst for. The days of "image everything" and letting tools like EnCase and Gargoyle sort them out are gone. If you expect to remain relevant in the forensic community, and have an impact on the industry, you NEED to know how to perform live analysis.

The first thing we need to look at is the benefit of analyzing a live system. You are dealing with the compromised system! You may never get a chance to lay your hands on that keyboard again and there is a wealth of information that can be learned from real time analysis. I will cover some of the tools I use and why, but there is a major point which needs to be understood before we proceed. I know how all of the tools I use interact with the several Windows platforms (2000, XP, 2003, 2008, and Vista). I have tested them and know what kind of fingerprint they are going to leave. MAKE SURE you do the same for any tools you use, and document what you are doing, when, and why. This will allow you to identify any "tracks" you make on the system should a forensic image be later required, for data reduction purposes.

As you look at a live system, you need to have something in mind that you are looking for...ie...go in with a plan. Simply looking at a system and "trying to find bad guy stuff" is both unrealistic and illogical. As malware (simply defined as any program used for malicious intent) has become more advanced, its presence has become less obvious. You WILL NOT see processes called "hacked.exe", "P0wn3ed", or "slkjdhfbc.exe" - you WILL see processes called, "lsass.exe", "svchost.exe", and "winlogon.exe". The later are processes you would normally see on a typical Windows system, and would likely not draw any suspicion from an admin or your "average" investigator. This is why you need to go in with a plan.

The most successful model I have used (an still use) is the Alexiou Principle (named after it's creator Mike Alexiou). It asks the following questions:

1. What question are you trying answer?
2. What data do you need to answer that question?
3. How do you extract that data?
4. What does that data tell you?

By employing the Alexiou principle, you can sit in front of a live system with a goal in mind instead of just "willy nilly" tromping all over your suspect system.

In the next post, we will cover some live response tools, what the output looks like, and what that output means.

4 comments:

  1. Welcome to the 'blogging geeks' club :-)

    ReplyDelete
  2. Chris,

    Great post, thanks for sharing your thoughts. I would like to request a follow up posting. In this post you mentioned that you test all of your tools and know what kind of fingerprint they are going to leave.

    It would be really helpful if maybe you could share your testing methodology and what tools or methods you use to track what changes are made to OS by a particular tool.

    Thanks,

    Jim

    ReplyDelete
  3. Jim...more to come in this series, so stay tuned!

    ReplyDelete
  4. Chris- I agree with you. Collecign timages just to collect images may not be in the best interest for anyone involved in an incident. The client gets changed for the effort, the analyst gets bogged down with data to analyze and report on and unless there is a 'smoking gun' on all the system, the value of the effort is diminished.

    From my own perspective, I have had a decent run of good luck by considering other sources of actual information from asking for volatile data and logs, like VPN, Apache/IIS webserver logs to name a couple examples.

    The one caveat that comes to mind is for the analyst to think out carefully what they need to acquire otherwise they run the risk of missing a system/source that possibly had the best leads to what happened on it. In many cases the march of time does not stop for anyone, and its not unusual for logs to get overwritten or have poor log-rotation policies set. Getting the right data acquired the first time around only happens with experience, unless you are naturally brilliant.

    ReplyDelete