Tuesday, July 17, 2007

The Most Valuable ArcSight Filters of The Summer

Without a doubt, 2007 will be remembered by infosec professionals as the year that malware came into its own. Client-side exploits and malware are nothing new. But this year there is a lot more of it, it's a lot better put together, the malware authors are handily kicking the anti-virus industry's ass, but most of all its being run like a business. If you doubted it before, ecard should be proof positive that very smart, very organized people are behind malware distribution. That's not to say that they can't be beaten, but it's definitely an arms race, and if you aren't doing your part to gather intel, well, what you don't know can definitely send your docs to .ru.

These days, I spend a lot of my time in front of two ArcSight grids ("active channels") because they are the best tools I have for finding malware as it's on its way in to the environment. So here they are.

First, this filter is built to look for McAfee ePolicy Orchestrator (ePO) events that involve an actual virus signature. When a VirusScan alert event is passed back to ePO, it stores the signature name in a device string.

(Device_Product = "ePolicy Orchestrator" And Device_Vendor = "McAfee" And Device_Custom_String1 NOT Is "NULL")



The second filter should work for any proxy or firewall log where URLs are present in the log. In my case the source is Check Point firewalls using WebSense for content filtering. Even if WebSense doesn't block them, the URLs are recorded in the log. Basically, we want to know about all of the standard executable file types and then look for suspicious downloads. Depending on your network's configuration and size, you may need to tune this to make it useful. For instance, if you don't have a WSUS server and your workstations get updates directly over the Internet, this channel will be very busy for 2-3 days every month.

(Request_Url EndsWith [IgnoreCase] ".exe" OR Request_Url EndsWith [IgnoreCase] ".msi" OR Request_Url EndsWith [IgnoreCase] ".pif" OR Request_Url EndsWith [IgnoreCase] ".cmd" OR Request_Url EndsWith [IgnoreCase] ".bat")




Update: Someone told me that he didn't think it made sense to monitor anti-virus alerts when trying to combat malware, after all this is the stuff that your anti-virus did detect and stop. Aren't we interested in the stuff that got through?

Yes, absolutely. It has been my experience (and perhaps yours, too) that it is common for a dropper to attempt to install multiple pieces of malware. The malware authors are regularly repacking to defeat AV detection, but they can't win every time. It is common, at least 50% of cases I've handled since March, for the anti-virus to detect and remove some, but not all of the malware being dropped. It's my advice that AV detects should be investigated to see if there were other downloads, suspicious network traffic, etc. from machines that did generate alerts, as they may still be compromised.

1 comment:

Anonymous said...

I drop a similar filter (.exe) into a Trend and have a daily report greet me when I get into work. My intent originally was to use the Trend as an after the fact thing to look at to help find the source vector. Going through the report in an effort to trim out what I don't need has led to finding 6 zero day/varients in the last 2 or 3 weeks.

Mark