# The mechanism and defense of TCP session hijacking, RST injection, and IP spoofing [2026] — RFC 5961/6528/BCP 38

> A systematic explanation of session hijacking / RST injection that seizes or severs an established TCP connection, and IP spoofing that forges the source — from the principle of sequence numbers to the defenses of RFC 5961 (challenge ACK), RFC 6528 (ISN randomization), and BCP 38 (ingress filtering). It explains from TCP's state transitions why blind injection succeeds and why it's hard today, and shows neutralization via TLS with type-safe code. All are legal procedures confined to an isolated lab.

- Published: 2026-06-28
- Author: 友田 陽大
- Tags: セキュリティ, ネットワーク, TCP/IP, TCP, 脆弱性診断, ホワイトハッカー
- URL: https://tomodahinata.com/en/blog/tcp-session-hijacking-rst-injection-ip-spoofing-defense-guide
- Category: 実践ネットワーク攻撃と防御
- Pillar guide: https://tomodahinata.com/en/blog/network-penetration-testing-methodology-attack-defense-guide

## Key points

- TCP session hijacking seizes an established connection by injecting a segment with the correct sequence number. RST injection forcibly severs the connection with a forged RST (abused for censorship and disruption).
- The key to success is the sequence number. On-path (already MITM), the number is visible so it's easy. Off-path (blind), guessing the number is needed, and it could become realistic depending on the window size — that was the threat.
- IP spoofing falsifies the source IP. Used for blind attacks, DDoS reflection/amplification, and bypassing trust-based authorization. In TCP, the brake is that you can't complete the connection unless you can guess the ISN.
- Defense ①: RFC 6528's cryptographic ISN randomization blocks number guessing. RFC 5961's challenge ACK makes blind RST/SYN injection greatly harder (with ACK throttling).
- Defense ②: BCP 38 (RFC 2827) ingress filtering drops spoofed sources at the route. And the final wall is TLS — even if the numbers are seized, encryption, integrity, and authentication protect the contents.

---

