To figure out what Nmap really is doing behind the scenes you can analyze Nmap traffic with Wireshark. Whether Nmap is not showing the expected result or you just want to look at the packets – this is a great network lab.
Nmap ping probes analyzed with Wireshark
The background to this post is that sometimes the result from a Nmap scan differed from what I thought the result should have been. Sometimes Nmap will tell you “Host seems down. If it is really up, but blocking our ping probes, try -Pn”
Time to learn through practice and perform a Nmap scan while checking the traffic with Wireshark to see what is really happening.
Nmap ping probes documentation
This lab could be skipped by properly reading the manual on what Nmap is in fact doing. But learning through practice will probably help you understand and remember the facts better. Not to mention the skill of testing things on your own. That is how you learn cybersecurity you test, practice and learn.
The Nmap documentation tells us that Nmap by default is performing host discovery and sends the following to determine if the host is up:
- An ICMP echo request
- a TCP SYN packet to port 443
- a TCP ACK packet to port 80
- an ICMP timestamp request
So if we want to check if port 445 is open, Nmap will first test these four to determine the status of the destination before testing port 445.
Lab setup: Wireshark + Nmap
Two virtual machines connected to the same network adapter.
One Linux box running Nmap and Wireshark and one Windows server with open / closed ports.
| Linux box | Windows box | |
| IP | 192.168.80.7 | 192.168.80.3 |
| Scanned open port | – | 445 |
| Scanned closed ports | – | 80,443 |
Nmap connect scan open port test
To test this out we will execute Nmap with a couple of arguments:
- -sT for connect scan (Full TCP handshake)
- -p for specifying our port
- -v for verbosity
$ nmap -sT -p 445 192.168.80.3 -v
The verbosity argument really helps us to see what Nmap is doing: Nmap tries a ping scan and considers the host to be down:
We can see from the text output that the host might be up but blocking ping probes – from reading the documentation we know this means ICMP packets and testing of port 80 and 443.
We know port 445 is open but Wireshark reports the host as down. The traffic capture reveals why:
An ARP broadcast goes out to figure out where the destination is located – but no ICMP packets can be seen. So 2/4 host discovery checks fail there. Neither port 80 nor 443 is open on the destination so Nmap will consider the host as down and skip trying port 445.
Redoing the scan but with the suggested argument, skipping host discovery; -Pn
Now the host discovery check is skipped and the traffic capture reveals only one thing: a TCP-SYN towards port 445. With the whole TCP-handshake to follow.
Interestingly if you skip -Pn but let Nmap have sudo privileges it will also find the port.
With sudo privileges Nmap does an ARP scan and finds the device, then goes straight for the port and the TCP handshake.
Nmap connect scan closed port test
With sudo privileges to get it to hit the port.
$ sudo nmap -sT -p 83 192.168.80.3
Nmap tries the port twice then reports it as filtered:
Nmap stealth scan open port test
Stealth scan is only available to run with sudo privileges.
$ sudo nmap -sS -p 445 192.168.80.3
So -sS or Stealth Scan is supposed to be more stealthy than the connect scan. We can see from the captured traffic why. After the initial SYN the server responds with SYN-ACK but instead of completing the handshake and starting the connection Nmap kills it with a RST.
The reasoning behind this is that it might never be logged at the destination that a connection almost took place. This is not rocket science and might be captured anyway but still somewhat more stealthy.
Nmap stealth scan closed port test
Stealth scan is only available to run with sudo privileges.
$ sudo nmap -sS -p 83 192.168.80.3
What we would expect. Nmap tries the port twice then reports it as filtered.
Nmap without arguments
We will give it -Pn to actually find the destination.
$ nmap 192.168.80.3 -Pn
Just north of 2000 packets sent and 149k of data. So Nmap definitively leaves a mark on the network while doing a basic scan.
Nmap Host discovery summary
While analyzing Nmap traffic with Wireshark in this lab we only scanned one port and in this scenario the host discovery generates more traffic then the actual scan we want. But host discovery can save a lot of time while scanning for more ports and towards more destinations.
Instead of trying all ports towards all devices, Nmap will only scan destinations it finds to be up.
Unclear why Nmap did not send the ICMP request – So when in doubt always use sudo or -Pn
If you do not have a good environment to test this lab in, why not build your own Active Directory VM lab setup
