All responses to the initial IP protocol 11 communications are sent to the IP address 220.127.116.11. However, the UDP communication, done after the the initial attack, and the installation of foo, is between the honeypot and 18.104.22.168. (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.
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.
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.
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 22.214.171.124, 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.
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
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).
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.