A connection established by [TCP's three-way handshake](/blog/tcp-three-way-handshake-state-transition-retransmission-congestion-control-guide) behaves, once connected, like "a single trusted pipe." But if an attacker can **inject just one segment with the correct sequence number** into that pipe — the receiver accepts it as legitimate data. This is **TCP session hijacking**, and firing a forged RST to **forcibly sever** the connection is **RST injection**.

Following [the big picture of network pentesting](/blog/network-penetration-testing-methodology-attack-defense-guide), this article unpacks these attacks and **IP spoofing** from inside TCP and shows defenses compliant with **RFC 5961, RFC 6528, and BCP 38.** The keys all lie in the fact that [TCP builds reliability with sequence numbers](/blog/tcp-three-way-handshake-state-transition-retransmission-congestion-control-guide).

> **Thoroughness of the safe zone**: all verification in this article is done only against **TCP connections between VMs you manage** in an [isolated lab](/blog/ethical-hacking-home-lab-kali-juice-shop-ctf-self-study-roadmap-guide). **Injecting RST into or seizing a third party's communication is a violation of the secrecy of communications and the Unauthorized Access Act and Telecommunications Business Act.** This article focuses not on the attack-launch procedure but on **understanding the mechanism and defense.** Always read the [legal article](/blog/ethical-hacker-law-japan-unauthorized-access-act-active-cyber-defense-disclosure-guide) first.

---

## 1. Why you can break into a TCP connection — the sequence number as the key

TCP judges whether a received segment is "the correct-position data for this connection" by the **sequence number alone** ([the core of TCP retransmission/ordering](/blog/tcp-three-way-handshake-state-transition-retransmission-congestion-control-guide)). Conversely — **if the 5-tuple (source/destination IP, port, protocol) matches and the sequence number is within the receive window**, that segment is accepted. The sender's "identity" is not verified.

```text
受信側が1つのセグメントを受理する条件：
  ① 5タプルが既存接続に一致（src/dst IP・src/dst port）
  ② シーケンス番号が「受信ウィンドウ」の範囲内
  → 満たせば、誰が送ったかに関わらずデータとして受理してしまう
```

Attacks split into two kinds.

- **On-path (MITM done)**: if you've seized the path via [ARP spoofing](/blog/arp-spoofing-mitm-attack-detection-defense-guide), etc., the sequence number is **observable.** Injection is easy.
- **Off-path (blind)**: the number is invisible, so **guessing** is needed. The space to hit depends on the "window size" — the larger the window, the easier to hit. This was the threat.

---

## 2. The three forms of attack

### 2.1 Session hijacking — "seize" the connection

When the attacker injects a **data segment** with the correct sequence number, the receiver processes it as legitimate data. If they can slip a malicious command into an authenticated session (e.g. a post-login TCP connection), they can seize control without passing authentication. After injection, the original sender's numbers drift and the connection breaks (an ACK storm), so the attacker needs to silence the original sender.

### 2.2 RST injection — "sever" the connection

Send a forged segment with the [RST flag](/blog/tcp-three-way-handshake-state-transition-retransmission-congestion-control-guide) set, with an in-window sequence number, and the receiver **immediately discards** the connection (`ECONNRESET`). This has a history of being abused for censorship and communication disruption (severing connections to specific sites wholesale). **One forged RST drops an established connection** — its ease was the danger.

### 2.3 IP spoofing — "forge" the source

Falsify the source IP. On its own, TCP returns the SYN/ACK in the [three-way handshake](/blog/tcp-three-way-handshake-state-transition-retransmission-congestion-control-guide) to **the genuine spoofed IP**, so the attacker can't receive the ISN and can't complete the connection (this is the brake). However —

- **Blind attack**: it can be completed if the ISN can be guessed (→ blocked by RFC 6528).
- **DDoS reflection/amplification**: with response-less UDP (DNS/NTP, etc.), spoofing the source as the victim concentrates responses on the victim (→ blocked by BCP 38).
- **Bypassing trust-based authorization**: breaks weak authorization like "allowed from this IP."

---

## 3. Defense ①: don't let the number be guessed — RFC 6528 (ISN randomization)

The premise of a blind attack is that "the sequence number (especially the ISN at connection start) can be guessed." [RFC 6528](https://www.rfc-editor.org/rfc/rfc6528) (Defending against Sequence Number Attacks) specifies **generating the ISN on a cryptographic-hash basis** and making it unpredictable per connection.

```text
ISN = M + F(localIP, localPort, remoteIP, remotePort, secretKey)
  M … 単調増加クロック
  F … 暗号ハッシュ（接続4タプル＋秘密鍵）。攻撃者は secretKey を知らないため推測不能
```

Modern OSes implement this by default. **So blind hijacking basically doesn't succeed on a decent stack.** "TCP hijacking is easy" is a story from an old era; ISN randomization ended it.

---

## 4. Defense ②: reject blind RST/SYN — RFC 5961 (challenge ACK)

Still, room remains that "with a large window, you can fire a forged RST whose number falls in range." [RFC 5961](https://www.rfc-editor.org/rfc/rfc5961) (Improving TCP's Robustness to Blind In-Window Attacks, 2010) blocks this with a **challenge ACK.**

The mechanism is this. **Even on receiving an in-window but not exactly matching RST, don't sever the connection immediately.** Instead, return a confirming ACK (challenge ACK) — "really sever?" — to the peer. A legitimate peer returns a consistent response; a forging attacker can't produce the correct response, so the connection is maintained.

```text
RFC 5961 の RST 受信時の判定（概念）：
  受信した RST.seq == 次に期待する受信シーケンス番号 → 正規。接続を閉じる
  受信した RST.seq がウィンドウ内だが不一致         → challenge ACK を返す（即閉じない）
  ウィンドウ外                                      → 黙って破棄
```

Furthermore, RFC 5961 defines **ACK throttling**: to prevent a flood of challenge ACKs (which itself can be abused for amplification), it sets an **upper bound on the number of challenge ACKs per window** (e.g. at most 10 in any 5 seconds).

> **Implication for designers**: these are defenses the OS's TCP stack handles, not something app developers write directly. That's exactly why **keeping the OS/kernel up to date** is the foundation of network-layer defense. An old kernel may not implement RFC 5961.

---

## 5. Defense ③: drop spoofed sources at the route — BCP 38 (RFC 2827)

The root-cause defense against IP spoofing (especially DDoS reflection/amplification) is to **drop spoofed packets at the network's entrance.** [BCP 38 / RFC 2827](https://www.rfc-editor.org/rfc/rfc2827) (Network Ingress Filtering) prescribes that ISPs and organizations "**discard packets with a source IP that couldn't come out of that network.**"

```text
ingress filtering の原則：
  顧客網 10.1.0.0/16 から出ていくパケットの送信元が 10.1.x.x でなければ破棄。
  → 攻撃者は「被害者のIP」を送信元に詐称したパケットを送り出せなくなる。
```

In the cloud, much of this is already done at the platform level. AWS's VPC, via the **source/destination check**, drops by default packets where an instance uses a source other than its own IP. On Linux too, **Reverse Path Filtering (`rp_filter`)** can drop packets whose return route is inconsistent.

```bash
# Linux: 受信パケットの送信元が「その経路から来るはずか」を検証（詐称を落とす）
sysctl net.ipv4.conf.all.rp_filter      # = 1 で厳格モード（環境により 2=loose）
```

---

## 6. The final wall: TLS — "even if the numbers are seized, protect the contents"

The defenses so far (ISN randomization, challenge ACK, ingress filtering) are at the network layer. But the most reliable is — **using TLS at the app layer.**

TLS places **encryption, integrity, and authentication** on top of the connection. Even if an attacker could inject TCP segments:

- The injected data fails TLS's MAC (message authentication) verification and is **detected as tampering.**
- The contents are encrypted, **unreadable even if observed.**
- Impersonation is **rejected** by certificate verification.

In other words, **under correctly verified TLS, TCP session hijacking has no real harm.** "Severance" via RST is still possible, but that's an availability issue; confidentiality and integrity are protected (and RST is made hard by RFC 5961).

```ts
import tls from "node:tls";

// アプリの通信は TLS で包む。TCP セグメント注入は MAC 検証で弾かれ「改ざん」として表面化する
const socket = tls.connect(
  { host: "api.example.com", port: 443, servername: "api.example.com" },
  () => {
    // authorized が false なら検証失敗。安全側（使わない）に倒す
    if (!socket.authorized) {
      socket.destroy(new Error(`TLS not authorized: ${socket.authorizationError}`));
      return;
    }
    socket.write("GET / HTTP/1.1\r\nHost: api.example.com\r\nConnection: close\r\n\r\n");
  },
);
socket.on("error", (e) => console.error("tls error:", e.message));
```

---

## 7. Summary

- **TCP decides acceptance by the 5-tuple + sequence number and doesn't verify the sender's identity.** So you can break in as long as the numbers match.
- **Three attacks**: session hijacking (seize), RST injection (sever), IP spoofing (source forgery).
- **Defense ① RFC 6528**: cryptographically randomize the ISN to block blind number guessing (default in modern stacks).
- **Defense ② RFC 5961**: make blind RST/SYN injection hard with challenge ACK + ACK throttling. **Keep the OS/kernel up to date.**
- **Defense ③ BCP 38**: discard spoofed sources at the route with ingress filtering / rp_filter. Cut off DDoS reflection/amplification.
- **The final wall is TLS**: even if the numbers are seized, encryption, integrity, and authentication protect the contents.

Next, we'll handle **[SYN flood / DDoS](/blog/syn-flood-ddos-attack-defense-syn-cookies-guide)**, which exhausts resources by abusing the half-open state of the handshake, defense-centrically.

---

I (Hinata Tomoda) have implemented "don't fully trust the connection" designs including TLS/mTLS conversion of production systems, kernel/OS security-update operations, and AWS VPC anti-spoofing (source/destination check, least privilege). "Does plaintext internal communication remain," "I'm anxious about old kernels' TCP vulnerabilities," "I want to ensure session integrity" — I diagnose such connection-layer hardening from the attacker's perspective and cure it with the two wheels of encryption and staying up to date. Feel free to reach out.