In my last post, we took a look at some ways to do malware detection, and in that post, I presented four general characteristics of malware that can be used to detect and deal with many of the issues that we run into. I thought that a good way to get discussion on this started would be to run through an example, the nice folks at the MMPC popped up a great example today...%LnkGet%. Let's take a look at the write up on %LnkGet% and see how we can apply the four characteristics, and see if a response methodology (and even an analysis methodology) begins to evolve...
Initial Infection Vector
Okay, the MMPC describes this bit of malware as a Trojan Downloader that when run, downloads other files. Also according to the MMPC, the initial infection vector is to arrive as an email attachment, so one way to begin looking for indications of this is to search for Windows shortcut (*.lnk) files in email attachment directories; remember, this may also include web-based email tools, as well, so looking for .lnk files in the web cache may be a good idea, too.
Artifacts
The artifacts of this malware are pretty straightforward...first off, the main file involved is a Windows shortcut/*.lnk file. Yes, there can be a great number of these on a Windows system, but as an analyst, what you'll be looking for is a .lnk file in an unusual place (ie, email attachment or web browser cache directory). In addition, this .lnk file downloads a .vbs script that then downloads additional malware.
From a network perspective, the downloading may leave artifacts in log files; as you can see from the write up, there are a number of sites involved which resolve to .cn and .tw domains.
Propogation Mechanism
This bit of malware is described as a downloader, and doesn't propogate on it's own. However, as a downloader, it may download additional malware that does propogate (ie, a worm of some kind).
Persistance Mechanism
This bit of malware doesn't seem to need a persistance mechanism, because once it's downloaded the additional malware, it's done. The MMPC does state that while the shortcut files do try to disguise themselves through the use of icons, they apparently do not delete themselves once they've completed their task(s).
What this tells us...
1. Block .lnk file attachments
2. Have a written policy and educate users against launching arbitrary files that they receive, regardless of the source.
3. Develop a CSIRP and train your responders (this is a subject for a whole other series of posts).
My reason for looking at things like this is that AV companies are not incident responders. People who discover vulnerabilities and publish exploits are not incident responders. In most cases, companies such as these provide information that they think is important, but very often what they provide is not sufficient for their users and customers to incorporate into their risk management and incident response planning. In this regard, I really think that these companies are doing their customers a huge disservice.
I agree Harlan's perspective and especially on his last two sentences in what companies are *actually providing* in terms of useful information. I can't tell you how many times where I had to chase down a number of websites of AV products that identify the virus/malware/worm/what-have-you only to see some generic remark about "See our suggestions about removal of this type of worm," or something like that.
ReplyDeleteIn my opinion that is pretty lame. If that is the best information they can do, then they should not be amazed when IR folks to go somewhere else in frustration. Stuff that come out as 'Late-breaking' or middle of the night I can understand, but stuff that has been out there for weeks has no excuse to only refer to a skimpy sheet of instructions with little in the way of precise indicators or artifact to watch out for.
Having learned quite a bit from Harlan's blogs on this topic, as well as from his generous personal attention to my recent problem, I'll echo your appreciation of Harlan's comments. I'll also second (third?) both of your comments on the failure of vendors to give us the tools we need.
ReplyDeleteI've commented on this here in the past. We use ESET NOD32, as it's free under a state contract. ESET provides no descriptions of 99% of its detections. More than 1.5 years ago, ESET acknowledged that its virus encyclopedia was lacking and promised improvement. False. It's as bad as ever. Customer support is non-existent, though I was told that I could pay for information about NOD32 detections. Yeah, right. When you think about, how do we even know that a NOD32 reported threat is a threat? Because they say so? What if I did that in an exam?
Venting aside, I'll again suggest the Vgrep at https://www.virusbtn.com/login. Thanks to Harlan, I've obtained copies of Clam AV and SysClean portables, and I'll see what they provide. I installed a copy of McAfee in a VM, hoping to scan mounted images, but it's an unacceptably slow process. I picked McAfee as its information database is, I think, better than the others.
Jimmy,
ReplyDeleteJust a point of clarification...
...on the failure of vendors to give us the tools we need.
What I'm trying to point out is that vendors are going to provide what tools or information makes sense to them and to their business. Often...very often...what makes sense for their business has nothing to do with providing necessary information to help customers prevent and detect these issues, even when the vendor's own products can't...
I think that your point is obviously inherent in the issue. I don't question their motives, as there is less profit in maintaining a database or customer support. Sales come first, and they seem supported by somewhat meaningless stats on which tool caught which code first.
ReplyDeleteOur problem is not their's. It puts us at a disadvantage, however, as an opponent need opnly say that NOD32 found Win32/BlahBlah-D, which makes it possible that the evidence was planted.
I'd pay twice (3x?) as much for a tool that provided answers. I'd even go for a special subscription to a virus database. In the meantime, your work goes a long way to help us work with what we have, as well as with tools and techniques about which we new little before visiting.