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