← Back to Simulations
Network · Beginner 11 min read

Eavesdropping in Plain Sight: MITM Attacks on Unsecured Protocols

May 10, 2026

MITM Wireshark ARP spoofing network security TLS SSL stripping packet capture

Disclaimer: This simulation is for educational and defensive purposes only. Never use these techniques against systems you don't own or have explicit permission to test.

Overview

Many people assume their network traffic is private. In reality, any data transmitted over an unsecured protocol — or a poorly configured secure protocol — can be intercepted by anyone on the same network segment.

This simulation demonstrates a Man-in-the-Middle (MITM) attack on a local network, capturing and analysing traffic using Wireshark to expose sensitive data transmitted over unencrypted protocols.

Environment: This simulation uses a controlled lab setup. Never run these techniques on networks you do not own or have written permission to test.


Lab Setup

Topology

┌──────────┐     ┌──────────────┐     ┌──────────┐
│  Victim  │────▶│  Attacker    │────▶│ Internet │
│  (Alice) │     │  (MITM)      │     │  (Router)│
└──────────┘     └──────────────┘     └──────────┘
  192.168.1.5      192.168.1.10       192.168.1.1

Tools Used

  • Wireshark — Packet capture and analysis
  • Bettercap — MITM framework (or arpspoof from dsniff suite)
  • tcpdump — Lightweight CLI packet capture
  • A simple HTTP login page — Running on the attacker's machine for demonstration

Phase 1: ARP Spoofing — Becoming the Middleman

How ARP Works

The Address Resolution Protocol (ARP) maps IP addresses to MAC addresses on a local network. When a device wants to send traffic to another device, it broadcasts an ARP request: "Who has IP 192.168.1.1? Tell me your MAC address."

ARP has no authentication mechanism. Any device can respond to an ARP request, even if the response is false.

The Attack

The attacker sends forged ARP replies to both the victim and the router:

