Idle Scans are performed against a Target System without any traffic occurring between the Source and Target Systems. The Idle Scan is accomplished by using a third system to pass requests between the Source and Target. The third system is referred to as a “Zombie” System. The “Zombie” System will receive requests from the Source System and send them to the Target System. Responses are passed to the Source System. The Idle Scan is sometimes referred to as a Proxy Scan since the scan is performed through a third-party system. Requirements To perform an Idle Scan there are three requirements: Root privileges on the Source System Idle “Zombie” System Port 80 must be open on the “Zombie” System Root privileges must be used on the Source System to perform the Idle Scan. As with the TCP SYN Scan, a half-open connection will be made to the “Zombie” System. The half-open connection process is performed as follows in a normal scan: Source System sends a SYN request to the Target, but a Port number is added to the request in this case. The Target System will respond with a SYN/ ACK (Sync/Acknowledgement) to the Source if the specified Port is open. The Source System responds with a RST (Reset) to the Target to close the connection. The Target System can respond with a RST/ACK (Reset/Acknowledgement) to the Source System. The “Zombie” System ‘must be idle’ is the second requirement. The “Zombie” System must be processing no other traffic on the network. The reason is that each packet sent on a network by a computer is numbered. The Internet Protocol (IP) IDs, included in each packet, are used to number each packet with a consecutive number. NMAP uses the IP IDs to monitor the progress of the Idle Scan. If the IP IDs are seen as too out-of-order then the scan is terminated. If IP IDs are too out-of-order it shows that the system is communicating with other systems which will mess up the scan. The last requirement is the need for Port 80 to be open on the “Zombie” System. In a regular TCP SYN Scan the Port number is given when a Three-Way Handshake is opened. With the Idle Scan, a Port number is not given. Without a specified Port the default is used which is Port 80. By using the default Port it is required to be open for the Idle Scan to be performed. Let’s look into detail how the Idle Scan works. Process The way the process works is done in three steps. Be sure you understand each step before continuing to the next step. The first step is to find the current IP ID of the “Zombie” System. To find the current IP ID the Source system sends a SYN/ACK to the “Zombie”. You can see the the SYN/ACK is used as the second step in the Three-Way Handshake. Since the “Zombie” System did not initiate a Three-way Handshake it sees the Handshake attempt as an error. Since the Handshake is in error the “Zombie” system will respond to the Source System with a reset (RST). The RST will also include the current IP ID of the “Zombie”. Now the Source System has the current IP ID and is ready to begin the scan. The second step is for the Source System to send a spoofed SYN+Port to the Target. The Target system will respond to “Zombie” System which it thinks sent the request. The Target System sends a SYN/ACK to the “Zombie” if the Port is closed. The “Zombie” System responds to this erroneous attempt at a Three-Way Handshake. Keep in mind that the RST response will increment the IP ID by one. The third step occurs after a pause while the Source System waits for step two to occur. After the allotted time the Source System sends another SYN/ACK to the “Zombie”. The “Zombie” responds with RST. The RST includes the IP ID and the Source System can find how many packets were sent by the “Zombie” System. If the IP ID has incremented by one the Port specified in step 1 is closed. If the IP ID has been incremented by two then the specified Port is open. Setting Up the Idle Scan To perform the scan we know that three systems are required. I will use three systems with the following information: Source - Host Name: Jarret-PC OS: Linux Mint 18.1 IP: 10.0.0.1 MAC: 00:24:81:e9:c3:2f Zombie - Host Name: dell OS: Windows XP IP: 10.0.0.2 MAC: 00:0b:db:40:55:14 Target - Host Name: raspberrypi OS: PandaPi IP: 10.0.0.3 MAC: b8:27:eb:6a:84:f5 NOTE: The information given for each system involved is important to note. The problem is that the “Zombie” System will send packets to the Target System and use a different IP Address. The MAC Address will remain the same. The changing of the IP Address is used to keep the identity of the “Zombie” System hidden. The changing of the IP Address is called Spoofing. The command to run the Idle Scan is as follows: nmap -sI <zombie-IP-address> <Target-IP-address> -pN NOTE: On my system I have two Network Interface Cards (NIC). One is wired and the the other WiFi. In the ‘nmap’ command I had to specify my device with the ‘-e <device-name>’ parameter. The ‘-pN’ parameter is used when using a ‘-s?’ parameter. The ‘-pN’ parameter causes nmap to assume all given IP Addresses to scan are on-line. Now we can get on to performing an Idle Scan. Performing the Idle Scan An Idle Scan is shown in Figure 1. The command used was ‘sudo nmap -sI 10.0.0.2 10.0.0.3 -Pn -e enp02s5 -v’. FIGURE 1 The command shows I am using the system with the IP Address of ‘10.0.0.2’ as my “Zombie” System. The Target System has an IP Address of ‘10.0.0.3’. Since my system has two NICs I must specify the name of the Ethernet device with the ‘-e’ parameter. NOTE: To find the name of the NIC use the ‘ifconfig’ or the ‘ip a’ command. Also on the Windows system, as my “Zombie”, I had to make an exception for Port 80 in the Firewall. Now for the Wireshark scan. Physical Scan I performed a Wireshark scan from the Source System and the “Zombie” System. Figure 2 shows the initial output from the Source System. Lines 12, 16, 18, 20, 22 and 24 show where the Source System sent the SYN/ACK to the “Zombie” System. The six requests are used to determine the IP ID of the “Zombie” as well as verify the system is idle. The “Zombie” responded with a RST to each request since the Three-Way Handshake is out of order on Lines 15, 17, 19, 21, 23 and 25. FIGURE 2 The next step is for the Source System to spoof a request to the Target System as the “Zombie”. In Figure 3 you can see on Line 33 that the top pane shows that the system at 10.0.0.2 is contacting 10.0.0.3. If you look at the highlighted lower portion you will see the MAC Address is really that of our Source System and not the “Zombie”. The request is being made from Port 80 (http) to Port 23 (telnet) as shown in the upper pane to the right. FIGURE 3 In Figure 4 on Line 63 is where the Source System sends a SYN/ACK to the “Zombie” to determine the IP ID again. On Line 64 the “Zombie” responds with a RST and the Source System has the IP ID and can determine what has been happening with the Target System. FIGURE 4 If a scan were performed on a system located on the Internet it would perform in the same manner. The difference is that the Source System will spoof its IP Address to the “Zombie” and Target Systems. Looking back at the actual scan in Figure 1 you can see that only Port 22 (SSH) was open on the Raspberry Pi. The port is open since I have it open to use it for connecting to a remote terminal. Test the scan out on your systems. It works better to be on a closed network. If needed, shut down the WiFi on your router and only have local connections. Once the Internet is involved in the Idle Scan the Source System will start spoofing. Look carefully at the MAC Addresses and be aware that the spoof addresses will have to go to your router (gateway) and back to the “Zombie” and Target. The MAC Address will be that of your router and not the Source System. NOTE: The reason that the Source System will use your router in the middle is that its spoofed addresses will be of one on the Internet. The packet must go through a router to be able to reach a system on a different subnet (even though they are on the same physical network). This seems a little strange, but this is how TCP/IP works. TCP/IP has many little things to remember when dealing with the protocol. IP ID TCP/IP has a lot of hidden information inside the packets being sent. The IP ID is one of them. As stated before, Lines 17, 19 and so on are used by the Source System to check if the “Zombie” System is idle. In Wireshark you can select a line in the upper pane and see details in the lower pane. In the lower pane is a section ‘Internet Protocol Version 4...’ which has a sub-section called Identification as shown in Figure 5. In Figure 5 you can see the IP ID number for Line 17 in the middle pane which is 3566. FIGURE 5 If you look at Line 19 in Figure 6 you can see the next IP ID is 3567. The numbering is consecutive for the all of the reset (RST) packets sent by the “Zombie” System. FIGURE 6 Hopefully, the scan is understandable. Try a few scans to see if you follow what is going on.