Malware Intelligence: Making it Actionable

Published: 2008-07-20
Last Updated: 2008-07-20 18:52:34 UTC
by Kevin Liston (Version: 1)
0 comment(s)

At the day job I have to read a lot of alerts and reports and studies and white-papers and blogs on viruses, worms, malicious websites, crimeware, spyware, adware, malware (oh my.)

The intent is to tease out the important little details so that I can provide the proper guidance the client.

Target Audiences

Anytime someone produces a document, they have a target audience in mind (although sometimes it feels like they’re not conscious of it.)

 Documents about malware often address one of the following groups:
 
  • IT Staff/Sysadmins/Operations
  • Malware Researchers
  • Management/Public
“Actionable Intelligence” means different things to these particular groups. For Management, they want to know things like:
 
  • Are we vulnerable to this?
  • Am I getting my money’s worth from what I’m spending on anti-malware measures?
On the other hand, Operations Groups need to know basically:
 
  • Are we exposed?
  • If so, what do we do about it?

Are We Exposed?

The answer to this question relies on the answers to a number of other questions:

  • What vulnerability does this exploit?
  • Does our AV detect or block this?
The first question needs to be answered by your intelligence source (even if it’s just google,) you need to know what vulnerability this threat exploits. Does it exploit an IE weakness that you already have patched? Then you’re not exposed (as much.) Does it rely on a user clicking and running something (aka CVE-1) then you have a certain level of exposure. Is it exploiting some unknown vulnerability in an application that you deploy? Then you’re going to have a long day.
 
The second question’s answer depends on your AV vendor. Do they provide easy and reliable answers to this question? If not, perhaps you need a chat with your vendor. In cases where you have a copy of the malware, this is a little easier—you just test it against your AV (just be careful kids.) When all you have are media reports—this is a lot harder (vendor’s take note here.)

What Do We Do About It?

This is really the meat of what Operations needs to know. 

  • Are there new AV signatures to deploy? 
  • Do Websites need to be blocked?
  • Are there IDS signatures to detect infected systems?
  • Can it be safely cleaned off of a system? Or does it need to be re-imaged?

Is Your Environment Perfect?

I don’t know about your network, but in mine, AV fails (malware generation is faster than signature deployment, AV isn’t installed everywhere,) Web proxy filters fail (malicious sites pop up faster than the filter DB gets deployed, people have laptops and don’t have this protection on the road,) and people click on things (especially before their morning cup of coffee.) So an additional question that the security operations group needs to have answered is: “How do we detect an infected/compromised machine?”

 
  • Does it connect out to a known Command and Control system?
  • Does it make known HTTP requests?
  • Does it advertise itself in the user-agent?
  • Does it scan for a particular port?
  • Does it generate P2P traffic?
  • Does it set up a backdoor listener?

Case Study: The SuperBowl Worm

In February 2007, I wrote up a simple little entry (http://isc.sans.org/diary.html?storyid=2151) on what was dubbed the ”SuperBowl” worm. It was a harbinger of things to come, warning of our current environment of widespread web-site defacements driving a victim to a malicious website.

With that article, I hope that helped to satisfy the important questions, namely:

  • What vulnerability is exploited? MS06-014 and MS07-004
  • What does it do your system? It attempts to install www.exe on the victim machine
  • We provided links to IDS alerts
  • We briefly mentioned AV coverage (my work left a lot to be desired in this instance.)

Now, for the back story. At the day job this was getting a lot of managerial attention—mainly of the “What are we doing about it?” variety. We had good information on how to identify a malicious website, and matching that against our web proxy logs, we had very good information on how many systems were exposed. What we were lacking was a good signature for a successful exploit. In this instance we chose with the “better safe than sorry approach” and opened up tickets on everyone who visited a malicious website. This sent a technician out to each machine to check that it was patched properly, the AV was running properly and re-image the system if anything was out of line. 

The down-stream operations groups were not pleased.
 
The embarrassing part (and there are few better teachers than public humiliation) is that when a good signature to identify a successfully exploited system did become available. The number of real incidents was more like 1% of the exposed systems.

We’ve adjusted our response process a bit, and now “remember the Superbowl” is often uttered when trying to temper down mid-incident excitement.

In this case, we could have waited a bit to generate a better list of infected machines—especially with the hindsight that the malware’s intent was to steal gaming passwords—not targeting all passwords.

Case Study: Coreflood

In June 2008, Deb mentions a Coreflood outbreak (http://isc.sans.org/diary.html?storyid=4624) She mentions that the malware was delivered via a malicious website and goes on to describe how it uses psexec and domain privileges to infect other machines in the domain.  There’s also a note of how McAfee and Norton are detecting it. Not too bad, but keep in mind that we’re not claiming to be your one-stop malware intelligence source. 

Let’s look at what Joe Stewart released two days later: http://www.secureworks.com/research/threats/coreflood

It has a few more answers in it. I can’t answer all of the basic questions yet, but I can make some assumptions. Of importance is the statement: “At current, the known controller domains are mcupdate.net, joy4host.com and antrexhost.com.” This is something that I can use, I can detect infected systems within our network and respond. Happily I’m able to report that we haven’t found any (yet) at the day job.

Case Study: W32/Agent-FUVR

I received a query this week about an outbreak in Indonesia of W32/Agent-FUVR.  It was along the lines of: “A Customer is concerned about W32/Agent-FUVR and wants to know what we’re doing about it.”

Initially, I had to ask myself: “What is W32/Agent-FUVR?”  I had to google it.  Hoping that I’d find a virustotal result that would translate W32/Agent-FUVR into what other AV tools were identifying it as.  From the results (and making some possibly dangerous assumptions) I see that Norman uses the W32/Agent.FUVR nomenclature (which is a bit different from that used in the original email—so I’m little nervous.)

The provided copy/paste of the news article says that it’s targeting Indonesia.  Googling turns up a definite pattern of analyses hosted in the .id domain.  I can read bits and pieces of them.  Enough to gather that it uses Yahoo! IM messages to convince users to click.  From this can I guide the client a little bit on their potential exposure. 

Using the virustotal results as a kind of Rosetta stone to translate W32/Agent-FUVR into what the client’s AV vendor calls it, reveals only a generic signature.  The good news is that I can tell the client that they’ve had coverage for this since at least June 15th (based on when the virustotal report was created.)  So I can tell them that they’re (reasonably) covered from an AV signature standpoint.

I still couldn’t tell you what the intent of the malware is at this point—nor do I have a good signature to detect if an infected machine was brought into their environment.  But it’s not a perfect world, and you don’t win them all. 

The Ignored Target Audience

What I rarely see are efforts to identify the individuals and groups behind the malware that we deal with.  Obviously such investigations need to be kept quiet, but one would hope that there would be more reports of arrests, or we wouldn’t have bot-nets that have been in the media spotlight for long periods of time.  If you have information that would help such an investigation, but don’t know who to report it to or how, please contact us.

The Ideal Intelligence Source

The ideal malware intelligence source would tell you:
 
  • What vulnerability the malware exploits
  • What the malware does to the system
  • What the malware’s intent is
  • Who is behind it

A source that provides all of that information would be able to answer nearly all of the relevant questions that Operations, Management, and Law Enforcement have. Malware Researchers: I’m afraid that you’re on your own. It’s up to you in your labs with your debuggers digging into it yourselves. I’m fairly certain that you wouldn’t have it any other way.

Keywords: malware
0 comment(s)

Comments


Diary Archives