Links

Who You Gonna Call?
Tom Liston had a great post to the ISC blog a bit ago entitled Incident Reporting - Liston's "How To" Guide. This humorous bent on the situation simply oozed truthiness. Many moons ago, I was on the receiving end of the "abuse@" emails for a telecomm provider, and marveled at the emails threatening litigation as a result of...and get this...a single ICMP packet received by some home user's firewall. Seriously.

One thing I would add to that, particularly for larger organizations...seek a relationship with professional responders before (because one will...if one hasn't, you simply haven't been paying attention) an incident occurs, and work with them to understand how to best help yourself. What really turns most organizations off to responding to incidents in general is the overall impact to their organization...having people on-site, engaging their staff, taking them away from keeping the email server up...and there's the price tag, to boot. But the problem is that in almost every instance, every question asked by the responders is answered with "I don't know"...or with something incorrect that should have been "I don't know". Questions like, what first alerted you to the incident? Where is does your sensitive data live in your infrastructure? How many egress points/ISPs do you have? Do you have any firewalls, and if so, can we see the logs? It's questions like these that the responders need to have answered so that they can scope the engagement (how many people and how much equipment to send), and determine how long it will take to complete the engagement. To be honest, we really don't want to have to engage your staff any more than we have to...we understand that as the engagement goes on, they become less and less interested, and less and less responsive.

Art Imitates Life
My wife and I watched Extraordinary Measures recently...we both like that feel-good, "based on a true story" kind of movie. After watching the movie, it occurred to me that there are a lot of parallels between what was portrayed in the movie and our industry...specifically, that there are a lot of tools and techniques that are discussed, but never see common usage. Through sites such as eEvidence, I've read some very academic papers that have described a search technique or some other apparently very useful technique (or tool), but we don't see these things come into common usage within the industry.

IIVs
H-Online has a nice CSI-style write up on investigating a "PDF timebomb". I know a lot of folks don't want to necessarily look at (I hesitate to say "read") some really dry technical stuff, particularly when it doesn't really talk about how a tool is used. A lot of available tools have a lot of nice features, but too many times I think a lot of us don't realize that espousing the virtues and capabilities of a tool do little to really don't get...after all, we may have made a connection that others simply don't see right away. So things like this are very beneficial. Matt Shannon cracked the code on this and has published Mission Guides.

So what does this have to do with initial infection vectors, or IIVs? Well, malware and bad guys get on a system somehow, and H-Online's write-up does a good job of representing a "typical" case. I think that for the most part, many of us can find the malware on a system, but finding how it got there in the first place is still something of a mystery. After all, there are a number of ways that this can happen...browser drive-by, infected attachment through email, etc. We also have to consider the propagation mechanism employed by the malware...Ilomo uses psexec.exe and the WinInet API to move about the infrastructure. So, given the possibilities, how do we go about determining how the malware got on the system?

Book News - Translations
I received a nice package in the mail recently...apparently, WFA 2/e has been translated into French...the publisher was nice enough to send me some complimentary copies! Very cool! I also found out that I will be seeing copies of WFA 2/e in Korean sometime after the first of the year, and in a couple of weeks, I should be seeing WFA 1/e in Chinese!

Malware Communications
Nick posted recently on different means by which malware will communicate off of Windows systems, from a malware RE perspective. This is an interesting post...like I said, it's from an RE perspective. Nick's obviously very knowledgeable, and I think that what he talks about is very important for folks to understand...not just malware folks, but IR and even disk forensics types. I've talked before (in this blog and in my books) about the artifacts left behind through the use of WinInet and URLMON, and there are even ways to prevent these artifacts from appearing on disk. The use of COM to control IE for malicious purposes goes back (as far as I'm aware) to BlackHat 2002 when Roelof and Haroon talked about Setiri.

Evidence Cleaners
Speaking of disk analysis, Matt has an excellent post on the SANS Forensic blog that talks about using "evidence cleaners" as a means for identifying interesting artifacts. I think that this is a great way to go about identifying interesting artifacts of various tools...after all, if someone wants to "clean" it, it's probably interesting, right? I've said for years that the best places to go to find malware artifacts are (a) AV write-ups and (b) MS's own AutoRuns tool (which now works when run against offline hives).

As a side note, I had a case where an older version of WindowWasher had been run against a system a short time before acquisition, and was able to recover quite a bit of the deleted Registry information using regslack.