⚡ Project 02 — TCP/IP Attack Lab

Type: Attack lab (Linux VMs) Modules: 02 (TCP/IP Protocols), 04 (TCP/IP Attacks) Difficulty: ⭐⭐⭐

---

🎯 Objective

Exploit the trust assumptions baked into TCP's three-way handshake and sequence numbering: first by exhausting a service's connection backlog with a SYN flood, then by hijacking an established session with an off-path RST/data injection.

---

🛠 Setup

Three Linux VMs on the same virtual network:

VM	Role	Notes
Attacker	Runs hping3/Scapy	Needs to see traffic between Client and Victim for Part B (shared segment, hub-like network, or ARP-spoofed position from Project 01)
Victim	Runs a simple TCP service	A netcat listener (nc -lk -p 23) or a real Telnet server works well
Client	A legitimate user	Opens a normal Telnet/nc session to the Victim

---

🧩 Tasks

🔹 Part A — SYN Flood

1. On the Victim, start the test service and watch its connection state with ss -tan | grep SYN_RECV or netstat -tan.
2. From the Attacker, send a stream of SYN packets with spoofed source addresses toward the Victim's service port:

   sudo hping3 -S -p 23 --flood -a <spoofed_src_ip> <victim_ip>
   

   (or write an equivalent Scapy script looping IP(src=RandIP())/TCP(dport=23, flags="S")).
3. Observe the Victim's backlog filling with half-open SYN_RECV connections and the legitimate Client struggling or failing to connect.
4. Stop the flood and confirm the Victim recovers once the backlog drains.

🔹 Part B — Session Hijack / RST Injection

1. Start a normal Telnet/nc session from the Client to the Victim and keep it idle/active.
2. On the Attacker, sniff the session and record the current sequence number, ack number, source/destination IPs, and ports.
3. Craft a spoofed packet with Scapy using the Client's source IP/port and the correct next sequence number:
4. To kill the session: send a TCP(flags="R") packet and confirm the Client's connection drops unexpectedly.
5. To hijack the session: instead inject a TCP(flags="PA") packet carrying attacker-chosen data (e.g. a shell command) and observe it executed as if the Client sent it.
6. Compare what happens if the sequence number guess is wrong (the Victim should silently drop or challenge-ACK the packet).

---

✅ Verification Checklist

• Victim's backlog fills with SYN_RECV entries during the flood, visible via ss/netstat.
• Legitimate Client's connection attempt is measurably degraded during the flood.
• Backlog drains and service recovers once the flood stops.
• Correctly extracted sequence/ack numbers from a live sniffed session.
• Injected RST (or data) packet is accepted by the Victim and visibly affects the session.

---

📦 Deliverables

• Packet captures showing (a) the SYN flood traffic and (b) the single injected RST/data packet alongside the legitimate stream.
• The hping3 command or Scapy script used for the flood, and the Scapy script used for the injection.
• A short write-up explaining what was observed at each step and why the injected packet was accepted (matching sequence number within the receive window).

---

🚀 Stretch Goals

• Enable SYN cookies on the Victim (sysctl net.ipv4.tcp_syncookies=1) and re-run the flood — document how the behavior changes.
• Measure how long the flood takes to fill the backlog at different send rates, and estimate the backlog size from your results.
• Extend the hijack script to survive sequence number drift (recompute from a fresh sniff each time) for a more realistic long-lived hijack.

See also notes: [[04-01-tcp-syn-flooding]], [[04-03-tcp-session-hijacking]], [[04-04-rst-injection]], [[04-05-mitigations-syn-cookies-and-randomization]]