Pages

Thursday, January 31, 2008

Artifact Repositories, part deux

I wanted to take my last post on this topic just a bit further...

I received an email from someone recently asking me about checklists for determining the attack vector of an incident. Yeah, I know...that's a pretty broad question, but I do see the issue here. Sure, some folks are "finding stuff", but the question is now becoming, how did it get there? That's the next logical question, I suppose, and it is being asked.

Over on F-Secure, I saw this post this morning about a PHP IRC Bot. This is just one example, but once the IRC bot is located on the infected system, how does one go about determining how it got there? One thought would be to look at the method you used to locate the bot...say, scanning with an AV scanner...and use that as a starting point. What did the AV scanner identify the malware as? Once you get a name, go to the vendor's web site and see what it says about infection vectors. Again...this is one way to go about the process, not the way.

Another example is this...I'm sure that finding a bot or backdoor isn't too difficult, particularly if you have volatile data or the malware is easily detected by the scanner you're using. But how did it get there? Was the attack vector a downloader from a malicious web site that pulled down a Trojan or bot that was then used to put the backdoor on the system?

At this point, you might be thinking..."who cares?" After all, you found the bad stuff, right? But is that really sufficient? If you you don't discover the root cause, how do you protect yourself in the future? How do you protect other systems?

Another aspect to consider are the application artifacts. Hogfly recently posted on intel gathering...what are the artifacts of the use of the three applications he listed in the post? Does anyone know? After all, one thing to be concerned about is USB devices...but how many are considering remote storage repositories? Anyone remember this three year old blog post regarding the GMail Drive? Some of the artifacts listed in the post are easily added to any sort of Registry scanning tool... ;-)

I'm thinking that it's about time to add a little something to our investigative process. Artifact repositories will very likely make it much easier to determine root causes, keeping in mind, though, that such a thing isn't really a comprehensive solution. Training or instruction in OS and application basics will provide a better understanding of how to determine root causes, particularly when there a multiple possibilities.

4 comments:

  1. I know I'm looking at remote storage repositories. The apps I listed are on my hit list for upcoming work..as soon as I can get past a few blocking issues I'll get to them.

    As far as RCA goes I find there is a regular struggle to devote the time to determine the root cause because management hasn't been convinced of the value of such an endeavor. All they commonly care about is the end result..and that's just a shame.

    ReplyDelete
  2. ...management hasn't been convinced of the value of such an endeavor.

    In many cases, you're right. However, my experience has been that there are times when, after the final report is done, mgmt will ask that question...albeit as an afterthought. However, part of the impetus for the post what that I've received about half a dozen emails stating something along the lines of "...my boss wants to know..."

    ReplyDelete
  3. Yeah isn't that something? They all want to know but don't want to invest resources to it. My opinion is without an RCA the job isn't complete.

    ReplyDelete