Andy Bedinger

About
Contact
Posts

Recreating the Man-in-the-Middle Coffee Shop Scenario

Threat actor at a coffee shop performs MITM on unsuspecting man in line. Any resemblance to six-fingered threat actors, living or dead, is purely coincidental.

4/6/2025

A threat that often comes up when modeling the threat of stolen credentials or data theft is a man-in-the-middle (MITM) attack. In this type of attack, a threat actor intercepts traffic between two parties and is able to read their communication, unbeknownst to either party. While this could happen a number of ways, a commonly-discussed scenario involves a coffee shop.

Coffee Shop Scenario Explained

A threat actor connects to WiFi at a coffee shop. Using free tools, he probes the network and views information about other connected devices. He selects one of the devices as his target in a MITM attack. By sending false information out on the network in the form of forged ARP replies, he tricks the victim device to think that his device is the Internet gateway. Now packets from the victim device which should be going out to the Internet flow instead to the attacker's device. His device sends the traffic on to the actual destination, and the reply traffic comes back to him, which he forwards on to the victim. The attacker is now in the middle of the communication flow.

Why I Tried This (in a Lab)

This is all theory until you do it. While threat modeling, you can say that an employee is in a coffee shop, and logs in to a company portal and a threat actor performs a MITM attack and steals their credentials. But how hard is that to do, and what mitigations would raise the cost to the attacker? I wanted to see this in practice. And, of course, I needed to do it in a controlled environment in a legal and ethical way.

How I Did It

I chose to use bettercap, a free tool available on GitHub. It's meant for Linux but not hard to get working on a Mac. Once you get it running, it's very easy to spoof a target:

net.probe on                     # Gather information about devices
net.show                         # Show a list of hosts on the network
set arp.spoof.targets VICTIM_IP  # I used my mobile device's IP here
arp.spoof on                     # Begin spoofing the target

What I Learned

I immediately saw the DNS and HTTPS requests being made by my phone as it ran things in the background. By filtering the stream of messages, I could see log entries generated as I browsed to various sites on the Internet using HTTPS, revealing the hostnames of the sites via Server Name Indication (SNI).

Actually attacking my phone was less than trivial. For one thing, as I expected, HTTPS attacks are quite complicated. While bettercap has an HTTPS proxy, the victim device browser gets a certificate error. The bettercap utility can generate self-signed certificates for sites as they're visited, but they of course aren't trusted by the victim device.

Turning on the HTTP proxy did allow me to keep my mobile device on HTTP while browsing a site. However, I had to manually put http:// in front of the site address to force my mobile device to start out with HTTP. And that only worked because the site I browsed to doesn't send an HSTS header and isn't on the HSTS preload list.

In general, it was obvious to me when ARP spoofing was working: the site I browsed to over HTTP loaded notably slower (granted, I was using an ancient laptop for the attacking device). I got better performance if I used set http.proxy.whitelist DOMAIN_HERE and set http.proxy.blacklist *. Using set http.proxy.sslstrip true to tell bettercap to replace HTTPS links with HTTP was necessary to keep my mobile browser from switching to HTTPS when I clicked on site links.

For an attacker to pull this particular attack off undetected, a number of things need to happen:

  1. The victim has to browse to a site over HTTP.
  2. The victim has to not notice their browser indicating they're using HTTP.
  3. The site cannot be on the HSTS preload list.
  4. The site either cannot send the HSTS reply header or the victim must never have visited the site before (which makes it highly unlikely the victim has credentials to the site).
  5. The attacker needs to be ready in advance. This is not a "drive-by" scenario.

Why This Matters

I highly encourage any security practitioner to lab up the threats they are modeling. There is nothing like seeing theory put into practice. It gives you a better sense of what the cost to the attacker really is, the relative skill needed to perform an attack, and what the mitigations are.

Here are some things that make this particular attack more difficult:

  • Modern browsers default to HTTPS if you don't specify a protocol.
  • Use of the Strict-Transport-Security header forces browsers to use HTTPS after the first visit.
  • Including a domain on the HSTS preload list means browsers will always use HTTPS for a site and all of its subdomains.

Do you want to try a MITM in a lab environment? All you need is two devices, bettercap (or similar), and an Internet gateway (home WiFi router).

Are you concerned about MITM attacks on web properties you manage? Make sure you're sending back an HSTS header for your domains, preferably on your base domain, and get your domain on the HSTS preload list.