Wednesday, April 14, 2010

Snort Signatures for New Koobface Variant

The first rule is actually how we caught the first incident. The binary is served on non-standard HTTP ports via fast-flux servers. It's a signature we've had in place for years.

alert tcp $HOME_NET any -> $EXTERNAL_NET !80 (msg: "LOCAL .exe file download on port other than 80"; flow:established; content: "GET"; depth:4; content: ".exe"; nocase; classtype:misc-activity; sid:9000160; rev:1;)

And these are designed to catch the bot HTTP checkins we've seen so far. This is likely to be more of a whack-a-mole effort as we've already seen the checkin URL format change once.

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"LOCAL Koobface action=fbgen checkin"; flow:to_server,established; content:"POST"; content:"/.sys/?
action=fbgen"; nocase; classtype:trojan-activity; sid:9000220; rev:1;)

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"LOCAL Koobface go.js checkin"; flow:to_server,established; content:"POST"; content:"/go.js?"; nocase; classtype:trojan-activity; sid:9000221; rev:1;)


Martin said...

Those are good things to monitor! However, existing sigs for Koobface in the Emerging Threats signatures capture those, in case any readers are already running them. See SIDS 2010335 and 2010700. Also, I'd recommend the PE signature 2000419 over your GET signature, as it will detect any EXE or DLL download, even if they don't use a .exe extension.

PaulM said...

Hi Martin,

Thanks for the reply, and thanks for all of the work you and the team do!

You're right about sid 2010335 covering the same checkin traffic that my rule with sid 9000220 does. The ET sid 2010700 is supposed to detect the actual .exe file that Koobface is using right now. However, that rule is using $HTTP_PORTS and we're seeing the binaries download from fast-flux servers that are using all kinds of random port numbers that this rule would miss.

The PE download rule (sid 2000419) doesn't catch the setup.exe files we've seen over the past week. They're packed with UPX (according to PEiD and RBS, anyway) and the string "This program cannot be run in DOS mode" doesn't appear in them. Also, this is generally not a reliable signature unless the Snort sensor's flow depth is set to something larger than the default, which in turn has performance implications on Snort's stream reassembly function.


Martin said...

Quite right on all accounts. I had forgotten that the basic exe detection in the ET rules searched on the header text. There are some other, more specific exe rules that search based on pure MZ information, such as a header size indicating the exe is small. I realize now that I have been using a custom exe rule for my generic exe detection:

log tcp !$OK_EXE_SERVERS any -> $HOME_NET any (msg:"LOCAL Executable download"; flow:established,from_server; content:"MZ"; content:"PE|00 00|"; within
:700; sid:9000010; classtype:not-suspicious;)

You're very right about the flow depth. I've had a lot of conversations years ago on lists regarding that, and it comes back to Sourcefire's obsolete default focus of their product on protecting servers, when the vast majority of malicious activity today is occurring against clients (and from there, servers). From the Sourcfire manual on server_flow_depth: "A small percentage of Snort rules are targeted at this traffic." This is not true anymore! I was shocked when I first realized how small their defaults were. In my book, it's kind of cheating to gain "performance" by ignoring a lot of potentially important traffic. I always run with server_flow_depth=0 to search the entire payload and run a tight ruleset to avoid drops.

Thanks for pointing out the port 80 restriction on the ET rule 2010700. It's still a good detection rule, but it sounds like it needs to be modified to search all ports.

mark said...

After seeing an example of the go.js in our environment I created an ArcSight rule to look for 10 unique destinations with the same URL. It later picked up a system with "/.sys/". I liked the rule but because our environment is the way it is the rule was causing a little overhead (partial matches). In both cases our AV solution hadn't seen the particular Koobface varients that were on those boxes.

Interesting to see your post.