Exploit Artifacts redux

I posted yesterday, and included some discussion of exploit artifacts, the traces left by an exploit, prior to the secondary download. When a system is exploited, something happens...in many cases, that something is an arbitrary command being run and/or something being downloaded. However, the initial exploit will itself have artifacts...they may exist only in memory, but they will have artifacts.

Let's look at an example...from the MMPC blog post on Stuxnet:
What is unique about Stuxnet is that it utilizes a new method of propagation. Specifically, it takes advantage of specially-crafted shortcut files (also known as .lnk files) placed on USB drives to automatically execute malware as soon as the .lnk file is read by the operating system. In other words, simply browsing to the removable media drive using an application that displays shortcut icons (like Windows Explorer) runs the malware without any additional user interaction. We anticipate other malware authors taking advantage of this technique.

So the question at this point is, what is unique about the .lnk files that causes this to happen? A while back, there was an Excel vulnerability, wherein if you opened a specially-crafted Excel document, the vulnerability would be exploited, and some arbitrary action would happen. I had folks telling me that there ARE NO artifacts to this, when, in fact, there has to be a specially-crafted Excel document on the system that gets opened by the user. Follow me? So if that's the case, if I search the system for all Excel documents, and then look for those that were created on the system near the time that the incident was first noticed...what would I be looking for in the document that makes it specially-crafted, and therefore different from your normal Excel document?

So, we know that with Stuxnet, we can look for the two files in an acquired image (mrxcls.sys, mrxnet.sys) for indications of this exploit. But what do we look for in the malicious LNK file?

Why is this important? Well, when an incident occurs, most organizations want to know how it happened, and what happened (i.e., what data was exposed or compromised...). This is part of performing a root cause analysis, which is something that needs to be done...if you don't know the root cause of an incident and can't address it, it's likely to happen again. If you assume that the initial exploit is email-borne, and you invest in applying AV technologies to your email gateway, what effect will that have if it was really browser-borne, or the result of someone bringing in an infected thumb drive?

The MMPC site does provide some information as to the IIV for this issue:
In addition to these attack attempts, about 13% of the detections we’ve witnessed appear to be email exchange or downloads of sample files from hacker sites. Some of these detections have been picked up in packages that supposedly contain game cheats (judging by the name of the file).

Understanding the artifacts of an exploit can be extremely beneficial in determining and addressing the root cause of incidents. In the case of Stuxnet, this new exploit seems to be coupled with rootkit files that are signed with once-legitimate certificates. This coupling may be unique, but at the same time, we shouldn't assume that every time we find .sys files signed by RealTek, that the system had fallen victim to Stuxnet. Much like vulnerability databases, we need to develop a means by which forensic analysts can more easily determine the root cause of an infection or compromise; this is something that isn't so easily done.

Addendum
Another thing that I forgot to mention...we see in the MMPC post that the files are referred to, but nothing about the persistence mechanism. Do we assume that these files just sit there, or do we assume that they're listed as device drivers under the Services key? What about the directory that they're installed in? Do they get loaded into a "Program Files\RealTek" directory, or to system32, or to Temp? All of this makes a huge difference when it comes to IR and forensic analysis, and can be very helpful in resolving issues. Unfortunately, AV folks don't think like responders...as such, I really think that there's a need for an upgrade to vulnerability and exploit analysis, so that the information that would be most useful to someone who suspects that they're infected can respond accordingly.