Understanding Nmap Scan with Wireshark
This article dissects five fundamental Nmap scan types — TCP Connect (-sT), SYN/Stealth (-sS), FIN (-sF), NULL (-sN), and Xmas (-sX) — by pairing each command with its corresponding Wireshark capture. Every scan targets two ports on host 192.168.1.5: TCP/22 (SSH, open) and TCP/21 (FTP, closed). The contrast between these two states reveals the precise packet-flag logic that drives port-state determination.
Table of contents
- Introduction
- Lab Environment
- TCP Connect Scan (-sT)
- Connect Scan against an Open Port (22/SSH)
- Connect Scan against a Closed Port (21/FTP)
- SYN (Stealth) Scan (-sS)
- Stealth Scan against an Open Port (22/SSH)
- Stealth Scan against a Closed Port (21/FTP)
- FIN Scan (-sF)
- FIN Scan against an Open Port (22/SSH)
- FIN Scan against a Closed Port (21/FTP)
- NULL Scan (-sN)
- NULL Scan against an Open Port (22/SSH)
- NULL Scan against a Closed Port (21/FTP)
- Xmas Scan (-sX)
- Xmas Scan against an Open Port (22/SSH)
- Xmas Scan against a Closed Port (21/FTP)
- Comparison of Scan Behaviour
- Detecting These Scans
- Conclusion
Introduction
Nmap is the de facto port-scanning utility in offensive security, but its real power lies in the variety of scan techniques it offers. Each technique probes a target with a different combination of TCP flags and interprets the response according to RFC 793. Understanding what happens on the wire — not just what Nmap prints to the screen — separates a button-pusher from a true network analyst.
Lab Environment
The attacker runs Kali Linux 2026 with Nmap 7.99 at 192.168.1.17. The target is a VMware-hosted Linux host at 192.168.1.5 (MAC 00:0C:29:85:D1:03). Wireshark captures the wire with the display filter ip.addr == 192.168.1.5 to isolate scan traffic. All scans run from the same source so that flag-based comparisons are valid.
TCP Connect Scan (-sT)
The TCP Connect scan completes the full three-way handshake by invoking the operating system’s connect () system call. It is the most reliable scan and requires no elevated privileges, but it generates a fully established socket on the target, making it the loudest of all techniques.
Connect Scan against an Open Port (22/SSH)
With the following command, we will launch a Nmap scan, which will complete a kernel-level connect to TCP/22 and confirm the port is open.
nmap -sT -p 22 192.168.1.5

The scan finishes in 0.60 seconds and identifies the service as SSH. Because the kernel handles the handshake, this scan succeeds even from non-root accounts.
Wireshark shows the full handshake: the attacker (192.168.1.17) sends SYN, the target replies with SYN/ACK, the attacker completes with ACK, and Nmap immediately tears the connection down with RST/ACK. The IP header reveals a Total Length of 60 bytes and TTL 64 — typical defaults for a Linux scanner. This four-packet pattern is the unmistakable fingerprint of a Connect scan against an open service.

Connect Scan against a Closed Port (21/FTP)
We target port 21 with the following command:
nmap -sT -p 21 192.168.1.5

Nmap reports the port as closed because no service is listening there. Note that closed is a definitive answer — the host actively refuses the connection rather than dropping it silently.
Only two packets cross the wire. The attacker’s SYN reaches port 21, and the kernel’s TCP stack responds with RST/ACK because no listener is bound to that port. This crisp two-packet pattern (SYN out, RST/ACK in) is RFC-compliant behaviour for any closed TCP port and is what allows Nmap to declare the port closed with high confidence.

SYN (Stealth) Scan (-sS)
The SYN scan, also called the half-open or stealth scan, is Nmap’s default for privileged users. It crafts raw SYN packets directly and never completes the handshake. By aborting before the kernel records a session, it avoids application-layer logging on most services and runs faster than a full Connect scan.
Stealth Scan against an Open Port (22/SSH)
Running the following nmap scan produces the same verdict as the Connect scan — port 22 is open — but the underlying packet behaviour is fundamentally different. Nmap requires raw socket privileges (root) to forge the SYN, which is why -sS is the default only when invoked with sufficient privileges.
nmap -sS -p 22 192.168.1.5

The capture shows three packets instead of four. Nmap sends a SYN, receives a SYN/ACK confirming the port is open, then immediately sends a RST to tear down the half-open connection without ever sending a final ACK. The IP header on the SYN reveals Total Length 44 (the minimum TCP packet size) and TTL 46 — both subtle indicators that a raw-socket scanner, not a normal application, generated the traffic.

Stealth Scan against a Closed Port (21/FTP)
The following command is used to confirm that FTP is closed
nmap -sS -p 21 192.168.1.5

As before, a closed verdict means the target’s stack actively refused the probe.
Against a closed port the Connect and SYN scans are indistinguishable at the wire — both produce a SYN followed by RST/ACK. The only difference is who issues the SYN: a kernel API call versus a raw-socket libpcap injection. Defenders cannot reliably distinguish the two scan types from closed-port responses alone; they must observe behaviour against open ports.

FIN Scan (-sF)
The FIN scan exploits an RFC 793 corner case: a closed port must reply with RST when it receives any packet that lacks SYN, and an open port must silently drop such packets. By sending a lone FIN flag — normally used to gracefully close a session — Nmap can infer port state without ever creating one. FIN scans evade simple stateless firewalls that only inspect SYN packets.
FIN Scan against an Open Port (22/SSH)
The FIN scan state reflects fundamental ambiguity — Nmap received no reply, which under RFC 793 could mean either an open port (silently dropped the FIN) or a firewall (filtered the probe). FIN scans trade certainty for stealth. It is shown in the following command:
nmap -sF -p 22 192.168.1.5

