Ethical Hacking Lesson 31 – MITM Attacks | Dataplexa
System & Network Attacks · Lesson 31

MITM Attacks

Sniffing captures traffic that happens to pass your way. A man-in-the-middle attack is more deliberate — you position yourself between two communicating parties and route all their traffic through your machine. Everything they send to each other, you read first.

How man-in-the-middle works

In a normal network conversation, packets travel directly between two hosts. A MITM attack inserts a third machine into that path — transparently forwarding traffic between the two parties while reading or modifying it. Neither party knows the attacker is there. From their perspective, the conversation is happening directly between them.

The key word is transparent. A MITM attack that breaks the connection is not a MITM — it is a denial of service. The attacker must forward traffic correctly while intercepting it, which requires the traffic to be actively routed through the attacker's machine rather than simply observed from the side.

ARP spoofing — poisoning the address table

The Address Resolution Protocol maps IP addresses to MAC addresses on a local network. When a device wants to send data to 192.168.56.101, it broadcasts an ARP request asking "who has 192.168.56.101?" The device with that IP responds with its MAC address, and the sender caches the mapping.

ARP has no authentication. Anyone can send an ARP reply claiming any IP belongs to their MAC address — and other devices will trust it. ARP spoofing exploits this by sending forged ARP replies to both the victim and the gateway, telling each one that the attacker's MAC address belongs to the other's IP. Both parties update their ARP cache and start sending all traffic to the attacker's machine instead of each other.

Enable IP forwarding on the attacker's machine and all that traffic gets forwarded to the real destination — transparently. The victim and gateway continue communicating normally. The attacker reads everything in between.

ARP SPOOFING — how traffic is redirected

Victim

192.168.56.101

All traffic

Attacker

192.168.56.102

Reads & forwards

All traffic

Gateway

192.168.56.1

ARP cache of victim says: Gateway MAC = Attacker MAC
ARP cache of gateway says: Victim MAC = Attacker MAC

Performing ARP spoofing with arpspoof

The scenario: You have a position on the same network segment as Metasploitable. The lab gateway is 192.168.56.1. You want to intercept all traffic between Metasploitable and the gateway — read HTTP sessions, capture any credentials transmitted in plaintext, and demonstrate to the client that a compromised machine on their network can silently intercept all unencrypted communications from other hosts on the same segment.

# Step 1 — Enable IP forwarding on Kali
# Without this, traffic arriving at Kali for the victim stops here
# and the victim loses connectivity — which defeats the transparent interception goal
# echo 1 writes the value 1 to the kernel IP forwarding parameter
echo 1 > /proc/sys/net/ipv4/ip_forward

# Step 2 — Send forged ARP replies to the victim
# arpspoof tells the VICTIM that the GATEWAY's IP belongs to OUR MAC address
# -i eth0  use the eth0 interface
# -t 192.168.56.101  target = the victim (Metasploitable)
# 192.168.56.1  = the gateway IP we are impersonating to the victim
arpspoof -i eth0 -t 192.168.56.101 192.168.56.1 &

# Step 3 — Send forged ARP replies to the gateway
# arpspoof tells the GATEWAY that the VICTIM's IP belongs to OUR MAC address
# Now traffic from gateway to victim also routes through us
# Run this in a second terminal — both need to run simultaneously
arpspoof -i eth0 -t 192.168.56.1 192.168.56.101 &

# Step 4 — Capture the intercepted traffic with tcpdump or Wireshark
# All traffic between victim and gateway now flows through this machine
# Capture it and read it the same way as Lesson 30
tcpdump -i eth0 -w /tmp/mitm_capture.pcap \
  host 192.168.56.101 and not port 22

Breaking it down:

