Reference

Victim host: 172.16.183.2
Attacker host: 203.173.144.50
"Foo" drop site: 216.242.103.2 or 11.11.11.11

The Questions:

1. What is the attacker's IP address?

   Attacker's IP address is 203.173.144.50. It is the first packet sent by the NVP backdoor program, as pointed out in the Reverse Challenge analysis. Several other packets are sent to random IP addresses to hide the tracks.

   Also, attacker used the site 216.242.103.2 to load the "foo" program. It was (somewhat hastily...) obfuscated by me into 11.11.11.11 while preparing the contest to protect the privacy of the site.

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

   After establishing the session with "the-binary", attacker looks at the bind 8.x/9.x DNS configuration files using the

   grep -i "zone" /etc/named.conf

   We can only hypothesize why this is done. Our opinion is that the intruder needed an active DNS server for some spam-related activity. Thus, he was checking the DNS configuration files for signs that the machine is a DNS server responsible for some Internet-visible domain and not just the local domain. In this case, the attacker got the machine that is only responsible for localhost resolution (zone "0.0.127.in-addr.arpa") It is also possible that he was looking for zone files to discover more machines connected to the same network.

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?

This question refers to the bug in the binary, found during the Project analysis. Some of the Reverse Challenge participants has also pointed this out (e.g. here). "The-binary" incorrectly encrypts the outgoing packets so that part of the payload is clear text while the rest is encrypted. The incoming packets from the remote handler to "the-binary" are fully encrypted.

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?

To summarize, "foo" (or "ttserve") connects to an AOL ICQ website and scans through web pages looking for email addresses. Upon collecting a predefined number of addresses (100), it connects via UDP to an IP address (hardcoded in the program, same was used to download the "foo") port 53413 and transmits its findings.

When launched, "foo" forks into background under the faked process name (the process name "(nfsiod)" sounds UNIX-ish enough to hide from careless system admins) and sends a request (string "GU") to "home" IP address via UDP port 53413. Whatever program runs on the remote machine, responds with "DU_icq_id_number_". That makes the "foo" start grabbing the web pages from the ICQ AOL web site in a sequential order starting from the received ICQ ID (UIN) using the URL such as this one: "http://web.icq.com/wwp?Uin=_icq_id_number_".

The program parses and stores email addresses for future processing. If a "DIE" command is received instead of "DU_icq_id_number_", the program exits.

After 100 email addresses are collected, the "foo" sends another request to its handler via UDP port 53413. It says "SE_icq_id_number_" (same UIN as in the previous DU command) and then starts sending the acquired email addresses. After the transmission is completed the "foo" expects to hear "GOT" from the remote end or it will attempt retransmission (up to 10 times). Upon hearing "GOT", "foo" politely asks to do more work - namely, it sends another "GU" request for the new initial ICQ ID number.

In our opinion, the "foo" was coded by a somewhat talented amateur. The author thought about some advanced aspects (like designing the whole UDP communication protocol) and at the same time missed the obvious (redoing the DNS lookups for every HTTP access to the ICQ web server).

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

   "Foo" (renamed into "ttserve") is launched by an attacker to start collecting email addresses from the ICQ site. It is well-known that one can safely remove (/bin/rm) the executable and the process will still be running in the background. In fact, the way to recover the program is to copy the process memory image found in "/proc//exe" back to disk.

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

   This question is clearly an open-ended one. Honeynet Project has received no indication of further activity involving "foo".It is possible to use such an email database for spamming, selling to spammers, distributing viruses, attacking ICQ users via email malware or "social engineering" or other nefarious purposes.

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?

All Honeynet Project Data Capture capabilities are configured to capture all packets traversing the network and not only TCP, UDP or ICMP packets. Thus the detection of the NVP (protocol 11) binary was successful and this challenge was made possible.

However, typical IDS is often not configured to look for unusual protocol signatures. Thus, it is highly likely that in production environment this activity would have gone undetected.

As for prevention, the exercise shows the clear advantage of a "default-deny" policy for the firewall. "Block everything that is not expressly allowed" in both directions at the firewall is a very sound security policy. Making sure that client machines are not serving data and servers are not initiating connections is relatively straightforward and will add a lot to an organization security.

Tools used:

Linux:

• tcpdump
• tcpflow
• ethereal
• file
• strings
• Reverse Challenge decoder