Attacker to Victim:   "192.168.1.1 is at AA:BB:CC:DD:EE:FF" (attacker's MAC)
Attacker to Router:   "192.168.1.5 is at AA:BB:CC:DD:EE:FF" (attacker's MAC)

Now all traffic between the victim and the router flows through the attacker's machine.

Verification

On the attacker machine, enable IP forwarding to ensure traffic flows:

# Linux
echo 1 > /proc/sys/net/ipv4/ip_forward

# Verify ARP table on victim machine (Windows)
arp -a
# Output:
#   192.168.1.1        aa-bb-cc-dd-ee-ff     dynamic
#   192.168.1.10       aa-bb-cc-dd-ee-ff     dynamic

Both the router and the attacker show the same MAC address — traffic is being intercepted.


Phase 2: Packet Capture with Wireshark

With ARP spoofing active, the attacker launches Wireshark on the interface connected to the victim's network.

Capture Filter

host 192.168.1.5 and not port 22

This captures only traffic to/from the victim, excluding SSH traffic (which is encrypted).

What We See

HTTP Login (Port 80)

The victim visits http://example.com/login and submits their credentials. In Wireshark, the attacker right-clicks the HTTP POST packet and selects "Follow TCP Stream":

POST /login HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0
Content-Type: application/x-www-form-urlencoded

username=alice.smith&password=S3cur3P@ssw0rd!

The credentials are visible in plaintext. This is the single most common MITM finding.

FTP Data Transfer (Port 21)

The victim connects to an FTP server to download a sensitive document:

220 FTP Server Ready
USER alice.smith
331 Password required
PASS S3cur3P@ssw0rd!
230 User logged in
RETQ confidential_report.pdf
150 Opening data connection
[Binary data transfer]
226 Transfer complete

Both the FTP credentials and the transferred file are captured. The attacker can reconstruct the PDF from the TCP stream.

DNS Queries

Every website the victim visits is visible via DNS queries:

Standard query 0x1234 A google.com
Standard query 0x1235 A login-bank.com
Standard query 0x1236 A internal-admin-panel.local

Even if HTTPS is used for the connection, the DNS queries reveal which sites are being visited.


Phase 3: SSL Stripping — Downgrading HTTPS

The Problem (for the attacker)

Many modern sites use HTTPS. If the victim visits https://bank.com, the traffic is encrypted and Wireshark shows only gibberish.

The Attack: SSL Strip

The attacker runs sslstrip (or Bettercap's http.proxy.sslstrip module), which:

  1. Intercepts the victim's HTTPS request
  2. Proxies it to the real server over HTTPS
  3. Sends the response back to the victim over unencrypted HTTP
  4. Modifies all https:// links in the response to http://
Victim requests:  https://bank.com/login
sslstrip changes: http://bank.com/login (links downgraded)
Attacker proxies: https://bank.com/login (real connection)
Response to victim served over HTTP (unencrypted)

If the victim doesn't notice the missing padlock icon, they submit their credentials over plain HTTP — and the attacker captures them.

HSTS Bypass

If the target site uses HSTS (HTTP Strict Transport Security), the browser will refuse the downgrade. However:

  • First-time visitors to a site are vulnerable before HSTS is cached
  • HSTS-preloaded domains (like bank.com) are protected, but subdomains may not be
  • Attackers can use techniques like HSTS stripping combined with a fake clock to expire the HSTS policy

Phase 4: Analysing Captured Traffic with Wireshark

Key Wireshark Features for Analysis

Statistics → Protocol Hierarchy

Shows which protocols are in use and their relative volume:

Protocol % Traffic Risk
HTTP 23% High — plaintext
DNS 5% Medium — reveals destinations
FTP 2% High — plaintext auth
HTTPS 60% Low — encrypted
SMB 10% Medium — may leak file/folder names

Statistics → Endpoints

Reveals every IP address the victim communicated with, sorted by data volume.

Follow TCP Stream

The critical feature for extracting plaintext data from any TCP connection.

Export Objects → HTTP

Extract any files transferred over HTTP (images, PDFs, documents).


Defensive Measures

For Users

Practice Why
Use a VPN Encrypts all traffic at the network level
Verify HTTPS Check the padlock icon — never enter credentials on HTTP
Avoid public Wi-Fi Use mobile hotspot or VPN on untrusted networks
Use DNS-over-HTTPS Prevents DNS snooping

For Organisations

Control Implementation
HSTS Preloading Submit your domain to browser HSTS preload lists
HTTPS-Only Policies HSTS with max-age=31536000; includeSubDomains; preload
Network Segmentation Guest networks separated from corporate networks
802.1X Authentication Prevents rogue devices from joining the network
Dynamic ARP Inspection (DAI) Switches validate ARP packets against the DHCP snooping database
Encrypted DNS Deploy DNS-over-HTTPS or DNS-over-TLS internally

Wireshark Filter Reference for Defenders

# Detect ARP spoofing
arp.duplicate-address-detected

# Detect suspicious HTTP traffic
http.request

# Detect DNS queries to known-bad domains
dns.qry.name contains "evil.com"

# Detect SMB traffic from unexpected hosts
smb and not ip.addr == 192.168.1.0/24

# Detect SSL stripping (HTTP on ports that should be HTTPS)
http and tcp.port == 443

Key Takeaways

  • Unencrypted protocols are the lowest-hanging fruit — HTTP, FTP, Telnet, and plain SMTP should never be used
  • ARP spoofing is trivially easy — any device on the same network segment can intercept traffic
  • SSL stripping defeats HTTPS if users aren't vigilant — always check for the padlock
  • Wireshark is your best friend for both attack and defence — learn it well
  • Network segmentation and encryption are the primary defences — everything else is secondary

"Wireshark doesn't break encryption. It reveals the terrifying amount of data we still send in plaintext." — Network security instructor