[unisog] Apparent "encrypted" P2P botnet using port 8/tcp
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 188.8.131.52.http > A.B.C.D.8: S
> 1388829994:1388829994(0) ack 1733890823 win 5840 <mss 1460>
> inetnum: 184.108.40.206 - 220.127.116.11
> 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
> Jonathan Glass
> Information Security Engineer III
> OIT Information Security
> Georgia Institute of Technology
> Atlanta, Georgia 30332-0700
> 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" 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.
> -----BEGIN PGP PUBLIC KEY BLOCK-----
> Version: PGP 8.1
> -----END PGP PUBLIC KEY BLOCK-----
> unisog mailing list
> unisog at lists.sans.org
More information about the unisog