Ok, here's my shot:

> ### QUESTION 1:  What is the scan attempting to determine?

The attacker is sending a few characters per packet to the server in an
attempt to make a web request (this is known due to destination port 80,
and the server's response).  The technique of sending a few characters per
packet (in an attempt to bypass intrusion detection systems that have not
implemented stream reassembly) is called 'session splicing'.

If you look at the data in each packet, you'll see that following request
is sent:

HEAD /  HTT<backspace><CRLF><CRLF>

Note that this is actually a malformed request (the HTTP/1.0 was severed).
Had the scan suceeded, the server would have returned the main home page
(if it existed), which would include a few server headers--one in
particular that may indicate what software and version the webserver is
running (the 'Server' header).


> ### QUESTION 2:  What is unique about the scan methodology?

As mentioned above, sending a few characters a time prevents ID systems
that do not perform stream reassembly from correctly finding a valid
signature in the packet.

> ### QUESTION 3:  Can you name the scanning tool?

NOTE: We now belive that the scanning tool was a simple Windows
telnet connection.  At first we did not believe this, as Windows
telnet uses single character mode, and we could not get several
characters into a single packet.  However, after more testing we did
confirm it was possilbe.

> BONUS QUESTION:  What known vulnerabilities exist on the honeypot?

Looking at the returned headers, we see it's an IIS 4.0 server, which
means it's running on Windows NT.  Some guesses as too known
vulnerabilities would include RDS, HTR file fragment reading, and the
Unicode bug.

- rfp