Recently my network received an unusual scan, deciphering it has proven difficult. With some outstanding help from the security community, here is my best guess at what the scan is. THE SCAN -------- On 20 May, one of my systems received a unique scan from three systems. The three systems are: jive.rahul.net (192.160.13.4) bug.rahul.net (192.160.13.7) foxtrot.rahul.net (192.160.13.6) The scan signature is exactly the same from all three systems, they scanned ports 1-1024 (see signature below). Of these three systems, one is not active (jive.rahul.net) so we know for certain that at least one system was spoofed. The other two systems (bug and foxtrot) are up. This was confirmed both by hping and by the system owner, Rahul Dhesi However, I do not know if the two live systems were spoofed or not. --- snort snort --- 05/20-17:06:45.061034 192.160.13.4:31337 -> 172.16.1.101:1 TCP TTL:44 TOS:0x10 ID:242 ***FRP** Seq: 0xA1D95 Ack: 0x53 Win: 0x400 . . . 05/20-17:06:58.685879 192.160.13.4:31337 -> 172.16.1.101:1024 TCP TTL:44 TOS:0x10 ID:242 ***FRP** Seq: 0xA1D95 Ack: 0x53 Win: 0x400 --- snip snip --- THE TOOL -------- These packets were crafted by a tool, they were not created by a standard IP stack. We can determine this based on the following: 1. The Seq, Ack, and IP ID numbers are the same for all 1024 packets. An IP stack would have increasing numbers for all three. 2. Note the TCP flags, FIN, RST, and PSH. No standard IP stack would produce such a packet, nor would any IP stack respond with such a packet. Many people commented that this was Back Orrifice because the 31337 port, but that is not the case. First, BO uses UDP by default. Also, Dildog had this to say about the scan: "A bo2k scanner would never come -from- port 31337. Something might scan -you- for sockets listening on 31337, but not the other way around. Regardless, this would have been BO, not BO2K, since BO2K doesn't have a default port. This just looks like a regular port scan to me with a fixed local port." So, this scan was most likely done by a scanner that creates its own packets, but which one? Not nmap: Nmap does not have a FRP flag option. Nor does it use constant Seq, Ack, and IP ID numbers. Not hping: Hping can set most of the functionality of this scan, but it CANNOT set the Seq or Ack number. The best guess we have among the security community is these signatures were created by Libnet, some one has created their own packets. Why Libnet? To qoute Simple Nomad (and Aaron Campbell) "I thought these values looked familar. Took me a bit, but check out the sample programs that come with Libnet. In there you will find id 242, seq a1d95, ack 53, and a ttl of 48. Looks like someone was playing around trying to write a scanner of sorts using the Libnet sample progs as a starting point, and scanned you. So check every machine 4 hops away...." NOTE: I tried the traceroute 4 hops out, it was a router, most likely not our suspect :( So, based on what we know, our best guess is that Libnet was used to create these packets. PURPOSE OF THE SCAN ------------------- This is the most confusing part, the TCP Flags FRP do not generate a response, from open or closed ports. This has been tested on a variety of systems by a several people, inlcuding Max Vision, Dennis Ducamp, and myself. So why run a scan when you won't get any results? I do not know. Maybe someone was testing their coding or scanning skills. Perhaps they were trying "man-in-the-middle" scan techniques. We may never know :( K2 from ADM CREW has an interesting theory "Well, not really, what if your not using the TCP/IP stack of the OS but rather something like libpcap backdoor and are looking for weirdo options ( this will enable you to communicate through onto a firewall'd system )... he dose use libnet to communicate with it so it lead's me to believe that he wants to have a sub-carrier connection that is not normally valid. Source port significance is a really good way to authenticate to a backdoor (ip independent), and can be detected by the trojan early (able to bypass system logging). Exactally, libpcap based backdoor with a libnet based client to pipe i/o to the backdoor... I dont know why they would scan all the ports other then to assume that the backdoor on the host may modulate the port it's listening on... also, a system like this could listen on a port already allocated by the system like even if telnetd is running... you can still contact your backdoor on port 23 because your connect to that port is not valid to anything that the system would have there (your basically going up your libpcap stack insted of the OS), this also helps get past any host firewall." A comment from the system owner Rahul Dhesi, who has been extremely helpful with this analysis. "Hi, I don't see any obvious signs of a break-in on bug.rahul.net or foxtrot.rahul.net. Also, they are running different OSs: foxtrot is SunOS 4.1.3_U1, while bug is FreeBSD 3.4-STABLE. It seems doubtful to me that somebody would break into two machines running different OSs at around the same time. if somebody really broke into one of them, he would likely attack other machines on the network running the same OS. So I'm guessing that all packets were spoofed." Side note, FRP packets are not entered in the state table for FW-1 firewall. Even though the packet may be accepted and logged, the packet would not enter the FW-1 state table. ADDENDUM -------- If you have any comments or words of wisdom you would like to add, please email me at Lance Spitzner . Also, I have posted the raw data (tcpdump/snort binary format>. You can download it at http://www.enteract.com/~lspitz/scan.gz Thanks to the following people for their help and ideas: Nelson Murilo Bill Pennington Aaron Campbell Denis Ducamp Simple Nomad K2 ADM CREW ... and the many others who sent their ideas