Detect TCP FIN scans by looking for TCP segments with only the FIN flag set sent to closed or filtered ports. Closed ports often reply with RST, while open ports may stay silent. A spread of isolated FIN packets across many ports, with no prior session state, is typical scan behaviour rather than normal application traffic.
What TCP FIN scans look like on the wire
A FIN scan is visible because the probe pattern is unusual, not because it is noisy. Security teams should expect single-flag TCP segments, often sent one port at a time or in small bursts, with no completed handshake and no application-layer conversation behind them. That makes the scan distinguishable from normal client traffic, which typically establishes state before closing a connection.
Network Ports and Protocols Security Guide is useful background for recognising why flag combinations and port behaviour matter when interpreting scan activity.
How to tell FIN scans from normal TCP close traffic
The most practical discriminator is context. Ordinary sessions usually begin with a three-way handshake, exchange payload, and then close after a stateful conversation. FIN scans instead send FIN-only packets to many targets without a prior established session, and often without any corresponding service request. If you see the same source touching many ports with isolated FIN probes, that is a stronger signal than any single packet by itself.
Detection is easier when you correlate the packet pattern with port state. Closed ports often answer with RST, while open ports may stay silent, so a scan can create a mixed response pattern across a sweep. Look for that combination alongside timing regularity, repeated source addresses, and destinations that do not match the source’s normal business traffic.
Detection logic and monitoring points that work best
Use network telemetry that preserves packet flags, session state, and destination port detail. IDS, NDR, and firewall logs are the most useful sources because they let you correlate FIN-only probes with port sweeps, short-lived bursts, and repeated attempts against closed or filtered ports. Packet capture is the strongest evidence when you need to confirm whether the traffic is a scan or an unusual application behaviour.
To reduce false positives, compare the FIN pattern with host role and protocol expectations. A scanner often enumerates many ports across one or more hosts in a short period, while legitimate traffic tends to be narrower, sessionful, and tied to known services. If you already treat port discovery as a hunting signal, pair it with the response pattern rather than relying on a single FIN packet as proof.
Risk and Threat Considerations
FIN scans matter because they are a low-noise reconnaissance method. They are often used to map live services, identify filtering behaviour, and test which hosts react differently to unusual TCP control flags, so they can be an early indicator of pre-attack activity rather than a harmless anomaly.
Failure mechanism: Defenders miss the scan when they alert only on obvious SYN sweeps or on connection attempts that complete a handshake. FIN-only probes can blend into sparse background traffic, especially where logs do not preserve packet flags or where closed-port responses are not correlated across a source-and-destination set.
Impact: Missed reconnaissance reduces warning time before exploitation, because the same source that is probing with FIN packets may later return with more targeted scanning, service enumeration, or follow-on access attempts against the ports it found responsive or silent.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1046 — Network Service Discovery | FIN scans are a service-discovery pattern used for reconnaissance. |
| Recommendation — Correlate FIN-only probes with network service discovery telemetry and hunt for port enumeration bursts. | ||
| NIST CSF 2.0 | DE.CM-01 — Monitoring for Anomalies and Events | Detecting FIN scans depends on monitoring anomalous packet-flag patterns and sweep behaviour. |
| DE.AE-02 — Anomalous Activity Detected | FIN scans are anomalous network activity that should be recognised and triaged as suspicious. | |
| Recommendation — Tune monitoring to flag unusual TCP flag patterns and repeated probes across many ports. Investigate repeated FIN-only traffic that lacks a normal session lifecycle or application context. | ||
Practitioner Guidance
What to verify: Confirm that your detections key off packet flags and not just port numbers or connection counts. The most useful rule set is one that groups repeated FIN-only probes by source, destination range, and time window, then checks whether the targets are closed, filtered, or unexpectedly silent.
What practitioners underestimate: A FIN scan is easy to dismiss when it appears as a handful of isolated packets. The operational question is not whether the traffic is loud, it is whether the pattern shows systematic port probing without a legitimate session path.
Practitioner takeaway: Treat FIN scans as reconnaissance that should be judged by pattern and context, not by a single packet, and validate detections against host role, destination spread, and response behaviour before you assume benign traffic.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org