Mark Russinovich recently posted The Case of the Malicious Autostart to his blog.  I have to say, I think we are all very fortunate that Mark decided to post this; besides providing a very good demonstration of the use of the tools that Mark has written and made available, but it also demonstrates what others within the community are seeing.  Chris Pogue recently did something similar with his Webcheck.dll post to the Spiderlabs Anterior blog, and it's good to see these kinds of things posted publicly.

Mark's post provides some really good information about what was found during a support call, and the tools and techniques used to find it, as well as to dig deeper.  One thing that's interesting to point out is that the infection of the system may have included subversion of Windows File Protection (not that that's not trivial...), as it's mentioned that  the user32.dll files in the system32 and dllcache directories were modified.

Posts like this give the rest of us an opportunity to see what others are facing and how they're addressing those challenges.  Being the tech support in my household, I'm somewhat familiar with these tools and their use, but I can't say that I've seen something like this.  What I like to do is see how this methodology fits into my own processes.

In the comments to the post, a user ("Mihailik") asks about determining the infection vector, to which Mark responds:

Unfortunately, that's a question just about anyone fighting a new malware infection will have a near impossible time of determining. Unless you actually see the infection as it takes place, you can't know - it could have been someone executing a malicious email attachment, opening an infected document, or via a network-spreading worm. 

I would suggest that by using timeline analysis, many of us have been able to determine infection vectors.  I know that folks using timelines have nailed down the original infection vector in some cases to phishing emails, attachments, browser drive-bys, etc. The timeline may give an indication of where you should look, and examination of the actual files (PDF or Word document, Java .jar file, etc.) will illuminate the issue further.  Determining the infection vector may not have been something that could be easily done on this system, during this support engagement, but for more IR-specific engagements, this is often a question that analysts are asked to address.

I know I'm a little behind on this one, but I saw this morning that back in June, the MS AntiMalware team released an MSRT white paper entitled "Windows Malicious Software Removal Tool: Progress Made, Trends Observed".

I've seen some writeups and overviews of the content, particularly at the SANS ISC. Some very interesting statistics have been pulled from the data collected, and as always, I view this sort of thing with a skeptical eye. From the overview:

This report provides an in-depth perspective of the malware landscape based on the data collected by the MSRT...

It's always good for the author to set the reader's expectations. What this tells me is that we're only looking at data provided by the MS tool.

Here are a couple of statements from the overview that I found intersting:

Backdoor Trojans, which can enable an attacker to control an infected computer and steal confidential information, are a significant and tangible threat to Windows users.

Yes. Very much so. If a botmaster can send a single command to a channel and receive the Protected Storage data from thousands (or tens of thousands) of systems, this would represent a clear and present danger (gotta get the Tom Clancy reference in there!).

Rootkits...are a potential emerging threat but have not yet reached widespread prevalence.

I don't know if I'd call rootkits a "potential" or "emerging" threat. Yes, rootkits have been around for quite a while, since Greg Hoglund started releasing them with the NTRootkit v.0.40. In fact, commercial companies like Sony have even seen the usefulness of such things. It's also widely known that there are rootkits-for-hire, as well. Well, I guess what it comes down to is how you define "widespread". We'll see how this goes...I have a sneaking suspicion that since it's easy enough to hide something in plain sight, why not do so? That way, an admin can run all the rootkit detection tools they want and never find a thing.

Social engineering attacks represent a significant source of malware infections. Worms that spread through email, peer-to-peer networks, and instant messaging clients account for 35% of the computers cleaned by the tool.

I can't say I'm surprised, really.

These reports are interesting and provide a different view of the malware landscape that many of us might not see on a regular basis...it's kind of hard to see the forest for the trees when you're face down in the mud, so to speak.

Even so, what I don't think we see enough of in the IR and computer forensics community is something along the same lines but geared toward information that is important to us, such as forensic artifacts. For example, how do different tools stack up against various rootkits and other malware, and what are the artifacts left by those tools?

Most of the A/V vendors note the various changes made when malware is installed on a system, but sometimes it isn't complete, and other times isn't correct (remember the MUICache issue??).

What would be useful is a repository, or even various sites, that could provide similar information but more geared toward forensic analysts.