A member of the Toronto Metropolitan University/Rogers Cybersecure Catalyst program, a program I'm currently a mentor for, was using Nmap and could not really see the difference when using the -sW and -sM scan techniques. To help that student and others using Nmap, I thought I should put together a quick blog post.
Before getting into the -sW and -sM, let's take a look at some other TCP scan options. This is important as when we run these tools, it is important that we understand what they are doing in the background.
Staring with Nmap SYN Scan (-sS), we get
┌──(kali㉿securitynik)-[~] └─$ sudo nmap -sS 10.0.0.106 --reason -p 445 --send-ip --reason -Pn Starting Nmap 7.92 ( https://nmap.org ) at 2023-01-03 16:04 EST Nmap scan report for 10.0.0.106 Host is up, received user-set (0.00046s latency). PORT STATE SERVICE REASON 445/tcp open microsoft-ds syn-ack ttl 128 MAC Address: 08:00:27:88:B8:34 (Oracle VirtualBox virtual NIC) Nmap done: 1 IP address (1 host up) scanned in 5.65 seconds
Looking at this scan activity under the hood, we see ...
┌──(kali㉿securitynik)-[~] └─$ sudo tcpdump -nn --interface eth0 'port 445' tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes 16:04:18.309853 IP 10.0.0.108.37698 > 10.0.0.106.445: Flags [S], seq 3556209128, win 1024, options [mss 1460], length 0 16:04:18.310294 IP 10.0.0.106.445 > 10.0.0.108.37698: Flags [S.], seq 2634056672, ack 3556209129, win 64240, options [mss 1460], length 0 16:04:18.310312 IP 10.0.0.108.37698 > 10.0.0.106.445: Flags [R], seq 3556209129, win 0, length 0
From above, we see 3 packets. The first represents the stimulus. Nmap sends a SYN [S] packet and receive a SYN/ACK [S.]. This "[S.]", tells Nmap, this port is "open". Hence the Nmap result above states "open" and the reason states "syn-ack". On a side note, do you know why there is a 3rd packet? The one in red with "[R]"? Leave a comment in the chat if you do. Getting into the 3rd packet is not important for this post but would love to know your comment if you have one.
Looking at the connect scan (-sT)
┌──(kali㉿securitynik)-[~] └─$ sudo nmap -sT 10.0.0.106 --reason -p 445 --send-ip --reason -Pn Starting Nmap 7.92 ( https://nmap.org ) at 2023-01-03 16:04 EST Nmap scan report for 10.0.0.106 Host is up, received user-set (0.00047s latency). PORT STATE SERVICE REASON 445/tcp open microsoft-ds syn-ack Nmap done: 1 IP address (1 host up) scanned in 5.56 seconds
Looking at the output, it does not look any different from the Syn Scan (-sS). Keep in mind, both of these scans so far, returned a state of "open" and reason "syn-ack".
Looking under the hood, we are able to immediately see a difference between the two scans
┌──(kali㉿securitynik)-[~] └─$ sudo tcpdump -nn --interface eth0 'port 445' tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes 16:05:04.611618 IP 10.0.0.108.39368 > 10.0.0.106.445: Flags [S], seq 1022019330, win 64240, options [mss 1460,sackOK,TS val 322962533 ecr 0,nop,wscale 7], length 0 16:05:04.612014 IP 10.0.0.106.445 > 10.0.0.108.39368: Flags [S.], seq 486308284, ack 1022019331, win 65535, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 16:05:04.612030 IP 10.0.0.108.39368 > 10.0.0.106.445: Flags [.], ack 1, win 502, length 0 16:05:04.612054 IP 10.0.0.108.39368 > 10.0.0.106.445: Flags [R.], seq 1, ack 1, win 502, length 0
From a simplistic view, the Connect Scan resulted in 4 packets, while the Syn Scan resulted in 3. The first 3 packets, represent the complete TCP 3-way handshake. However, there is a fourth packet. Similar to above, it is not important for what we are interested in. However, if you have the answer, why the "[R.]" packet is there, do leave a comment ;-).
If we look at the two outputs from Nmap so far, there is really little to no difference. Continuing with the simplistic view of only looking at the Nmap output, only tells you this host is alive.
Running the ACK Scan
┌──(kali㉿securitynik)-[~] └─$ sudo nmap -sA 10.0.0.106 --reason -p 445 --send-ip --reason -Pn Starting Nmap 7.92 ( https://nmap.org ) at 2023-01-03 16:09 EST Nmap scan report for 10.0.0.106 Host is up, received user-set (0.00030s latency). PORT STATE SERVICE REASON 445/tcp unfiltered microsoft-ds reset ttl 128 MAC Address: 08:00:27:88:B8:34 (Oracle VirtualBox virtual NIC) Nmap done: 1 IP address (1 host up) scanned in 5.64 seconds
Once again, the output looks basically the same so far as we saw in the earlier two. However, if you pay close attention, you see the state is "unfiltered". Why unfiltered?
Looking under the hood, we see two packets this time.
┌──(kali㉿securitynik)-[~] └─$ sudo tcpdump -nn --interface eth0 'port 445' tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes 16:09:21.794159 IP 10.0.0.108.50010 > 10.0.0.106.445: Flags [.], ack 2598207558, win 1024, length 0 16:09:21.794442 IP 10.0.0.106.445 > 10.0.0.108.50010: Flags [R], seq 2598207558, win 0, length 0
So far, the output from the first two are basically the same, having a state of "open" and this 3rd "unfiltered". The real difference in how they operate can be seen from under the hood. While the two previous examples had a stimulus of "[S]", this example has a stimulus of "[.]". Notice also the Nmap output states "unfiltered". Nmap knows the port is unfiltered, because it received the "[R]". We can confirm this, by looking at the Nmap output, where the reason shows "reset" besides "unfiltered".
Now to the two scan techniques the user was really concerned about. -sW and -sM. Starting with -sW
┌──(kali㉿securitynik)-[~] └─$ sudo nmap -sW 10.0.0.106 --reason -p 445 --send-ip --reason -Pn Starting Nmap 7.92 ( https://nmap.org ) at 2023-01-03 16:13 EST Nmap scan report for 10.0.0.106 Host is up, received user-set (0.00038s latency). PORT STATE SERVICE REASON 445/tcp closed microsoft-ds reset ttl 128 MAC Address: 08:00:27:88:B8:34 (Oracle VirtualBox virtual NIC) Nmap done: 1 IP address (1 host up) scanned in 5.64 seconds
Notice the state is "closed". How does Nmap know it is closed? We should now have an understanding of where to find the answer.
Looking under the hood, we see two packets.
┌──(kali㉿securitynik)-[~] └─$ sudo tcpdump -nn --interface eth0 'port 445' tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes 16:13:20.105897 IP 10.0.0.108.46454 > 10.0.0.106.445: Flags [.], ack 3050815645, win 1024, length 0 16:13:20.106254 IP 10.0.0.106.445 > 10.0.0.108.46454: Flags [R], seq 3050815645, win 0, length 0
This is much the same as was seen in the ACK scan. This is also because this scan is exactly the same as the ACK scan, difference being that it examines the TCP Windows field when a "[R]" packet is returned.
Wrapping this up with a Maimon scan (-sM)
┌──(kali㉿securitynik)-[~] └─$ sudo nmap -sM 10.0.0.106 --reason -p 445 --send-ip --reason -Pn Starting Nmap 7.92 ( https://nmap.org ) at 2023-01-03 16:17 EST Nmap scan report for 10.0.0.106 Host is up, received user-set (0.00034s latency). PORT STATE SERVICE REASON 445/tcp closed microsoft-ds reset ttl 128 MAC Address: 08:00:27:88:B8:34 (Oracle VirtualBox virtual NIC) Nmap done: 1 IP address (1 host up) scanned in 5.61 seconds
Once again, the state is "closed". The output between -sW and -sM looks basically the same.
Looking under the hood ...
┌──(kali㉿securitynik)-[~] └─$ sudo tcpdump -nn --interface eth0 'port 445' tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes 16:17:06.538048 IP 10.0.0.108.45642 > 10.0.0.106.445: Flags [F.], seq 0, ack 925611209, win 1024, length 0 16:17:06.538370 IP 10.0.0.106.445 > 10.0.0.108.45642: Flags [R], seq 925611209, win 0, length 0
... We have two packets. Notice the difference in the flags? The -sW has flags "[.]" and "[R]". The -sM have flags "[F.]" and "[R]".
You might have noticed, the last 3 outputs where there is the "[R]" RST flag, I did not put them in red. This is because this behavior was expected. The other two above, they are generated from your system's TCP/IP stack because it was not aware of the initial "[S]" packet being sent.
If you are reading this and wonder why I did not go more into what the different flags mean, then come hang out with us at one of the upcoming SANS SEC503: Network Monitoring and Threat Detection in Depth, where we go deep into packets learn more.
Hopefully this clear up any concerns users of Nmap have, as it relates to not seeing any difference in the outputs.
Reference:
https://linux.die.net/man/1/nmap