The capture shows two outbound FIN packets from the attacker and zero responses. Nmap retransmits because no answer arrived — it cannot tell whether the host swallowed the packet (open) or dropped it at a firewall (filtered). The 40-byte IP packet length and absent reply traffic together create the open|filtered verdict.

FIN Scan against a Closed Port (21/FTP)
Running the following scan produces a definitive closed verdict because RFC 793 mandates that a closed port reply with RST to any non-SYN packet.
nmap -sF -p 21 192.168.1.5

The wire shows a single FIN out and a single RST/ACK back — the textbook closed-port reaction to a stealth probe. This is precisely why FIN scans are useful: they distinguish closed ports from open/filtered ones without ever sending a SYN.

NULL Scan (-sN)
The NULL scan is the FIN scan’s more extreme cousin: it sends a TCP packet with no flags set at all. Wireshark displays this exotic packet as [<None>]. Like the FIN scan, it relies on the RFC 793 rule that closed ports must RST while open ports must drop. NULL scans defeat firewalls that only inspect specific flag combinations.
NULL Scan against an Open Port (22/SSH)
Executing the following command yields the open|filtered verdict, mirroring the FIN scan result. The same ambiguity applies — silence from the target could mean either state.
nmap -sN -p 22 192.168.1.5

Wireshark labels both probes [<None>] because no TCP flags are set. The IP header still shows Total Length 40 and TTL 40 — values that themselves betray the probe as non-conventional traffic. Modern Linux and BSD stacks honour RFC 793 and stay silent, but Microsoft Windows ignores the rule and replies with RST regardless of port state, which is why NULL scans are notoriously unreliable against Windows targets.

NULL Scan against a Closed Port (21/FTP)
The following command marks the port closed. The Linux target obeys the RFC and refuses the flagless probe.
nmap -sN -p 21 192.168.1.5

Just as with the FIN scan, a single flagless probe meets a single RST/ACK. The reaction confirms that the destination stack is RFC-compliant and gives Nmap the certainty needed to print closed.

Xmas Scan (-sX)
The Xmas scan lights up a TCP packet “like a Christmas tree” by setting the FIN, PSH, and URG flags simultaneously. This bizarre flag combination is illegal in normal TCP communication, yet RFC 793 still requires the same behaviour as for a FIN or NULL probe — silence from open ports, RST from closed ports.
Xmas Scan against an Open Port (22/SSH)
Running the following scan returns open|filtered, completing the consistent pattern across FIN, NULL, and Xmas scans against an open port: ambiguity is the rule because RFC-compliant stacks stay silent.
nmap -sX -p 22 192.168.1.5

Wireshark clearly shows the FIN+PSH+URG flag combination on each probe. The 40-byte length and absent response again produce the open|filtered verdict. From a defender’s perspective, [FIN, PSH, URG] is one of the loudest red flags imaginable — no legitimate application ever sends such a packet.

Xmas Scan against a Closed Port (21/FTP)
Executing the following command confirms the closed state.
nmap -sX -p 21 192.168.1.5

A single FIN+PSH+URG packet provokes a single RST/ACK in return. Across all three stealth variants — FIN, NULL, Xmas — the closed-port wire signature is identical: one probe out, one RST/ACK back. Only the flag set on the outbound packet distinguishes them, which is why blue teams should alert on the flag combination itself, not just the response.

Comparison of Scan Behaviour
The table below condenses the wire-level behaviour of each scan type against open and closed ports. The distinct fingerprints make it possible — for both attackers tuning their scans and defenders writing detection rules — to identify exactly which Nmap technique is in use.

Detecting These Scans
Each scan technique leaves a recognisable fingerprint that defenders can write IDS rules around. Connect scans look like a barrage of short-lived completed handshakes from a single source. Stealth scans appear as SYN packets followed by RST instead of ACK. FIN, NULL, and Xmas scans are trivially flagged because their flag combinations never occur in legitimate TCP traffic — Snort, Suricata, and Zeek all ship default rules for these patterns.
Beyond signatures, behavioural detection works well: any single source touching dozens of ports within seconds, especially with low TTL values or unusual IP Total Length fields (44 or 40 bytes), strongly suggests a port scan. Modern firewalls deploying TCP state tracking automatically drop unsolicited FIN, NULL, and Xmas packets, neutralising those scans entirely.
Conclusion
Nmap’s scan flags are not interchangeable — each technique implements a different probe and interprets the response through the lens of RFC 793. The Connect scan is loud but reliable, the SYN scan trims one packet for stealth, and the FIN, NULL, and Xmas scans abandon the handshake entirely to slip past stateless filters at the cost of certainty. Pairing each scan with a Wireshark capture, as this article has done, transforms Nmap from a black-box utility into a transparent demonstration of the TCP/IP standard.
Penetration testers should choose the scan that matches the engagement’s stealth and accuracy requirements. Defenders should ensure their detection stack alerts on every flag combination shown here — an Xmas packet on production traffic is never benign. Mastery of these five techniques is foundational, and every additional Nmap flag builds on the wire-level behaviour demonstrated above.
Amazing article. Thanks for sharing this stepwise guideline to tackle the attacker invasion using wireshark. Great explanations and easy to understand. Thanks a million for sharing this.
A good article!
Man, this is just great! Thank for sharing
can you also show how to detect nmap -O (OS) using wirehsark
Hey Bee Joy,
If you got any answer for this can you let me know.
Good Artical Raj.. Appreciate your efforts on sharing good Artical.