arp reply 192.168.56.1 is-at [attacker MAC]
This is the forged ARP packet being sent to the victim. It tells the victim's ARP cache that the gateway's IP address belongs to the attacker's MAC address. From this point, every packet the victim sends "to the gateway" is actually sent to the attacker's machine. The victim has no way to detect this — ARP has no verification mechanism.
POST /dvwa/login.php — credentials in cleartext HTTP
The victim submitted a login form over HTTP — not HTTPS. The POST body containing username=admin&password=password is fully visible in the intercepted traffic. This demonstrates the compound risk: a flat network segment plus plaintext HTTP equals credential exposure to any compromised machine on the same VLAN. Neither vulnerability alone is as severe as both together.
not port 22 in the tcpdump filter
Excluding SSH traffic from the capture keeps your own Kali SSH session out of the output — otherwise every command you type over SSH would appear in the capture alongside the victim's traffic. This filter exclusion is a practical detail that matters when you are working remotely over SSH on the Kali machine.

SSL stripping — downgrading HTTPS to HTTP

Once positioned as a MITM, encrypted HTTPS traffic is still unreadable — the TLS encryption protects the content even if you intercept the packets. SSL stripping is a technique that exploits the moment when a user first navigates to a site — before HTTPS is established — to downgrade the connection to HTTP.

The attack works because browsers often initiate connections to websites over plain HTTP first, then get redirected to HTTPS. If an attacker intercepts that initial HTTP response and replaces the HTTPS link with HTTP, the browser connects over HTTP while the attacker connects to the real server over HTTPS — the user sees no obvious sign anything is wrong, but their traffic to the attacker is unencrypted.

HSTS — HTTP Strict Transport Security — was introduced specifically to defeat this attack. When a site has HSTS enabled and the browser has previously visited it, the browser refuses to connect over HTTP at all, regardless of what the attacker does to the connection. Modern browsers also maintain an HSTS preload list of high-profile sites that are forced to HTTPS before any connection is made. SSL stripping still works against sites without HSTS and against users connecting to a site for the first time.

# SSL stripping using bettercap — a modern MITM framework on Kali
# Requires ARP spoofing to already be running (or bettercap handles both)
# Active attack — only run in your authorised lab environment

# bettercap is an all-in-one MITM framework — handles ARP spoofing,
# SSL stripping, credential capturing, and packet modification together

# Launch bettercap targeting the lab network
# -iface eth0  the network interface to use
bettercap -iface eth0

# Once inside bettercap's interactive console:
# Turn on ARP spoofing — poisons the whole subnet by default
# net.probe on  discovers hosts on the network
# arp.spoof on  begins ARP poisoning on all discovered hosts

# Enable the SSL stripping module
# This intercepts HTTPS redirects and rewrites them to HTTP
# https.proxy on

# Enable credential sniffer — extracts credentials from intercepted HTTP traffic
# net.sniff on

# Or run all three as a single command when launching
bettercap -iface eth0 -eval "net.probe on; arp.spoof on; net.sniff on"

Breaking it down:

bettercap handles ARP spoofing and sniffing together
bettercap combines everything needed for a MITM into one interactive framework — host discovery, ARP poisoning, SSL stripping, and credential extraction. The net.sniff module automatically parses intercepted traffic and extracts credentials from HTTP, FTP, Telnet, and dozens of other protocols — presenting them cleanly rather than requiring manual packet analysis.
Why HSTS defeats SSL stripping
HSTS instructs the browser — via a response header — to always use HTTPS for this domain for a specified period. Once the browser has seen this header, it refuses all HTTP connections to the domain entirely. The SSL stripper never gets a chance to intervene because the browser insists on HTTPS from the start. HSTS preloading extends this to the first visit by building the list into the browser itself.

What MITM attacks expose beyond HTTP credentials

Credential harvesting gets the headlines, but a MITM position enables considerably more. Once positioned between two parties, an attacker can modify traffic in transit — not just read it. This opens up attack categories that passive sniffing cannot reach.

Content injection

Injecting malicious JavaScript into HTTP responses. When the victim loads a web page, the attacker's code is inserted into the HTML — running in the victim's browser in the context of the legitimate site. This can steal cookies, redirect form submissions, or silently download further payloads. Content injection via MITM is significantly more powerful than a standard XSS attack because it does not require the target site to have an XSS vulnerability — the attack happens at the network layer.

