An Nmap SYN scan in a PCAP: three open ports out of a thousand

In 23 seconds 172.16.0.8 sends 1,994 SYN packets to 1,000 ports of 64.13.134.52, and three ports answer: TCP 22, 53 and 80. This Nmap SYN scan PCAP is a half-open scan in its classic form, and the SYN scan is Nmap's usual choice whenever it can craft raw packets, so knowing what one looks like in a capture is basic network forensics. A-Packets reads the burst as one busy conversation between the scanner and its target and lists the ports that answered with SYN-ACK in the Open Ports view.

The value of a SYN scan to an attacker, and the reason it leaves a recognisable fingerprint, is that it never finishes the connection. That makes it fast and invisible to the services it maps, but its fan-out across a thousand destination ports looks like nothing an ordinary client does. This report shows both halves: the open ports the scan found, and the pattern that marks the traffic as a scan rather than real use.

The open ports the scan found

A SYN scan sends a TCP SYN, the first packet of the three-way handshake, and watches the reply. An open port answers with SYN-ACK, a closed port answers with RST, and a filtered port stays silent. The scanner reads the answer and then abandons the connection instead of completing it with the final ACK, which is why it is called half-open. Across this capture three ports answered SYN-ACK, four times each, and they are the open services on the target.

Open the Open Ports view →

Those three are TCP 22, 53 and 80, labelled SSH, DNS and HTTP by their port numbers; the scan proves that something answered on each, not which software it is. A-Packets lists a port as open only when it saw the port answer a SYN with SYN-ACK, which is exactly what tells a listening service apart from a closed port that replied with RST and from a filtered port that stayed silent. Everything else the scanner touched is not listed. For a defender reading the capture after the fact, this short list is the important output: these are the services an attacker now knows to probe next, and the ones to confirm are meant to be exposed.

The shape that marks it as a scan

The open ports are what the attacker wanted; the traffic pattern is what gives them away. Nearly two thousand SYN packets left one source for one destination in 23 seconds, spread across a thousand destination ports, and none of them completed a handshake. Ordinary traffic does not look like that: a browser or a mail client opens a few connections to a few ports and finishes them. A single source sending many SYNs to many ports with no established sessions is the defining signature of a port scan, and it is visible in the capture as one dominant conversation with a wall of half-open attempts.

Because the scan completes no handshakes, there is no application payload to rebuild, and the capture is nothing but TCP control segments: SYNs outbound and, apart from twelve SYN-ACKs and five resets, silence coming back. Thousands of control packets and no data is itself a fingerprint: real traffic carries payload, a scan carries intent. In Wireshark you can isolate the probes with tcp.flags.syn == 1 && tcp.flags.ack == 0 and the answers from open ports with tcp.flags.syn == 1 && tcp.flags.ack == 1; the second filter returns twelve packets, three ports answering four times each.

SYN scan versus a full connect scan

The half-open design is also why a SYN scan is harder to catch in application logs than a full connect scan. A connect scan, which an unprivileged user runs when it cannot craft raw packets, completes the handshake and so appears in the target service's logs as a connection that opened and closed. A half-open attempt never reaches the application, so it leaves no service log entry; only a host firewall, kernel instrumentation or an endpoint sensor would record it. That is precisely why the capture matters: the evidence of a SYN scan lives at the packet level, in the SYN pattern, not in the logs of the services it mapped, and a defender who relies only on application logs would miss it.

Retries explain the gap between packet and port counts

The file holds 2,011 TCP packets, all without payload: 1,994 SYNs, twelve SYN-ACKs and five resets. The SYNs cover exactly 1,000 distinct destination ports, so 1,994 is an attempt count, Nmap probing most ports twice, not a count of services. The twelve SYN-ACKs belong to three ports and repeat because the handshake is never finished. Port 53 answers at 0.064, 3.063, 9.072 and 21.093 seconds and port 22 at 1.466, 5.063, 11.064 and 23.085: the doubling back-off of a server retransmitting into silence, with port 80 on the same schedule in its own stream.

No reset from the scanner appears anywhere in the file, so each half-open connection was left for the server to time out. The five resets come from the target, from ports 25, 70, 113 (twice) and 31337: those ports are closed. The remaining 993 ports never answered at all, which Nmap reports as filtered, the probes dropped on the way. A-Packets' open-port list is built from the affirmative answers only, which is what makes three entries out of a thousand probes trustworthy.

Timing, decoys and the limits of spotting a scan

This capture shows a fast scan, 1,994 probes in 23 seconds, which is easy to spot. A real attacker who wants to stay under a detection threshold slows down: Nmap's timing templates and retry settings let an operator stretch the same scan over hours. A slow scan defeats a rule that counts probes per minute, so a thorough detection strategy correlates over a longer window and looks at the distinct-port count from a source rather than the rate alone. The captured scan is the loud end of a spectrum; the quiet end looks almost like noise until you aggregate it.

Attackers also hide the source. Nmap's decoy option fills a scan with spoofed source addresses so the real scanner is one of many apparent origins, and idle scans bounce probes off a third host so the target never sees the attacker's address at all. In a capture, decoys show as several sources sending identical scans in lockstep, which is itself a tell, and an idle scan shows unusual IP ID progression on the bounce host. None of this changes the defensive conclusion, the open ports are what matter, but it is why attributing a scan to a source from the capture alone is unreliable, and why the response focuses on the exposed services rather than on chasing the origin.

Responding to a scan and reducing what it finds

A SYN scan is reconnaissance, not a breach, but it is reconnaissance worth noticing because it usually precedes something more targeted against whatever it found. The immediate response is to review the ports that answered: each listening service is attack surface, so confirm that SSH, DNS and HTTP are meant to be reachable from where the scan came, and close or firewall anything unexpected. Two details keep that review honest: a SYN-ACK can come from a load balancer or SYN proxy in front of the server rather than the service itself, and TCP 53 says nothing about DNS over UDP. Reducing the open-port count is the durable mitigation, since a scan can only report what is actually listening.

Detecting the scan itself relies on the pattern rather than any single packet: many SYNs from one source to many ports with no completed handshakes in a short window. Counting distinct destination ports, handshake outcomes and duration together separates a sweep like this from a SYN flood aimed at one service or a client retrying one endpoint. Stateful firewalls and intrusion-detection systems flag the pattern directly, and rate limiting on new connections slows a scan and makes it louder. In MITRE ATT&CK terms a scan of an external-facing host like this one is T1595, Active Scanning; the same scan run from inside the network is T1046, Network Service Discovery. Either way, treat it as the opening of a possible intrusion and check that the discovered services are patched and access-controlled.

This is the port-discovery counterpart to the Nmap ACK scan, which maps firewall behaviour rather than finding open ports, and the Nmap NSE HTTP scan, which probes a single service in depth. For the investigator's perspective on scans and sweeps, see using PCAP analysis for network forensics, or upload a capture of your own.