- Introduction to Nmap Idle Scan
- Finding a zombie device
- Executing the Nmap Idle Scan
- Conclusion
- Related articles
Introduction to Nmap Idle Scan
Last two tutorials published on LinuxHint about Nmap were focused on stealthy scan methods including SYN scan, NULL and Xmas scan. While these methods are easily detected by firewalls and Intrusion Detection Systems they are a formidable way to didactically learn a little about the Internet Model or Internet Protocol Suite, these readings are also a must before learning the theory behind the Idle Scan, but not a must to learn how to apply it practically.
The Idle Scan explained in this tutorial is a more sophisticated technique using a shield (called Zombie) between the attacker and the target, if the scan is detected by a defense system (firewall or IDS) it will blame an intermediate device (zombie) rather than the attacker computer.
The attack basically consists on forging the shield or intermediate device. It is important to highlight the most important step in this type of attack is not to carry it out against the target but to find the zombie device. This article won’t focus on defensive method, for defensive techniques against this attack you can access for free to the relevant section in the book Intrusion Prevention and Active Response: Deploying Network and Host IPS.
Additionally to the Internet Protocol Suite aspects described at Nmap Basics, Nmap Stealth Scan and Xmas Scan to understand how the Idle Scan works you must know what an IP ID is. Every TCP datagram sent has a unique temporary ID which allows fragmentation and posterior reassembly of fragmented packets based on that ID, called IP ID. The IP ID will incrementally grow in accordance to the number of packets sent, therefore based on the IP ID number you can learn the quantity of packets sent by a device.
When you send an unsolicited SYN/ACK packet the response will be a RST packet to reset the connection, this RST packet will contain the IP ID number. If first you send an unsolicited SYN/ACK packet to a zombie device, it will respond with an RST packet showing its IP ID, the second step is to forge this IP ID to send a forged SYN packet to the target, making it believe you are the Zombie, the target will respond (or not) to the zombie, in the third step you send a new SYN/ACK to the zombie to get a RST packet again to analyze the IP ID increase.
Open ports:
| STEP 1 Send unsolicited SYN/ACK to the zombie device to get an RST packet showing the zombie IP ID. |
STEP 2 Send a forged SYN packet posing as zombie, making the target to respond an unsolicited SYN/ACK to the zombie, making it answering a new updated RST. |
STEP 3 Send a new unsolicited SYN/ACK to the zombie in order to receive a RST packet to analyze its new updated IP ID. |
 |
 |
 |
If the target’s port is open it will answer the zombie device with a SYN/ACK packet encouraging the zombie to answer with an RST packet increasing it’s IP ID. Then, when the attacker sends a SYN/ACK again to the zombie the IP ID will be increased +2 as shown in the table above.
If the port is closed the target won’t send a SYN/ACK packet to the zombie but an RST and it’s IP ID will remain the same, when the attacker sends a new ACK/SYN to the zombie to check its IP ID it will be increased only +1 (due to the ACK/SYN sent by the zombie, without increase by provoked by the target). See the table below.
Closed ports:
| STEP 1
Same as above |
STEP 2
In this case the target answers the zombie with a RST packet instead of a SYN/ACK, preventing the zombie from sending the RST which may increase its IP ID. |
STEP 2
The attacker sends a SYN/ACK and the zombie answers with only increases made when interacting with the attacker and not with the target. |
 |
 |
 |
When the port is filtered the target won’t answer at all, the IP ID will also remain the same since no RST response will be made and when the attacker sends a new SYN/ACK to the zombie to analyze the IP ID the result will be the same like with closed ports. Contrary to SYN, ACK and Xmas scans which can’t distinguish between certain open and filtered ports, this attack can’t distinguish between closed and filtered ports. See the table below.
Filtered ports:
| STEP 1
Same as above |
STEP 2
In this case there is not answer from the target preventing the zombie from sending the RST which may increase its IP ID. |
STEP 3
Same as above |
 |
 |
 |
Finding a zombie device
Nmap NSE (Nmap Scripting Engine) provides the script IPIDSEQ to detect vulnerable zombie devices. In the following example the script is used to scan port 80 of random 1000 targets to look for vulnerable hosts, vulnerable hosts are classified as Incremental or little-endian incremental. Additional examples of NSE use, despite unrelated to Idle Scan are described and shown at How to scan for services and vulnerabilities with Nmap and Using nmap scripts: Nmap banner grab.
IPIDSEQ example to randomly find zombie candidates:
As you can see several vulnerable zombie candidate hosts were found BUT they are all false positive. The most difficult step when carrying out an Idle scan is to find a vulnerable zombie device, it is difficult due to many reasons:
- Many ISP block this type of scan.
- Most of Operating Systems assign IP ID randomly
- Well configured firewalls and honeypots may return false positive.
In such cases when trying to execute the Idle scan you’ll get the following error:
“…cannot be used because it has not returned any of our probes — perhaps it is down or firewalled.
QUITTING!”
If you are lucky in this step you will find an old Windows system, an old IP camera system or an old network printer, this last example is recommended by the Nmap book.
When looking for vulnerable zombies you may want to exceed Nmap and implement additional tools like Shodan and faster scanners. You can also run random scans detecting versions to find a possible vulnerable system.
Executing the Nmap Idle Scan
Note the following examples aren’t developed within a real scenario. For this tutorial a Windows 98 zombie was setup through VirtualBox being the target a Metasploitable also under VirtualBox.
The following examples skips host discovery and instructs an Idle Scan using the IP 192.168.56.102 as zombie device to scan ports 80.21.22 and 443 of the target 192.168.56.101.
Where:
nmap: calls the program
-Pn: skips host discovery.
-sI: Idle Scan
192.168.56.102: Windows 98 zombie.
-p80,21,22,443: instructs to scan the mentioned ports.
192.68.56.101: is the Metasploitable target.
In the following example only the option defining ports is changed for -p- instructing Nmap to scan most common 1000 ports.
Conclusion
In the past, the biggest advantage of an Idle Scan was both to remain anonymous and to forge the identity of a device which wasn’t unfiltered or was trustable by defensive systems, both uses seem obsolete due to the difficulty to find vulnerable zombies (yet, it is possible, of course). Remaining anonymous using a shield would be more practical by using a public network, while it is unlikely sophisticated firewalls or IDS will be combined with old and vulnerable systems as trustworthy.
I hope you found this tutorial on Nmap Idle Scan useful. Keep following LinuxHint for more tips and updates on Linux and networking.