DNS spoofing

In a MITM position, DNS queries from the victim pass through the attacker's machine. Intercepting and modifying DNS responses redirects the victim to attacker-controlled servers instead of the legitimate ones. The victim types their bank's URL and gets the attacker's phishing page instead — with the legitimate hostname still showing in the address bar because the DNS response was modified, not the URL.

Session token theft

Even when a site uses HTTPS, if the session cookie lacks the Secure flag, it can be transmitted over HTTP during the downgraded connection. Capturing this cookie and replaying it in a browser allows the attacker to take over the victim's authenticated session — without ever knowing their password. This is MITM combined with session hijacking, covered in depth in Lesson 41.

NTLM relay

In Windows environments, NTLM authentication challenges intercepted during a MITM can be relayed to other services. The attacker captures a challenge-response authentication exchange from one service and immediately replays it against another — authenticating as the victim to a second system without ever cracking the password. Responder and ntlmrelayx are the standard tools for this technique in internal network engagements.

Detecting and preventing MITM attacks

ARP spoofing leaves traces. ARP cache monitoring tools detect the moment a cache entry changes unexpectedly — when the MAC address associated with the gateway IP suddenly changes to a different machine, that is a detection event. Dynamic ARP Inspection on managed switches validates ARP packets against a trusted DHCP binding table and drops spoofed ones before they reach hosts.

MITM DEFENCES — layered approach
Control What it prevents Limitation
Dynamic ARP Inspection Switch validates ARP packets against the DHCP binding table and drops spoofed replies before they reach hosts Requires managed switches; static IPs need manual configuration
HTTPS + HSTS Encrypts traffic making interception unreadable; HSTS prevents SSL stripping by forcing HTTPS at the browser level Only covers web traffic; other plaintext protocols remain exposed
Certificate pinning Applications verify the server certificate against a pinned value — preventing interception using a rogue CA certificate even if the attacker has a trusted cert Implementation overhead; breaks when legitimate certs rotate
Network segmentation VLANs limit ARP spoofing blast radius — a compromised host can only target devices on the same VLAN, not the entire flat network Does not prevent attacks within the same VLAN segment

The table above reveals something important: no single control stops all MITM attacks. Dynamic ARP Inspection stops the spoofing but does not protect plaintext protocols. HTTPS stops credential exposure but does not stop DNS spoofing at the network layer. The only comprehensive defence is layering multiple controls — which also happens to be the argument pen testers make when clients push back on fixing "just one of these issues" at a time.

Teacher's Note: In real internal network engagements, ARP spoofing against a large subnet can destabilise network connectivity for legitimate users if not carefully targeted. Always specify the exact victim IP with the -t flag rather than poisoning the entire subnet. Broad ARP poisoning on a busy corporate network can cause noticeable packet loss — which is the kind of thing that gets a pen test noticed by the wrong people at the wrong time.

Quiz

Scenario:

A junior pen tester asks why ARP spoofing works — specifically why devices on the network accept and trust ARP replies from an attacker's machine rather than verifying them against a known-good source. What is the fundamental protocol weakness that makes ARP spoofing possible?

Scenario:

A pen tester is performing SSL stripping during an authorised MITM engagement. The attack works successfully against most sites the victim visits — downgrading HTTPS to HTTP and capturing credentials. However, when the victim navigates to their organisation's internal web portal, the browser refuses to connect over HTTP even though the attacker is stripping the HTTPS redirect. The pen tester checks and finds the portal has a specific HTTP security header configured. Which header is preventing the SSL strip from working?

Scenario:

A pen tester is running ARP spoofing on a busy corporate internal network during an authorised engagement. Within minutes of starting, the client calls to say multiple users are experiencing severe network slowdowns and dropped connections. The pen tester's arpspoof command did not specify a target — it is poisoning all hosts on the /24 subnet. What should they have done differently and what must they do immediately?

Up Next · Lesson 32

DoS Attacks

Denial of service attack types, how volumetric and application-layer attacks differ, and how organisations defend against them at scale.