Answers to Questions

1. What is the attacker's IP address?

All responses to the initial IP protocol 11 communications are sent to the IP address 203.173.173.50. However, the UDP communication, done after the the initial attack, and the installation of foo, is between the honeypot and 216.242.103.2. (As an aside, this address is also where the attacker retrieves the foo binary from). From this evidence, the attacker must have access to the latter IP address.

2. What is the attacker doing first? What do you think is his/her motivation for doing this?

After initializing the communication, the attacker performs grep zone /etc/named.conf. My guess is that the attacker is checking whether the machine has authority for any domains - if so, the attacker would be able to alter the DNS, at least as it appears to the machines for which it is a name server. As it turns out, the name daemon has authority only over the localhost.

3. Why there is some readable text in packets #17-#25 (and some others), but not in packets #15-#16 (and several others)? What differentiates these groups of packets from each other?

I believe this an error in the encoding function, as described by several people in the Reverse Challenge (I particularly liked Chris Eagle's explanation). Packets are padded with supposedly random information - however, due to buffer overlap problems, this random information is often the unencoded version of what has been sent encoded previously.

It seems to me that all packets sent by the honeypot machine have some readable text, whereas all sent in the other direction do not have any readable text.

4. What is the purpose of 'foo'? Can you provide more insights about the internal workings of 'foo'? Do you think that 'foo' was coded by a good programmer or by an amateur?

I believe foo to be a general purpose attacker's tool - in this case, my assumption is that the attacker used it for email harvesting, but I suspect it has a number of other features, as there a number of unused commands (GOT, DIE and SE), the purposes of which have not been investigated here (although the purpose of DIE is clear, both from its name, and the code).

Initially, foo renames itself to '(nfsiod)', to hide itself from anyone reading the output of e.g. ps. It then becomes a daemon. Once daemon status is achieved, it sends a UDP communication to 212.242.103.2, containing only the data "GU\n". On receipt of this signal, the attacker responds with the request "DU9207100". At this point, the UDP socket is closed.

The request "DU9207100" causes foo to make 100 HTTP requests to web.icq.com, asking for the pages for users with ids in the range 9207100-9207199. These pages are then processed by foo, looking for the pattern "mailto:[^"]*".

It appears to me that foo was coded by someone who understands the rudimentaries of socket programming, and is aware of IP spoofing etc. I would hesitate to criticise the attacker's coding, as, from my analysis, foo does what is expected of it.

On the other hand, there are a number of similarities between foo and the-binary of the Reverse Challenge, that suggest that the same programmer was responsible for both (possibly, that programmer is also the attacker). These similarities, such as the same compilation platform, similar (if not identical) compilation options (statically linked, stripped, inline functions) are indicative, to me, of a high likelihood that the same programmer wrote both.

5. What is the purpose of './ttserve ; rm -rf /tmp/ttserve' as done by the attacker?

ttserve, or foo runs as a daemon (changing its name to "(nfsiod)" in the process), and so here it seems the attacker is running the ttserve binary, and then removing the executable, presumably to avoid the possibility of it being detected.

6. How do you think the attacker will use the results of his activity involving 'foo'?

The attacker is clearly harvesting email addresses from web.icq.com. Why he/she should want to do this is unclear - possibly for sales to spam merchants? Furthermore, I have yet to identify any mechanism for email address retrieval (although possibly the honeypot was disconnected before the attacker had a chance to retrieve them - after all, the commands SE and GOT were unused).

Bonus Question: If you administer a network, would you have caught such NVP backdoor communication? If yes, how? If you do not administer a network, what do you think is the best way to prevent such communication from happening and/or detect it?

I don't run a commercial network, but I do maintain our internal home network, where the gateway to the outside world is an adsl modem, connected to an OpenBSD firewall/gateway. Communication is only allowed from the outside world if, and only if, it has been initiated from the outside world. If I needed to allow further access to, e.g., a webserver, I would specifically open port 80 over tcp. But everything is locked down by default, unless I decide to unlock it. While a home network is significantly easier to administrate than a business network, applying the same principles (everything locked down by default unless specifically allowed) would mean that a business network would not let through NVP packets.