Detect TCP ACK scans by watching for standalone ACK packets that are not part of an existing connection. These probes are often used to map firewall state by eliciting different responses from filtered and unfiltered paths. Unexpected ACKs from one source to many destinations, without follow-on session traffic, indicate reconnaissance activity.
How TCP ACK scans show up in traffic
ACK scans are easier to spot when you treat them as stateless probes rather than normal session traffic. A legitimate client usually sends an ACK after a SYN, SYN-ACK, or existing conversation; a scan sends isolated ACKs that arrive without the handshake or a preceding flow that explains them. The pattern often looks like a burst of single-packet events, sometimes to many hosts or ports in a short window.
That distinction matters because the signal is not just “an ACK exists”, it is “the ACK has no believable connection context”. Security tooling should therefore correlate TCP flags with flow state, connection tracking, and the absence of follow-on packets. A single packet may be noisy, but repeated ACKs with no reply traffic are the behavioural clue that the packet is reconnaissance rather than application activity.
One useful place to anchor that interpretation is the broader network context in NHIMG’s Network Ports and Protocols Security Guide, since ACK scans sit in the same operational space as port exposure, firewall behaviour, and protocol state validation.
What defenders should correlate before calling it a scan
ACK scans are only meaningful when you compare packet flags with what the network should already know. If you see ACKs from one source to many destinations, but no established sessions, no three-way handshake, and no application-layer conversation, the traffic deserves attention. The destination mix also matters: broad destination variety, repeated timing, or systematic traversal across subnets strengthens the case for reconnaissance.
Firewall and IDS responses are part of the signal. ACK probes are often used to learn whether a path is filtered or stateful by observing whether a response comes back and how a control plane reacts. That means defenders should inspect not only the packet itself, but also the response pattern, NAT logs, state-table events, and any related resets or drops that follow the probe.
For network-edge interpretation, the key question is whether the ACK is consistent with an existing flow. If not, it belongs in the same investigative queue as other suspicious scan traffic, especially when the source is enumerating many addresses with no service-level follow-through.
How to separate noise from actionable reconnaissance
Most teams benefit from a simple triage rule: treat isolated ACKs as suspicious when they are unpaired with session establishment and recur across multiple targets. A single stray packet can be the result of retransmission, asymmetrical routing, or a misbehaving application, but a sequence of ACK-only probes across hosts is a stronger indicator of intentional mapping.
Context reduces false positives. Check whether the source belongs to a known monitoring system, whether the destinations are expected to receive health checks, and whether the packet timing matches approved scanning windows. Where none of those explanations fit, the lack of connection state becomes the main evidence. If your telemetry includes flow records, the absence of byte exchange after the probe is often more important than the packet count itself.
When the traffic is confirmed, preservation matters. Retain packet captures, firewall logs, and endpoint or sensor timestamps so investigators can reconstruct source, target range, and any subsequent attempt to pivot into a real session. ACK scans rarely end the story on their own; they are usually an early-stage discovery signal.
Risk and Threat Considerations
ACK scans are a reconnaissance technique, but they also expose how much your perimeter depends on stateful inspection behaving correctly. If the control plane or detection stack treats isolated ACKs as routine noise, an attacker can map filtering behaviour, identify reachable services, and choose the next attack path with less friction.
Failure mechanism: The scan succeeds by exploiting the difference between a packet that is syntactically valid and a connection that is actually legitimate. Defenders that do not correlate packet flags with session state may miss the pattern, especially when the source spreads probes across many hosts or hides behind normal-looking source addresses.
Impact: Successful reconnaissance improves attacker targeting, helps distinguish filtered from unfiltered paths, and can precede deeper intrusion attempts against services that appear exposed or inconsistently protected.
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 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1595 — Active Scanning | ACK scans are a form of reconnaissance and active probing against exposed paths. |
| Recommendation — Map ACK-only probe bursts to Active Scanning and alert on repeated stateless destination sweeps. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks and network services are monitored to detect potentially adverse events | Detecting ACK scans depends on monitoring network traffic patterns and anomalous flows. |
| Recommendation — Correlate packet flags and flow state to detect suspicious ACK-only reconnaissance. | ||
| NIST SP 800-53 Rev 5 | SI-4 — System Monitoring | ACK scan detection is a monitoring use case for network and security telemetry. |
| Recommendation — Tune monitoring to flag ACK-only probes that lack an established session context. | ||
Practitioner Guidance
What to verify: Confirm that the alert is based on stateful correlation, not just on TCP flag inspection. The best detection logic ties ACK-only packets to missing handshake context, missing follow-on traffic, and repeated destination scanning within a short interval.
Decision rule: If the same source sends ACKs to multiple hosts without an established flow, escalate it as reconnaissance even when each individual packet looks harmless. If the traffic matches an approved scanner or a known asymmetrical routing pattern, document that exception and tune the correlation rather than suppressing the control.
Practitioner takeaway: ACK scan detection works best when analysts think in terms of connection state, not single packets; the absence of a believable session is the evidence that turns a normal-looking ACK into a meaningful security event.