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

Brian Eckman eckman at umn.edu
Sun Apr 30 01:19:26 GMT 2006


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!


More information about the unisog mailing list