The botcc, dshield, comprised, and drop rules at:

http://www.bleedingthreats.net/rules/

had not been updated since November 15. They were supposed to be updated nightly from various sources, including ShadowServer and DShield. I have re-enabled these automatic updates.

Similarly, the firewall rules at:

http://www.bleedingthreats.net/fwrules/

had not been updated since November 15, either. They were supposed to be updated nightly from Spamhaus, ShadowServer, and DShield. I have re-enabled these automatic updates.

If you encounter any problems, please report them.

David.

As you all know there’s been a variant of Storm that’s XOR encrypting it’s P2P traffic. I didn’t put up sigs for this one specifically as we expected it to change and we’d see a flood of differently encrypting variants. All I could put up was a few sigs looking for UDP packets of certain size and frequency, which has only been slightly successful.

So far we’re only seeing that one variant encrypt, and in better than a month it hasn’t changed it’s key. So I’m going ahead and putting up sigs specifically for that variant. Seems it’s going to stay for a while longer.

alert udp $HOME_NET 1024:65535 -> $EXTERNAL_NET 1024:65535 (msg:”BLEEDING-EDGE TROJAN Storm Worm Encrypted Variant 1 Traffic (1)”; dsize:25; content:”|10 a6
d4 c3|”; depth:4; threshold: type both, count 1, seconds 60, track by_src; classtype:trojan-activity; sid:2007701; rev:1;)
alert udp $HOME_NET 1024:65535 -> $EXTERNAL_NET 1024:65535 (msg:”BLEEDING-EDGE TROJAN Storm Worm Encrypted Variant 1 Traffic (2)”; dsize:25; content:”|10 a0
d4 c3|”; depth:4; threshold: type both, count 1, seconds 60, track by_src; classtype:trojan-activity; sid:2007702; rev:1;)

Please let me know how they go!

Matt

Win98 isn’t a security threat in itself… well mostly. But a LOT of spyware and downloaders still use old static User-Agent strings that identify them as Windows 98.

So the following sig is out, it’s thresholded to keep the numbers down in case you run across Win98 boxes you weren’t aware of.

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:”BLEEDING-EDGE POLICY Windows 98 User-Agent Detected - Possible Malware or Non-Updated System”; flow:established,to_server; content:”|0d 0a|User-Agent\: “; content:”Windows 98\;”; within:50; threshold:type limit, count 1, seconds 60, track by_src; classtype:policy-violation; reference:url.doc.bleedingthreats.net/bin/view/Main/Windows98UA; sid:2007695; rev:1;)

Don’t run this sig if you KNOW you have Win98 boxes. If you do, best of luck….

If you Don’t have Win98 boxes then any hits on this sig should be treated as extremely suspicious, likely spyware or a downloader.

Matt

Sent in by Don Jackson from SecureWorks. Good set of sigs.

The tool isn’t all that well written, there are existing toolkits and code that are much better suited, but this is what we’re seeing. No significant activity, but it’s in the press…

Current signatures available here:
http://www.bleedingthreats.net/cgi-bin/viewcvs.cgi/sigs/CURRENT_EVENTS/CURRENT_E-Jihad?view=markup

Please report any issues.

matt

Martin Holste sent in an inspired idea. Since the vast majority of malware executables downloaded via http are small, why don’t we look for anything small? (actual numbers from several malware collections show an average just under 500kb).

Great idea. It won’t catch everything, but it’ll do a lot. The complication is we have to rely on the http header reported size in this case since we can’t really truly look at the stream as a whole. A return header will look something like:

HTTP/1.1 200 OK
Date: Wed, 07 Nov 2007 23:56:05 GMT
Server: Apache
Last-Modified: Wed, 07 Nov 2007 23:55:46 GMT
ETag: “24d26c-79f0-7cf3a470″
Accept-Ranges: bytes
Content-Length: 31216
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Content-Type: application/x-msdos-program

That’s a get request for a binary that the web server knows is a binary by filename. If it didn’t identify it’d say plain/text for the content-type, but otherwise the same.

So… if we set a flow bit from the get if it looks like a binary then a second rule to look for the file size we’ll be able to identify smaller binaries.

One flaw is that many of the servers serving spyware/malware aren’t full blown http servers, and don’t report the valid headers as apache or IIS would. So this certainly won’t be fool-proof, but it’ll be interesting.

The following rules are up for testing:

#Idea by Martin Holste, sigs by Matt Jonkman
# The idea here is that most legitimate exe downloads are more than 1meg, most malicious are far less than 1 meg.
# This is evadable of course, and doesn’t work with non-compliant web servers, but this will catch many…

#First we qualify this as a packet containing the header return info from the get request and is likely binary content
alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:”BLEEDING-EDGE POLICY Likely Binary in HTTP by Type Flowbit”; flow:established,from_server; flowbits:isnotset,BE.http.binary; content:”HTTP/1″; depth:6; content:”|0d 0a|Content-Type\: application/”; nocase; flowbits:noalert; flowbits:set,BE.http.binary; classtype:not-suspicious; sid:2007670; rev:1;)

#next we check that the content-length is less than 7 digits, thus under 1,000,000 bytes.
# note: I re-check for the leading HTTP/1 to make sure we’re still in the header packet, not in the rest of the binary stream
alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:”BLEEDING-EDGE POLICY Binary Download Smaller than 1 MB — Likely Hostile”; flow:established,from_server; flowbits:isset,BE.http.binary; content:”HTTP/1″; depth:6; content:”MZ”; pcre:”/\x0d\x0aContent-Length\: \d{0,6}\x0d\x0a/”; classtype:policy-violation; sid:2007671; rev:2;)

I’ve added the check for the MZ to make sure we’re looking at a real executable.

Also added a flowbits set for this bit to the other rules we have that look for PE headers in downloads, so this second rule will be applied to those dowloads as well.

Please report issues and results!

Matt