No, not with the default signature set. You can detect the hostile web page (since there are other automated exploits which attempt to get the EXE run) or you can write a sig looking for the request to download the various EXD variants (which we've done). Or, you could write a sig looking for a specific URL request pattern on a web server referenced only by it's IP address (which we have also). We've found that between the two of these you have a pretty accurate detection mechanism.
Bleeding Edge has over 800 sites in their IDS rules http://www.bleedingthreats.net/rules/bleeding-storm.rules
Why is Cisco not creating sigs for this threat?
Coming from a Fortune 50 company I feel this is unacceptable. It's time to recommend a new IDS vendor to Management :-(
Simply tracking by IP is not an effective or winning solution, I would still recommend using a signature to detect a user trying to grab one of the 'bad' exe files.
Cisco has been historically very slow on many vulnerabilities (plus hiding the signature regex is not acceptable in my book).. we also have Sourcefire & Dragon products and they have many pluses over Cisco (the Sourcefire ships with 5000 enabled signatures compared to Cisco's 1000).
I fully agree with you... The IP list grows far too fast to manage and is not always relieable. Can you post the sig you created for storm worm?
Unfortunately, I can't post it here since we developed that solely for our managed customers. However, if you look at the bleeding snort signatures for "BLEEDING-EDGE TROJAN Storm Worm HTTP Request" it should point you in the right direction. I wish that Cisco had a utility that would convert snort signatures for use on the Cisco sensor as you can do for Dragon now.
Cisco does monitor this board and has many engineer types who troll it and answer questions. I imagine one will stop into this thread sooner or later. I don't see a way of contacting any of them through this board so you would need to open a TAC. Cisco does have a signature writing team who are responsive (_if_ you can get in contact with them).
Thats unfortunate, I would call in and escalate your TAC and have it re-queued if it hasn't been picked up. I would also call the sales office in your state and complain that your account rep won't return your calls and to request a new one. The key is to make noise. :-)
This was done on a winxp, sp2, fully patched box, no A/V, no host ids, no tinkering with internet settings in IE, and has firefox installed. No restrictions on outbound traffic.
Following the link (in IE) I received from some random person I don't know, telling me about some account I never signed up for, and a link that isn't even hidden (it's just plain http://xxx.xxx.xxx.xxx) in the mail, took quite a considerable effort to click past all the warnings to try and get the binary to download and everything to "run" right. I actually had better luck via FireFox in getting the binary. Once I double-click on the downloaded binary, and click past numerous errors and warnings... the trojan runs finally.
Now you owe my 2 year old a word of thanks, because daddy had to trojan her laptop to get all this to work.
The binary being downloaded seems to mutate rapidly, so looking for that isn't a great idea. It's also further obfuscated by being gzipped and chunked. What you could do, is write a custom signature using the string-tcp engine, *from* #WEBPORTS, regex string = "Server[:]\x20nginx" without the quotes to identify hosts attempting to download the trojan, but if the server type changes or there's a legitimate server of that type, then you either miss the download attempts or drop legitimate traffic. Really good chance of either a false negative or false positive here, resulting in a not so great fidelity signature. (to note, earlier version of this, the binary was mailed and not downloaded from the web)
Once you get the trojaned binary, and click past all the errors to get it to run, now starts the UDP p2p attempts. Unlike some previous versions I've seen, this one hits any number of hosts on random destination ports, but all comes from the same source port (and this may change in some future version). If enabled, signature 4002 will trigger, and the infected host will show up as the "victim", provided the UDP traffic is all allowed to pass in/out. So, depending on what's allowed out past your firewall, and what can come back in, your mileage may vary with this signature.
The following custom signature can be used to identify infected hosts, attempting to connect to the p2p network:
engine = atomic-ip
specify layer 4 protocol = yes
layer 4 protocol = UDP
specify payload inspection = yes
regex string = \xe3[\x0a-\x0f]
specify exact match offset = yes
exact match offset = 1
event count = 50
specify alert interval = yes
alert interval = 10
The p2p connects seem to be somewhat consistent in the traffic from different versions we've seen. It's also rather noisy. This signature will catch the connect attempts, and identify an infected host, but it comes with a price. The sensor has to analyze every UDP packet as we don't specify any source or destination port, so this can be cpu intensive to the sensor.
**WARNING** This custom signature above could affect sensor performance **WARNING**
We're still evaluating releasing the above signature, that detects the p2p attempts and identifies infected hosts, into a signature update.
If we can establish the p2p connections, now we start sending out emails to all sorts of places, providing them links to click and hopefully trojan themselves in a similar fashion. In this case (this variant), signature 3030 fires because of the numerous smtp connections attempted. Hopefully, the only outbound smtp allowed past the firewall is from the mail servers, so here a simple acl or firewall rule will at least help stop the spread and provide a further point to locate infected hosts.
On August 24 the S298 signature update was released which added Storm Worm.
After installing the update I noted quite a few Storm Worm hits showing in the event viewer. Being curious about Storm Worm I clicked on the NSDB link to get the details. The window opened and hung. The IPS viewer showed a Storm Worm hit and the flow blocked. The NSDB link to other signatures works OK.
Interesting that the NSDB link triggers the signature. Not too concerned about this apparently false hit, but wondering if the other hits might be false as well?
I've got this signature running on a couple of sensors now and it is VERY noisy. It also, unfortunately, appears to be poorly conceived since it is only looking for the "Server: nginx" pattern in return web traffic.
The reason why this is a problem is that the nginx server is not just used for serving up trojan EXEs but is in use by HUNDREDS if not THOUSANDS of completely benign sites. It is a shame that you can't push a signature already disabled. We'll have a filter for this signature on our SEM platform before pushing S298 to any production clients.
Cliffnotes: thumbs way down
PS: There are many other good storm signatures out there if you know where to look.
Your post proved the point well. Since it contains "Server: nginx" my IPS is blocking the flow when I try to read this thread. I had to use an external PC to post this response.
I don't like to enable shunning or blocking until I've seen how a signature performs in the real world as it this has bitten us too many times.
There are many ways to tune this signature so it wouldn't trigger on a web page (aka this forum thread) like setting a max inspect length to a reasonable value or breaking up the server reply to only look for the web server type.
But I wouldn't bother tuning this signature since the premise that only the 'bad' guys are using nginx type servers is fatally flawed.
I was already working on modifying this signature when you guys posted.... yes, the current released signature in S298 is very broad and generic. Didn't see any alerts when I initially had it out (prior to S298 release)
There's a tighter signature coming in S299.
I've gotten over 3000 hits from 2 sensors in 6 hours. I wish you guys would use a larger testbed network for these sigs.
Walter, are you going to use a sig similar to this?
Even with S299, I got false positives from NB traffic on port 137 thrown by SigID:5894/1. It appears that NBNS chatter doesn't sit well with this signature.
For instance: one of the false positives triggered on Transaction ID from the NetBios Name Service packet. It seems that the regex is pretty weak (being only two bytes).
The 2 byte regex, while being *very* short, is really the only thing consistent about that p2p traffic. Anything much more into the packet doesn't get you anything better.
The one thing that you might want to do is raise the event count from 50 to say 75. So far, I haven't seen those alerts fire (5894-1) or anyone else say anything about it yet, but its possible that that threshold might not be high enough for you.
Wait a sec, it can use any arbitrary udp port even on non-windows boxes?
Just got a couple of false positives from a dns server. Again, it triggered on Transaction ID.
quite possibly. from what i saw, it's pretty port agile once it starts, and while i did not see that it hit low ports, i don't think that it would be any sort of a far stretch to say that it wouldn't.