Links

e-Evidence
Christina's updated the e-Evidence What's New site...check it out! There's always some good reading here...

Tools
Speaking of tools, Don's been busy...no, Don's not a tool, but he's posted a tool update over on the SecRipcord blog. In addition to the tool update, Don has a little tip he got from some guys from Mandiant on detecting if malware embedded in or infecting CHM (Windows compiled Help) files might have been run on the system.

Don also links over to IronGeek's forensically interesting spots post. It's a very interesting post, and I noticed that a lot of the Registry locations that IronGeek mentions are covered by RegRipper plugins. Also, something else to think about...IronGeek has done a great job of presenting some interesting places to look for forensic data, but I noticed that under both IE and Firefox, there's no mention of Favorites or Bookmarks, respectively.

I digress for a moment, but I really think that examining some of the areas described in my earlier post can add a great deal of context to the information retrieved via more well-known analysis. For example, one of the first items on many checklists with respect to browser analysis is to check the contents of the TypedURLs key. That's fine, but what if the user's default browser isn't IE? That's right...no entries in this key would be explained by that fact. Now, what if there are some entries in the key, and the default browser is IE? Checking the Favorites list would provide some context to what was being seen in the browser history.

Where this can also be helpful is if some sort of anti-forensic tools or techniques have been employed on the system. I actually received a question along these lines just the other day...someone interested in getting into the field asked me how analysts "deal with" anti-forensic tools, and specifically mentioned timestomp. Well, there are a number of locations on a system that contain timestamps that are not affected by timestomp or other anti-forensic tools/techniques.

It seems that I'm not the only one thinking along these lines...Kristinn has updates to log2timeline that include adding this sort of information to a timeline. Thanks to gl33da for sending me the link to Kristinn's page.

Analysis
Speaking of tools, Daniel Wesemann has a SANS ISC post on the static analysis of malicious PDFs, which is pretty easy to follow along with...and starts out using Didier's PDF tools. Very cool!

Circling back around to browser analysis yet again, I picked this one up from the sausage factory...consider the browser's session restore capabilities, something that's been around for a bit. I use Firefox (I've been using Mozilla since 0.9, from as far back as...'94?) and version 3.5 would crash often. When it did, I'd have to decide to restore sessions are just start new ones. Harry Parsonage posted a PDF on the topic...take a look.

Certs
Daniel Castro had a very interesting article in FCW regarding his thoughts on a national certification program. I think that Daniel made some very important points in his article, one being that an increase in certified individuals hasn't resulted in a corresponding decrease in vulnerabilities, incidents/breaches, and losses. I also agree with Daniel in that a national/federal certification program will result in a check-in-the-box mentality...there are plenty of examples out there to illustrate this occurring.

There are a number of excellent certification and training programs out there, and I really don't think that the issue is the programs themselves; no, it's the individual who gets the certification and what they do with it. Let's say you go away to a training program, work hard, and get the certification, and when you return back to your job, you don't use any of the newly-developed skills for 6 or more months...then what? Do you go for a skills review after an incident occurs? If your company is going to send you off to this training, shouldn't there be a purpose for it...like, this person is going to be an integral part of our security plan or CIRT? Wouldn't it then be a good idea to have a plan that starts with getting someone trained, and once they return, get them involved in the program and using those newly-learned skills?

I've seen certified responders walk up to a compromised system, open the Event Viewer, start opening event records, and use Paint to save bitmaps of the entire desktop to the system hard drive as a means of documenting their findings. Seriously. Is that the fault of the certifying organization, or whomever wrote the materials? No, of course not. The material was provided to an individual and they were certified, but what happens after that is in part up to the individual, and in part the responsibility of their management.

Rootkits
Microsoft's Malware Protection Center recently posted some observations on rootkits for 2009...pretty interesting read. However, I think that like a lot of AV service write-ups, something like this falls short of what it could be. Many times, AV service write-ups are geared toward "use our product" type of information, and sometimes not enough to be useful in an environment that may already use that product.

Working as an incident responder over the past several years, a couple of the things I've seen are that (a) a malware infection can devastate an infrastructure, (b) AV products don't protect against everything, and (c) AV services are geared toward using the product.

As an example, just about a year ago, Conficker (and later in the spring, Virut) variants would bring an infrastructure to its knees...literally. Our team would show up, and often find someone from the AV vendor already on-site or engaged. Our observations of the malware characteristics would lead us to a diagnosis, so that we could assist in identifying infected systems, which would be pulled offline and scanned with the updated virus files provided by the vendor. Often things didn't really get rolling until we stepped in because the AV vendor required a sample to analyze, and the customer was drowning.

After the incident settled down, we would have discussions with the customer to help them understand that this was a variant of previously detected malware family, and that the variant itself was sufficiently different enough to escape detection by their current and up-to-date AV product.

Anyway...enough of the soapbox, I guess...it's just too early in 2010 for that!