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

Jonathan Glass jonathan.glass at oit.gatech.edu
Sun Apr 30 03:00:05 GMT 2006


I'm seeing a Chinese host scanning our network for this port.  Anybody 
on Unisog doing research into this from China? Only a few hosts have 
issued ACKs.  Brian, can I get a copy of the traffic you're seeing?

22:54:35.086851 IP 218.16.120.122.http > A.B.C.D.8: S 
1388829994:1388829994(0) ack 1733890823 win 5840 <mss 1460>


inetnum:      218.13.0.0 - 218.18.255.255
netname:      CHINANET-GD
descr:        CHINANET Guangdong province network
descr:        Data Communication Division
descr:        China Telecom
country:      CN
admin-c:      CH93-AP
tech-c:       IC83-AP
mnt-by:       MAINT-CHINANET
mnt-lower:    MAINT-CHINANET-GD
status:       ALLOCATED NON-PORTABLE
changed:      hostmaster at ns.chinanet.cn.net 20010528
changed:      hm-changed at apnic.net 20041207
source:       APNIC


Thanks

Jonathan Glass
Information Security Engineer III
OIT Information Security
Georgia Institute of Technology
Atlanta, Georgia 30332-0700
404-385-6900
PGP KeyID: 0xAB50FF20
PGP Fingerprint: 3CD2 1BC6 4485 720B AB45  FF3E 8B3B D6F5 AB50 FF20

Brian Eckman wrote:
> 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

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Jonathan B. Glass.asc
Url: http://www.dshield.org/pipermail/unisog/attachments/20060429/1346bcc3/JonathanB.Glass.bat


More information about the unisog mailing list