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

Fixer fixer at gci.net
Sun Apr 30 07:01:58 GMT 2006

Can you just post the traffic here?  It'd be nice to see it so we know 
what to look for...


Jonathan Glass wrote:
> 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 > A.B.C.D.8: S 
> 1388829994:1388829994(0) ack 1733890823 win 5840 <mss 1460>
> inetnum: -
> 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
> 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
> ------------------------------------------------------------------------
> Version: PGP 8.1
> mQGiBEGblgURBADUPDNwX+TFOKas0Dt5KzyZvoldvjIEREWvlLacRB5m3zLcN33L
> zUqrLPWQ0Yr0v7g/80ovVpvsUZ8I+ZfBJRiNfOBo01FlE56tbCUSBhpmk9zt/tAT
> 0CpQVvjSQDainL2Xtwuy2lhCOL3j2XFOCV+wSba2YsULTJa4N81J7pUm7QCg/2QK
> id30UgqEAbgaYoBpU+wGTy0D+wY71J8+8jGlUSv+c2a08k7P+n2QtueQuqIFTOyq
> KM1IgszFILVNK5E459KB/8iMrhuClJS45Hcf2E65zgu4wliCukraEo0XWj+4kKJj
> 4YbSeYAi2d+dREy+I10oI2ycgVSHWb+4GDa/2opJ16VTsNrJQmFoI/dCUW2aGfC3
> GQW1A/9z8kni1V+QKZCg+ozvyNjJDUWAqZkJTZc1qNlRWB0vhbJ93Y4tDuvYH9tn
> z+A+bmNxk86LNVbFy5widxWWnHNbE28LrXU373prbj/gUKAIFZC3C0puxIqy2S5/
> 91MhGEBqfSu8vUS7aCKyf+93pp2C7tlgP3gXuFBy/i+pwTNsB7QxSm9uYXRoYW4g
> Qi4gR2xhc3MgPGpvbmF0aGFuLmdsYXNzQG9pdC5nYXRlY2guZWR1PokAfAQQEQIA
> PAUCQ0LO7AcLCQgHAwIKAhkBGRhsZGFwOi8va2V5c2VydmVyLnBncC5jb20FGwMA
> lxC4m8pXrXyMZwf/Y7yGiGzi6jc+RV4n2O7WBfyDf//oTFeIo0Qmo3eO/WWe3lhw
> xPz6X9jO8I6PrugLdh+FWK1s/1TO+8rBW3rRfpXyL5bDXeBiVc1gA+GPjyt8mU20
> pOW8RNJUIOomlVovGM3MSEEpY04CpOhposTuUUXf8XBPmK8dCPdMpbo8w1bmaKW6
> Xs4kJropZyPQ8XrbLa7PTJSYwy9X+7myF7/P1jSwrOUCWE+Z8fZbtfB9lo2RNp1h
> NHr1zRpSaM5F8ezTi/0iJ2MncXVnA9LlO+JS7fg9M+MDv2ymL0p02QqOwyuk3VjI
> cTbYRnGHYyAw0ETzPLpC84FZ83nRvusoOuJw9bkCDQRBm5YFEAgA9kJXtwh/CBdy
> orrWqULzBej5UxE5T7bxbrlLOCDaAadWoxTpj0BV89AHxstDqZSt90xkhkn4DIO9
> ZekX1KHTUPj1WV/cdlJPPT2N286Z4VeSWc39uK50T8X8dryDxUcwYc58yWb/Ffm7
> /ZFexwGq01uejaClcjrUGvC/RgBYK+X0iP1YTknbzSC0neSRBzZrM2w4DUUdD3yI
> sxx8Wy2O9vPJI8BD8KVbGI2Ou1WMuF040zT9fBdXQ6MdGGzeMyEstSr/POGxKUAY
> EY18hKcKctaGxAMZyAcpesqVDNmWn6vQClCbAkbTCD1mpF1Bn5x8vYlLIhkmuqui
> XsNV6TILOwACAgf7BmP2xaPgkbVCLtcEheyByv083dUuLGjsiUAaykDQ42oUP1aB
> /X+iQgUf8Pmt9iK/3wfsA++inP/NKejB2Bs+sL86LSo74zqnMJDKdj7OJyWFoITR
> VPOvqGBIXIwzfK20L90/bCZndPx8THTAuNc3GkX3kz5lszkG8xPDFar5Nt6WS8oR
> xvWxLdiZP9n/5Xo2eGo54qFEFcU0msRGgKgRo/kA9mdxx5DlbOU1c2qPFobJINjh
> 0Ih6Nv8szicS6z7kfmFd/RQ1ovKjVEBaI6f2kGfwW/4MNKphSFWjMj9lTLmpXjRD
> dSryYHi5JL5nIf4=
> =9Xyp
> ------------------------------------------------------------------------
> _______________________________________________
> unisog mailing list
> unisog at lists.sans.org
> http://www.dshield.org/mailman/listinfo/unisog

More information about the unisog mailing list