Saturday, July 17, 2010

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 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.

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 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.


Claus said...

Hi Harlan!

RE: "...we see in the MMPC post that the files are referred to, but nothing about the persistence mechanism."

More information on this whole mess is still breaking...slowly due to it being a weekend event.

However you might find the following sources helpful to your questions:

Trojan-Spy.0485 and Malware-Cryptor.Win32.Inject.gen.2 Review (PDF) by Kupreev Oleg and Ulasen Sergey of VirusBlokAda as linked to and hosted by F-Secure Weblog.

I've also posted a summary collection of linkage in general about this vulnerability on the GSD blog:

Windows zero-day exploit?: USB storage + .lnk files + file explorer = FAIL

Stefan said...


do we assume that they're listed as device drivers under the Services key?



Corey Harrell said...

Great post and I agree that a means needs to be developed by which forensic analysts can more easily determine the root cause of an infection or compromise. I think another component that should be involved is the artifacts for the most common delivery mechanism which delivery the exploit and payload. For example, what are the typical artifacts left on a system if the delivery mechanism was a hidden iframe as compared to a thumb drive.

H. Carvey said...

Corey, that something you can provide, as a start?

Corey Harrell said...

I just started to think about the artifacts left by the common delivery mechanism and this is going to be the next area of my testing. The testing is going to take some time due to other obligations but I will share it with the community once I make some progress on it.