Nmap Idle Scan: Scan Anonymously via Zombie Host (2026)

Nmap’s idle scan lets you probe a target without revealing your own IP address, using a "zombie" host as an intermediary.

Let’s see it in action. Imagine we want to scan 192.168.1.100 (the target) and we have a zombie host at 192.168.1.200. The zombie needs to be idle, meaning it’s not sending or receiving much traffic, and crucially, its IP ID counter must be predictable.

First, we need to find a suitable zombie. We can do this by pinging a range of IPs and looking for hosts that respond to pings but don’t generate much other traffic. A quick way to check the IP ID sequence is to send a few probes and observe the increment.

nmap -Pn -p80 --randomize-hosts 192.168.1.200

If 192.168.1.200 is a good zombie, its IP ID will increment predictably. Let’s say we send a few probes and observe the IP IDs:

Probe 1: IP ID 1000
Probe 2: IP ID 1002
Probe 3: IP ID 1004

This shows an increment of 2. Now, we can initiate the idle scan against our target, 192.168.1.100, using 192.168.1.200 as the zombie.

nmap -Pn -sI 192.168.1.200 -p 80 192.168.1.100

Here’s what happens under the hood:

1. Nmap sends a SYN packet to the zombie’s port 80. The zombie’s OS, upon receiving this unexpected packet, generates an RST packet in response and increments its IP ID counter. Let’s say the IP ID was 1004 before this. After Nmap’s probe, the zombie’s IP ID might become 1005.

2. Nmap sends a SYN packet to the target (192.168.1.100) on port 80, but spoofed to look like it came from the zombie (192.168.1.200).

   • If port 80 on the target is OPEN: The target will respond with a SYN-ACK packet to the zombie. The zombie, not expecting a SYN-ACK (since it didn’t send the initial SYN), will respond with an RST packet and increment its IP ID counter. If the zombie’s IP ID was 1005, it might now be 1006.
   • If port 80 on the target is CLOSED: The target will respond with an RST packet to the zombie. The zombie, upon receiving this RST, will increment its IP ID counter. If the zombie’s IP ID was 1005, it might now be 1006.

3. Nmap then sends an ACK packet to the zombie’s port 80. This is to check the zombie’s current IP ID.

   • If port 80 on the target was OPEN: The zombie’s IP ID would have incremented twice (once for the RST to Nmap’s SYN, and once for the RST to the target’s SYN-ACK). So, if the zombie’s IP ID was 1005, it would now be 1007. Nmap’s ACK probe will receive a response with IP ID 1007. Nmap sees the jump from 1005 to 1007 and infers the port is open.
   • If port 80 on the target was CLOSED: The zombie’s IP ID would have incremented only once (for the RST to Nmap’s SYN). So, if the zombie’s IP ID was 1005, it would now be 1006. Nmap’s ACK probe will receive a response with IP ID 1006. Nmap sees the jump from 1005 to 1006 and infers the port is closed.

The key is that Nmap can’t directly observe the target’s response. It infers the target’s port state by observing how many times the zombie’s IP ID counter increments. The zombie’s IP ID increments once for every IP packet it sends out.

The problem Nmap solves here is network anonymity. By routing probes through a zombie, the target sees traffic originating from the zombie, not from the scanner. This makes it much harder for the target to identify the source of the scan.

The -Pn flag is crucial because it tells Nmap not to ping the target first, as the zombie is handling the actual probing. If the zombie itself is down or unresponsive, the scan will fail. You also need to ensure the zombie is truly idle; any significant traffic from the zombie will throw off the IP ID count and make the scan unreliable.

The most surprising thing about the idle scan is how it leverages a fundamental, often overlooked, characteristic of IP packet generation—the sequential IP identification field—to infer network state without direct observation. It turns a system-level detail into a powerful reconnaissance tool.

When setting up an idle scan, you’re not just picking any machine. You’re looking for a host that is predictably incrementing its IP ID counter. Some operating systems and network configurations might not increment sequentially or might reset the counter, making them unsuitable zombies. The scan’s success hinges on the zombie’s IP ID advancing by a consistent, observable amount with each packet it sends.

The next challenge you’ll face is dealing with firewalls that might drop spoofed packets or block traffic from your chosen zombie.