Three new rule categories were introduced yesterday (Tuesday, 13th July 2010) in SEU 348 and into the VRT Certified Rule packages. I'd like to take a moment to explain what's in these categories, where the data behind them is coming from, and what you should do if you turn them on and they start firing.

The initial set of rules for these categories was pulled from the specific-threats and spyware-put categories, as these categories already contained numerous botnet command and control, and dns based detection rules. We felt that by breaking these categories out it was easier to find the rules end users were looking for, and that doing this gives people a simpler way to enable a whole type of detection in a single unified category. These categories are augmented by our automated malware analysis systems, spam traps, honeynets, and additional external data feeds. We'll be putting out some additional information about how these systems works and what type of data they capture; we'll also be publishing some raw data lists. Anyone will be able to get the raw lists, which contain IP addresses, URLs, and DNS names that were collected from these systems so you can use this data in other security or security releated tools, like SMTP RBLS, or DNS Blockhole systems.

  • botnet-cnc.rules: A large portion of the world's malware connects the infected machine into a botnet, to serve at the whim of whomever unleashed the initial infection; this software uses command and control channels to communicate with master servers and take instructions on what to do next. These rules are aimed at detecting communication over those channels, by looking for portions of URLs that remain constant across domains used by control servers, chunks of the communications channels themselves, or other criteria that have been observed repeatedly across a broad range of related pieces of malware. A number of rules in this category were previously listed in the Specific-Threats category and in the Spyware-Put category, since these rules focused specifically on command and control traffic they have been moved here.
  • blocklist.rules: These rules look for DNS queries for known-malicious domains and common URL patterns observed inside of our malware sandbox, not necessarily associated with a command and control channel. These could be domains serving up exploits, URLs used in click-fraud schemes, update servers for malware, or any number of other things that were consistent across a large number of malware
    samples.
  • phishing-spam.rules: Phishing attacks and spam are the bane of the modern inbox. These rules seek to supplement your existing spam filtering system (you do have a good spam filter, right?) by looking for domains being advertised in malicious emails.
    So, what happens if you turn these rules on and you start getting alerts? For the phishing/spam rules, you may wish to consider enabling them in blocking mode, to help prevent these malicious emails from coming into your network in the first place. For the blocklist and botnet/C&C rules, you've got a larger problem on your hands, since you're looking at outbound communications from an existing infection.

We've done our best to help you identify the particular piece of malware generating the traffic being detected by these rules. For most of the malicious domains in our blocklist rules, we've cross-referenced with other malware analysts and given you the name of at least one virus known to be associated with the domain in question.

Additionally, the references included in rules based on our malware sandbox data give you a list of md5sums of binaries that generated the traffic used to create the rule - which can help you cross-reference anything suspicious you may find on the system in question with tools like Virus Total and ThreatExpert.

Since these rule categories will be under active development, we welcome your suggestions on ways to improve them, and your feedback on how you've integrated them into your security process in the wild. Feel free to comment below, or reach us on IRC or email at research at sourcefire dot com.