So, how did we discover this attack? On February 18, 2002 the Honeynet maintained by team member Michael Clark was attacked. This Honeynet was a virtual Honeynet using VMware and running several instances of Red Hat Linux. A Red Hat Linux 6.2 box (yes, people are still actually hacking these systems) was compromised with the wu-ftpd exploit. Once hacked into, the attacker downloaded the Reverse Challenge binary onto the system and executed it. The binary was downloaded from another hacked system, acting as a distribution center for the attacker. This implies the attacker was breaking into other systems, and downloading the binary from the same central system. You can see here the actual network capture of the command.

Once installed, the attacker began communicating with the hacked honeypot using IP protocol 11. Michael Clark detected this communication when his Honeynet firewall logged the IP traffic. As this was a Honeynet, the traffic was instantly identified as suspect. Intially, we failed to capture the network activity with Snort, as our standard Snort config only looked at TCP, UDP, and ICMP traffic. Based on this finding, we updated our Snort config to capture ALL IP based traffic. Once updated, Snort quickly captured the network activity. You can see here one of the first encoded packets we captured. The binary was then analyzed by the team members and Job de Haas developed a traffic decoder. You can also download the compiled version. We then proceeded to capture all of the attacker's commands, decoding them for analysis. For example, you can see the same encoded command now decoded. In this case, the attacker downloads and installs an IRC bot from the same distribution system, another hacked computer. We then continued to monitor the attacker for several months. When we felt there was nothing more to be learned, we decided to release the binary as the Reverse Challenge.

On an interesting side note, this binary has been seen used in the wild before. Upon first capturing on the binary, we searched Google to see if anyone else had identified similar tools used in the wild. We had one hit, sure enough someone had identified an almost identical tool used on a compromised system. On 30 Aug, 2001, Ryan posted to a maillist asking about rootshells and NVP activity. This tool is definitely being used in the wild, but has seen little reported activity. This is either due to the fact that it is not widely distributed, or that system administrators are simply not looking for this activity, as they are focused on primarily TCP, UDP, and ICMP (a trap that even we had fallen into).

So, what did the attacker use our systems for? Why was he going through all this trouble? That will be for you to determine in a future Scan of the Month challenge :)