Sequence Number Spoofing

How sequence number spoofing works

TCP relies on sequence numbers to keep packets in order and to confirm delivery. In a sequence number spoofing attack, the attacker forges those values instead of waiting for the legitimate endpoint’s traffic, which can let them inject data into an existing session or disrupt the expected flow. The attack succeeds when the sequence space is predictable enough, or when the attacker can observe enough traffic to infer the valid values.

The practical issue is not only packet ordering. If an adversary can place believable sequence numbers into an active connection, the receiver may accept traffic that appears to belong to the session, which turns a transport-layer control into an entry point for manipulation. This is why older stacks that use weak or predictable sequence generation are more exposed than stacks with stronger randomisation.

Why sequence number spoofing is dangerous

At a protocol level, sequence numbers are part of the trust model that keeps a TCP conversation coherent. When they are guessed or observed, an attacker may be able to desynchronise endpoints, inject commands, reset a connection, or impersonate one side of the exchange. That makes the attack relevant anywhere TCP sessions carry authentication material, administrative traffic, or other high-value data.

Because the attacker is abusing a control the protocol itself depends on, the damage can be subtle. A session may remain visibly “up” while the payload is altered, dropped, or replayed in a way that is hard to distinguish from network instability. For this reason, sequence spoofing is often discussed alongside session hijacking and traffic injection rather than as a stand-alone packet-format problem.

How organisations reduce exposure

Exposure starts with where TCP sessions are exposed and how sequence values are generated. Internet-facing services, legacy systems, and devices that accept unauthenticated or partially trusted traffic deserve particular scrutiny. Strong TCP randomisation, modern stack hardening, and transport protections such as encryption and integrity checks reduce the attacker’s ability to predict or manipulate the stream.

Verification is also important. Security teams should review vendor guidance for the operating systems, appliances, and embedded products in use, then test whether the environment still depends on predictable transport behaviour. Where legacy systems cannot be replaced quickly, compensating controls such as segmentation, restricted exposure, and encrypted tunnels can limit the blast radius of a successful spoofing attempt. For protocol context and registry references, IANA remains the canonical source for Internet protocol parameter registries.

Detection and response after suspicious session activity

Sequence spoofing is often detected indirectly, through symptoms such as unexpected resets, duplicate or out-of-window packets, session desynchronisation, or application behaviour that changes without a corresponding authentication event. Network and host telemetry should be correlated so that transport anomalies can be separated from normal retransmission or congestion effects.

If compromise is suspected, responders should assume the session may have been tampered with even when credentials were not directly stolen. That means reviewing the affected connection, validating whether any commands or data were accepted from an unauthorised source, and checking for broader access that may have been gained through the spoofed stream. A packet-level anomaly can be the first visible sign of a larger trust failure, so post-event review should include the endpoints, the path, and any actions taken during the suspicious session.

Related resources from NHI Mgmt Group

• How do attackers use TCP Sequence Number Probe?
• How can security teams detect TCP sequence number probes?
• What mitigations reduce the risk of a TCP sequence number probe?
• Monotonic Sequence Number