This is the third in a series of posts looking at detecting Nmap scans in Wireshark. I’m being guided by Chapter 31 of Wireshark Network Analysis entitled: “Detect Scanning and Discovery processes
I’ve previously covered the Nmap “stealth scan” here:
The SYN Scan is stealthy as it never completes the three-way handshake and so is also known as “half-open scanning”. This is a default setting, but can be requested with -sS.
This from the above Wireshark book:
In a TCP half-open scan, since the scanner does not complete the three-way-handshake, a target can look at their list of open communications and the scanning host will not show up (hence the name “stealth scan”). The half-open TCP is the desired type of TCP scan for the sake of stealthiness and resource preservation on the target.
TCP scans can be difficult to detect with Wireshark unless the scans are in close proximity and evident in the trace file. An unusually high number of RSTs or a high number of SYN/ACKs without data transfer are strong indications that TCP scan is underway.
I will now perform the -sS scan on one specific port (80) that I already know is open. At the same time I will enable - -packet-trace to observe the packets sent and received:
~# nmap -sS -p 80 –packet-trace pax-pentest.net
SENT (0.2562s) ICMP 192.168.1.70 > 193.189.74.44 Echo request (type=8/code=0) ttl=47 id=6642 iplen=28 <– 1
SENT (0.2565s) TCP 192.168.1.70:49498 > 193.189.74.44:443 S ttl=44 id=39342 iplen=44 seq=4185714695 win=1024 <mss 1460> <– 2
SENT (0.2567s) TCP 192.168.1.70:49498 > 193.189.74.44:80 A ttl=42 id=7824 iplen=40 seq=0 win=1024 <– 3
SENT (0.2569s) ICMP 192.168.1.70 > 193.189.74.44 Timestamp request (type=13/code=0) ttl=49 id=6519 iplen=40
RCVD (0.3137s) TCP 193.189.74.44:443 > 192.168.1.70:49498 SA ttl=53 id=0 iplen=44 seq=2414670637 win=5840 <mss 1460> <– 4
Line 1 the scanning machine sends an echo request.
Line 2 the scanning machine sends an SYN request
Line 3 the scanning machine sends an ACK request
Line 4 the scanned machine responds with a SYN/ACK
But where is the promised RST from the scanning machine which terminates the connection before the three-way-handshake is complete? Well, that’s the beauty of it, Nmap doesn’t send this, it is sent by the Operating System of the scanning machine.
As Nmap crafted the original packet, the received acknowledgement surprises my operating system, which will respond with a RST packet; therefore, Nmap doesn’t have to acknowledge and close the connection.
This can all be seen beautifully and graphically illustrated in the Wireshark capture below:
So, if we see this pattern of requests for SYN followed swiftly by RST after SYN/ACK has been sent, we know we’re probably being “stealthy” TCP scanned.