disseminated about our network perimeter and defense.

For the purposes of this investigation, a TCP retry is defined as one that has the same source and destination hosts, ports, and TCP sequence numbers as the initial attempt. The number of successive retries and the backoff time between retries is TCP/IP stack dependent.

Retries are associated with source code that uses socket connections. In other words, the source code is written so that the socket calls go through the proper layers of the TCP/IP stack. In this case, the socket uses the TCP and IP layers to form the appropriate headers and values for those headers.

The alternative is known as a raw socket, which does not use the TCP/IP stack to form the packet. Instead, the programmer is responsible for supplying the appropriate headers and data. This packet is written directly to the network interface card. Many scanners such as nmap and hping2 use raw sockets.

This scan manifested multiple retries when the destination host was unresponsive. What does this mean? That regular and not raw sockets were used? First, the scanning host really wanted to maximize the opportunity to elicit a response from the destination host—more indicative of scan behavior than flood behavior. Flood behavior would likely send packets using raw sockets as fast as possible. Second, raw sockets require an additional level of complexity because they require the installation of an application programming interface for packet capture on the scanning host—either winpcap for Windows or libpcap for UNIX. The use of standard sockets simplifies the setup required to scan.

Summary

The determination is that this was a very efficient scan looking for hosts listening on TCP port 27374. The scan was conducted by zombie hosts, which were mostly Windows hosts. It appears that hosts with other operating systems were involved, yet they played only a small part in the percentage of scanning hosts. The significance of this is that the means of infection of the zombie hosts does not appear to be Windows-specific. It is unknown whether the percentage of Windows-based scanning hosts and the percentage of scanning hosts that have other operating systems actually mirror the percentage of Windows versus all other operating systems that are found on the Internet. The implication here would be that the operating systems of the zombie hosts might be consistent with a normal distribution found on the Internet. Another implication is that the percentage of zombie hosts having a particular operating system might represent the ease of compromise for that operating system.

Is the sole purpose of this scan to efficiently identify hosts listening on port 27374? It can be surmised that not all of the zombie hosts were exploited by the SubSeven Trojan. SubSeven is a Windows-based Trojan, and it appeared that not all the zombie hosts were Windows. Perhaps there are SubSeven Trojans that have been developed for other operating systems as well. Whatever the exploit used to "own" the zombies, the "commander" knew about the owned zombie hosts and had no need to scan to find them. Is it possible that this scan search was to find other candidate zombies owned by another commander? This assumes that these new zombie hosts would be Windows-based because they would be listening at the SubSeven port. The new zombies may be used for activity other than the scanning that was witnessed at our site.

Whatever the purpose of this scan, it looks like a pretty sophisticated way to maximize a scan.

In a couple of minutes, over 30,000 destination hosts were scanned. This activity demonstrates the evolving sophistication in zombie activity and malicious code in general, as we have witnessed with Code Red and nimda worms. It also shows the burgeoning number of exploited hosts that can be marshaled into active duty because of the innocence or disbelief of home users, paired with always-on connectivity, and operating systems and applications that come ready-assembled for looting and pillaging.