Threat Level: green Handler on Duty: Rob VandenBrink

SANS ISC InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Spamming as 'terror' tactic

Published: 2006-05-01
Last Updated: 2006-05-02 15:08:13 UTC
by Jim Clausing (Version: 2)
0 comment(s)
We received several e-mails today from folks who had received spam claiming that a database containing customer info at Blue Security had been compromised.  The folks there claim that this is not the case and that it is a scare campaign and the spammer is using lists already at their disposal.  There official statement can be found here.

Update:  It appears that bluesecurity.com has been under a DoS and/or DNS hijacking attack since this story was posted.

----------------------------
Jim Clausing, jclausing //at// isc.sans.org
Keywords:
0 comment(s)

Spaf on reexamining

Published: 2006-05-01
Last Updated: 2006-05-02 15:07:19 UTC
by Jim Clausing (Version: 1)
0 comment(s)
With much of the world observing holidays today, the mail has been a little slow except for the P2P malware using tcp port 8.  That gives me the opportunity to mention a couple of other things that might be of interest to our readers.  Now, some consider me a neo-luddite for not embracing blogs and such, but one of these days maybe I'll join the 21st century and set up an RSS reader.  Anyway, a week or so ago, I came across this essay from Dr. Gene Spafford at Purdue.  He's one of those really smart people whose opinions carry some weight with me and always gets me thinking (Bruce Schneier is another one, I've subscribed to his Crypto-Gram newsletter, I believe, since the first issue).  It is good to periodically reexamine the roots of our "best practices" and see if the underlying assumptions still apply.

-----------------------------------
Jim Clausing, jclausing //at// isc.sans.org
Keywords:
0 comment(s)

As the Bot Turns

Published: 2006-05-01
Last Updated: 2006-05-01 21:00:50 UTC
by Scott Fendley (Version: 5)
0 comment(s)
The below was sent to us as well as some of the ISACs around the net tonight. As there is quite a bit of information being conveyed by the author, I am going to leave the majority of the advisory as originally written.  I will note that this started with a click happy user on AIM to the best of our knowledge.

---snip---
A bot was seen spreading via AOL Instant Messenger (AIM) earlier today that appears to be using "encrypted"[1] peer-to-peer (P2P - possibly Waste?) as the Command and Control (C&C) mechanism. The bots communicate with each other via port 8/TCP.

The bot does not use DNS to find any C&C. It also does not use any human readable strings in its client/server communication. Therefore, many IDS measures will not help you detect infected hosts on your network. Flow analysis and/or tcpdump looking for mysterious port 8/TCP traffic seems to be the best way to detect these infections on your network.

I realize that phatbot has been able to use Waste as the C&C for several years. However, I remember finding these botnets years ago, and the bots involved, and they typically were 600KB or more in size. The bot involved here is comparatively lean at 173KB.

Info about the sample I obtained:
MD5: 74600e5bc19538a3b6a0b4086f4e0053
Installation Location (when run): %WINDIR%\System32\mstc.exe
WinXP Firewall: Grants itself an exception called "null", which allows inbound 8/tcp from anywhere. This was done without the user notification pop-up (it likely edited the registry entry directly).

The file distributed via the AIM link and %WINDIR%\System32\mstc.exe are identical - no other files are dropped, etc.

I infected a test computer with the binary. It tried to connect to port 8/tcp on 22 different IP addresses. (Note that these are most likely the "seeds" of the P2P network that were coded into the version of the binary that I downloaded.) Only four of the IP addresses responded that they were listening on 8/tcp.

My lab computer tried to contact each of the 22 IP addresses many times (I left it infected for about 15 minutes with a firewall in place that blocked all incoming packets, solicited or otherwise). Since it tried to contact each of these many times, and not any other IP addresses, I feel it is fairly safe to guess it was not randomly selecting IPs to obscure "the real C&Cs".

Anyhow, after 15 minutes of firewalling off all inbound packets altogether (even SYN/ACKs) to my infected lab computer, I lifted the incoming IP restriction. The first host my lab computer connected to on 8/tcp started a relatively short connection (10-12 packets each way), and nothing was in cleartext. In the middle of the TCP conversation, that same host connected to port 8/tcp on my host (the malware holds that port open). The connection from them to me was simply a three-way handshake, immediately followed by FIN/ACKs from them  then me. It then closed my connection to it altogether, via FIN/ACKs again.

My host then tried several other IPs (still in the list of 22, with only four of them online), and this time, connected successfully to a different host. The connection lasted for a couple of minutes before I pulled the plug.

There was more communication this time around. During the connection, the remote host connected to 8/tcp on me just like the other one did (three-way handshake, then FIN/ACK, just like before). The initial connection from  my host to theirs continued afterward. One of the packets from the remote host contained a full 1460 bytes of data. (Other packets to/from 8/tcp on infected hosts thus far had contained 64 bytes of data or less.) There was no SSL/TLS negotiation evident, and again, the contents were not human readable. I haven't taken the time yet to see if it's something simple like XOR or Base64. I suspect the content was an updated list of other infected hosts.

While still connected to that host, my bot still tried connecting to others (not common for a traditional botnet, but expected for a P2P connection). It connected successfully to a third host. My host did to that host as the others above did to it - complete the three-way handshake, then ended it with FIN ACKs. It then connected to another host that was NOT on the initial seed list. (My theory is that my host learned of this one from another bot) After that, I turned it off, so that I could write this.

Moral of the story: Prepare to watch for 8/tcp flows for a while. Unless I'm wrong, this botnet should be able to stick around for a while.

[1] I am using "encrypted" in quotes because I have not identified the protocol - but it is not human-readable. I'm sorry if this sounds FUD-like, but I wanted to get the word out sometime *before* I had done hours of analysis!
-------Snip-------

Update 1:

Earlier Sunday, Symantec has posted a write-up about this particular binary.  It is located at http://www.sarc.com/avcenter/venc/data/w32.nugache.a@mm.html. Please note that they do not have any mention about the P2P traffic noted above.  There is more analysis being done on malware by the various AV companies and others in our malware analysis team.

I expect that this binary will be detected by most AV companies quickly (today I hope) and slow its spread tremendously.  However, I also expect that this is a signal that the botnet writers are entering a new generation of  development and capabilities.  Those of us that are tasked with defending our various networks will need to find a new and better game plan to spot and counter these encrypted/p2p based botnets.

Update 2:

A few hours ago, Bleeding Snort issued some rules to help people detect this botnet on their network.  The signatures are located at bleedingsnort.com.  (Remember that bleedingsnort does update their signatures as more information is gathered.  You may want to go to bleedingsnort.com and download the most recent version instead of the one linked here. The current link is for 1.9, and 1.10 may be out sooner or later.)

Update 4:

In update 3, we provided the initial list of IPs that seemed to be hard coded in this malware.  Since that time, numerous other peers have been identified.  As such, it no longer makes sense to post a list of IPs.  The best defense would to be to monitor activity in your flows for tcp/8, update antivirus, and/or use the above snort signature to detect this activity.



--
Scott Fendley
Handler on Duty


Keywords:
0 comment(s)

SANS Top 20 Spring Update

Published: 2006-05-01
Last Updated: 2006-05-01 18:18:39 UTC
by Jim Clausing (Version: 1)
0 comment(s)
SANS has announced its spring 2006 update to the "Top 20" list.  The high level discussion is here and the technical details are here.  The big news (which isn't big news to our readers) is the increasing visibility of malware targetting Mac OS X.
Keywords:
0 comment(s)
Diary Archives