An idlescan is a type of port scan, used in the electronic wilds of the Net to determine a remote machine's vulnerabilities. Port scanning a machine, as that node will tell you, is the practice of attempting to make contact with each of the myriad TCP ports on a remote networked computer. The purpose is to determine which ports are actually 'open,' or listening for traffic.

The problem with port scans is that they are rather obvious. Modern IDS are good enough to catch portscans buried in huge mounds of traffic through statistical and pattern-matching techniques. Modern computers are fast enough to allow intrusion detection sieves of larger and larger size to be run more and more quickly. What is a determined recon hacker to do?

Well, ideally, you'd like your port scan of the (suspecting) host to be untraceable to you. It's not so difficult to craft packets that don't point back to you - but it's difficult to get any information out of them. Enter the idlescan.

Essentially, the idlescan depends on several pieces of information:

  • The SYN ACK handshake of TCP/IP
  • The fact that each packet of data sent out by an internet-connected host contains a 'serial number' known as the 'fragment ID'
  • The less-and-less common fact that some operating systems and TCP/IP stacks issue those fragments in an incremental manner, or predictable pattern
  • The ability to craft a spoofed return-address packet

Now, in order to understand the idlescan, you need to know a couple of things about how TCP/IP works. Specifically, the SYN ACK handshake. When a computer (let's call it a client) wants to open communications with another computer (which we'll dub the server), it sends a particular type of packet called a SYN (synchronize) packet to the appropriate port on the server. The server, if it is willing and able to open communications on that port, will send a SYN ACK packet back (synchronize acknowledge) to the sender of the SYN packet. At this point, they are ready to open data communication.

If, however, the port on the server is closed, it will do one of two things: either it will send no data back at all, or it will send a RST packet indicating that the session request has been rejected. This is how a standard port scan determines if the port is open or not, by checking for the SYN ACK or RST packet (or lack of response). The idlescan depends on one particular difference in behavior: a machine which receives an unsolicited SYN ACK (that is, an acknowledgement of a session request that it didn't make) will also send a RST, indicating the session should not continue. However, machines that receive unsolicited RST packets simply ignore them. This is the key to the idlescan.

What an idlescan does is find an unsuspecting machine (called the zombie) to use as a patsy. In order to determine if a server port is open, a client running idlescan does the following things, in order:

  1. Sends a SYN to the zombie on an open port and records the fragment ID of the responding SYN ACK packet.
  2. Sends a SYN to the target server, with a faked return address of the zombie's open port
  3. Sends another SYN to the zombie and checks the fragment ID on the SYN ACK.
Now, if the target server's port was open, it would have sent a SYN ACK to the zombie's open port, since it assumed the SYN packet originated at the zombie. The zombie, receiving a SYN ACK which it didn't ask for, will send a RST to the server - and that RST will increment the zombie's fragment ID! The server then closes communication. The client (attacker) then sends its second SYN to the zombie and compares fragment IDs. The fragment ID has incremented twice.

If, however, the target server's port was closed, it would have sent a RST packet to the zombie's open port - and the zombie would have simply ignored it. Then, when the client attacker sends its second SYN, the fragment ID (assuming no other traffic has hit the zombie since the first check) will have only incremented once.

Note that during this entire exchange, not one packet that identifies the attacker has been sent to the target server. If the attacker chooses the zombie carefully, it will be impossible for the target to access its logs to determine who was sending intermingled SYNs to the zombie - and anonymity is preserved. In the target's logs, it will appear that the zombie has been doing the port scanning.

This technique has its negatives as well. Increasingly, network software is being modified to use non-incremental (and in some cases, entirely random) fragment IDs. As long as the fragment numbering utilizes a pattern that the attacker can recognize and mimic, the technique will still work - but random (or pseudo-random) number streams will defeat it. Also, it requires an available zombie - although that's not usually a problem. Finally, it *does* leave a port scan in the logs, and can trip active defenses that might, for example, block all connections to the zombie during or as a result of the scan - which might alert the zombie that something is wrong, if it regularly talks to the target.

Although the technique may sound complex, the (in)famous *nix tool Nmap can do it for you in one quick command line - all you need do is identify the target and zombie. There are various other script kiddie tools to perform the scan out there as well. Recognizing them and differentiating them from 'normal' port scans is extremely difficult without access to the logs of the zombie, but some ID systems claim to be able to do so by carefully looking at timing and event patterns during the scan.

Much of the information in this post was taken from, various bits of googled data, and watching the damn things happen.

Log in or registerto write something here or to contact authors.