Man-in-the-Middle Attacks: How They Work and How to Detect Them
A man-in-the-middle (MITM) attack is one where the attacker inserts themselves into a communication path, invisibly, between two parties who believe they're communicating directly with each other. Alice thinks she's talking to Bob. Bob thinks he's talking to Alice. Both are actually talking to the attacker, who relays and potentially modifies everything that passes through.
ARP Poisoning
sequenceDiagram
participant V as Victim
(192.168.1.100)
participant ATK as Attacker
(192.168.1.50)
participant GW as Gateway
(192.168.1.1)
participant WEB as Web Server
Note over V,GW: Normal state: V knows GW MAC
rect rgb(40, 20, 20)
Note over ATK: ARP Cache Poisoning
ATK->>V: ARP Reply: 192.168.1.1 is at AA:BB:CC (attacker MAC)
ATK->>GW: ARP Reply: 192.168.1.100 is at AA:BB:CC (attacker MAC)
Note over V: ARP cache poisoned
Note over GW: ARP cache poisoned
end
rect rgb(30, 30, 40)
Note over V,WEB: Intercepted Communication
V->>ATK: HTTP request to bank.com (thinks this is gateway)
ATK->>ATK: Log credentials / modify content
ATK->>GW: Forward request (IP forwarding enabled)
GW->>WEB: Route to internet
WEB-->>GW: Response
GW-->>ATK: Response returns
ATK->>ATK: Inspect / modify response
ATK-->>V: Forward response to victim
end
Note over V: Victim sees normal webpage
unaware of interception
ARP cache poisoning attack - the attacker inserts themselves between victim and gateway by sending forged ARP replies to both parties
On a local area network, devices communicate using IP addresses but send data using MAC addresses at the Layer 2 level. ARP has no authentication - any device can broadcast gratuitous ARP responses claiming to be both the target victim and the default gateway. If an attacker sends "I am the gateway" to the victim and "I am the victim" to the gateway, both update their ARP tables. All traffic between victim and gateway now flows through the attacker.
Defense: Dynamic ARP Inspection (DAI) on managed switches. Static ARP entries for critical devices. 802.1X preventing unauthorized devices from being on the network.
SSL Stripping
SSL stripping targets the upgrade from HTTP to HTTPS. Many websites accept HTTP connections and redirect to HTTPS. If an attacker intercepts the initial HTTP request, they can complete the HTTPS connection to the real server while serving the decrypted content back to the victim over HTTP.
HSTS defeats this because browsers refuse to connect to HSTS sites over HTTP regardless of server offer. The HSTS preload list hardcodes major sites into browsers - they're never accessible over HTTP even on first visit.
Rogue Access Points as MITM Vectors
graph TD
subgraph "Rogue AP MITM Attack Flow"
SETUP["Attacker deploys
BLEShark Nano as
Rogue AP"]
SSID["Broadcasts target SSID
(e.g. CoffeeShop_WiFi)"]
DEAUTH["Deauth legitimate AP
(forces client reconnect)
(non-EU only)"]
CONNECT["Victim auto-connects
to strongest signal"]
PORTAL["Evil portal served
(fake login page)"]
CREDS["Credentials captured"]
PROXY["Traffic proxied through
attacker device"]
end
SETUP --> SSID --> DEAUTH --> CONNECT --> PORTAL --> CREDS
CONNECT --> PROXY
subgraph "What Attacker Can Do"
READ["Read unencrypted
HTTP traffic"]
STRIP["SSL strip HTTPS
downgrade attempts"]
DNS["DNS hijack to
phishing sites"]
INJECT["Inject content
into HTTP responses"]
end
PROXY --> READ & STRIP & DNS & INJECT
subgraph "Detection Indicators"
CERT["Certificate warnings
in browser"]
BSSID["Different BSSID for
known SSID"]
SIGNAL["Unusual signal
strength changes"]
DUP["Duplicate SSIDs
in scan results"]
end
Rogue AP MITM attack using the BLEShark Nano - combines evil twin, evil portal, and traffic interception in a single battery-powered device
A rogue AP is one of the cleanest MITM setups. When a client connects, the AP by definition sits between the client and the internet. No ARP poisoning needed - the client has voluntarily connected to the attacker's device.
The rogue AP position enables full DNS control, traffic interception of unencrypted protocols, SSL stripping, and captive/evil portal deployment. The limiting factor is HTTPS with HSTS - for well-configured browsers connecting to HSTS-preloaded sites, the attacker sees encrypted TLS data they can't read.
The Relationship Between Evil Portals and MITM
An evil portal isn't a pure MITM attack - it's closer to a phishing attack delivered through a network MITM position. A classic MITM is transparent. An evil portal is visible - Alice is presented with a page and asked to interact with it.
The BLEShark Nano's portal features operate in the evil portal model: it broadcasts an AP, serves HTML pages to connecting clients, and collects form submissions. It doesn't attempt to decrypt or intercept encrypted traffic from outside the portal page itself.
Detecting MITM Attacks
graph TD
subgraph "MITM Detection Methods"
direction TB
NET["Network Layer"]
NET --> ARP_MON["ARP table monitoring
(detect MAC changes)"]
NET --> DUP_IP["Duplicate IP detection
(Gratuitous ARP alerts)"]
NET --> WIDS["WIDS/WIPS alerts
(rogue AP detection)"]
TLS_L["TLS Layer"]
TLS_L --> CERT_PIN["Certificate pinning
(detect fake certs)"]
TLS_L --> HSTS["HSTS enforcement
(prevent SSL strip)"]
TLS_L --> CT_LOG["Certificate Transparency
(detect misissued certs)"]
USER_L["User Layer"]
USER_L --> LOCK["Check padlock icon
(HTTPS indicator)"]
USER_L --> DOMAIN["Verify domain name
(watch for typosquats)"]
USER_L --> VPN["Use VPN on
public WiFi"]
end
subgraph "BLEShark Nano Role"
SCAN_AP["Scan for rogue APs
(duplicate SSIDs)"]
TEST_PMF["Test for PMF
(802.11w protection)"]
PORTAL_TEST["Test portal security
(credential handling)"]
end
WIDS -.-> SCAN_AP
ARP_MON -.-> TEST_PMF
CERT_PIN -.-> PORTAL_TEST
Multi-layer MITM detection strategy - network monitoring, TLS verification, and user awareness each catch different attack variants
ARP poisoning detection: Dynamic ARP Inspection on managed switches. ARP monitoring tools (arpwatch) alerting on ARP table changes.
Rogue AP detection: Wireless Intrusion Detection Systems comparing broadcast RF against the authorized AP inventory. The BLEShark Nano's Deauth Checker passively monitors for deauth frame floods - deauth flooding and an unknown SSID simultaneously is a useful correlation signal.
Certificate validation failures: A MITM attacker presenting a fake certificate triggers browser warnings. Certificate pinning in mobile apps refuses any certificate other than its pinned certificate.
Why HTTPS Limits But Doesn't Eliminate MITM Risk
Residual MITM risk after HTTPS/HSTS: non-HTTP protocols that lack transport encryption, DNS queries (unless DoH or DoT is in use), applications that don't properly validate certificates, users who click through certificate warnings, and the evil portal attack vector which doesn't require breaking any crypto.
The BLEShark Nano is a tool for testing these gaps in authorized assessments. Setting up a rogue AP, connecting test devices, and evaluating what actually gets intercepted in your specific environment gives you concrete data on your exposure.