How TCP Handshake Spoofing Exploits Sequence Numbers to Hijack Connections

Background

When a TCP three‑way handshake completes, both sides assume they have verified each other's IP addresses, but this assumption is false. The handshake only synchronizes 32‑bit sequence (Seq) and acknowledgment (Ack) numbers, which were designed in 1981 without strong security considerations.

Vulnerabilities in the TCP Handshake

Sequence and acknowledgment fields are only 32 bits long, limiting the space for randomness.

Both fields serve dual purposes: data ordering and connection validation. An incorrect Ack can be ignored as long as a later packet carries the correct Ack, allowing malformed packets to be discarded without breaking the connection.

Attack Demonstration

The following dialogue illustrates how an attacker (pretending to be client A) can exploit these weaknesses:

A: Hi B, I'm C, send number 5.
B: Hi C, I'm B, 5, send number 3.
A: Hi B, I'm C, 1, send number 6. I'd like example.net.
B: Hi C, I'm B, that's incorrect. Close the connection please.
A: Hi B, I'm C, 2, send number 6. I'd like example.net.
B: Hi C, I'm B, that's incorrect. Close the connection please.
A: Hi B, I'm C, 3, send number 6. I'd like example.net.
B: Hi C, I'm B, 6, send number 4. Here comes the data: ...

In this scenario, the server B cannot distinguish whether it is responding to the genuine client C or the spoofed attacker because the IP address is forged. The attacker must generate enough traffic to guess a valid sequence number; on average this requires about 120 GB of data, though it can range from 72 GB to 200 GB depending on luck. With a 1 Gbps VPS, the attack typically completes in roughly 17 minutes.

Injecting a payload (e.g., an HTTP GET request) after the handshake further increases the required traffic—approximately 152 GB, or about 20 minutes—while still appearing as a normal connection in the target’s access logs.

Mitigation

Because the TCP protocol itself does not provide robust authentication, the most effective defense is to add a separate security layer such as TLS. Even self‑signed certificates force the client to exchange additional encrypted data, which prevents the spoofing attack from succeeding. The article therefore recommends avoiding IP‑based authentication, not relying on IP whitelists, and always using a secure protocol (TLS/SSL) when confidentiality and integrity are required.