[unisog] Apparent "encrypted" P2P botnet using port 8/tcp

Dave Ellingsberg dave.ellingsberg at csu.mnscu.edu
Sun Apr 30 12:09:17 GMT 2006


 Brian,

do you have the list of ips your seeing connections to?  and is this
random port to port 8 or is it 8 to 8?

bigfoot.
 


The above info is strictly my interpetation and does not reflect the
attitudes or opinions of my employers.  If this message contains
anything that may or may not reflect a proper legal opinion, please
consult higher authorities for a proper legal opinion!    

**************************************************************************
Dave Ellingsberg        WAN Specialist
Cell phone  1 507 381 2051 try my home number first
Home phone  1 507 354 8772
Ellingda at csu.mnscu.edu
Office Phone 507-354-8772
http://www.net.mnscu.edu/news/
**********************************************	 
    It will be a great day when our schools have
    all the money they need and the Twins
     have to hold a bake sale to build a new stadium.




>>>eckman at umn.edu 04/29 8:19 pm >>> 
Some malware was seen spreading via AOL Instant Messenger (AIM) earlier 
today that appears to be using "encrypted"[1] peer-to-peer (possibly 
Waste?) as the Command and Control (C&C) mechanism. Infected hosts 
communicate with each other via port 8/TCP. 
 
The "bot" (for lack of a better term) does not use DNS to find any C&C. 
It also does not use any human readable strings in its 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 others in the list above, before connecting 
to the same host again. The same thing happened as above (my bot 
connected to it, it connected to me, it "hung up"). 
 
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. 
 
Brian 
-- 
Brian Eckman 
Security Analyst 
OIT Security and Assurance 
University of Minnesota 
 
 
[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! 
 
unisog mailing list 
unisog at lists.sans.org 
http://www.dshield.org/mailman/listinfo/unisog 


More information about the unisog mailing list