Machine in the Middle
Positioning yourself between two parties so all their traffic passes through you. The attack that authentication exists to prevent, and the analyst's primary tool for understanding a closed device.
A machine-in-the-middle attack places the attacker on the path between two communicating parties, so that everything flows through them. Both endpoints believe they are talking to each other. The attacker can read, modify, delay, drop or inject.
It is simultaneously the canonical network attack and the standard analysis technique: understanding what a closed IoT device says to its cloud is, in practice, always done by getting in the middle of it.
Getting into position
The interception is the easy part. Getting on the path is the work, and the method depends on the layer:
- ARP spoofing. On a local Ethernet or Wi-Fi segment, answer ARP requests claiming the gateway's IP. Both sides update their tables and route through you. Loud, effective, and detectable by anyone watching for duplicate MAC-to-IP mappings.
- Rogue access point. Broadcast the SSID the device expects. Devices with no server authentication associate happily; devices that also validate the network do not. Combined with deauthentication, this moves an already-connected client.
- DNS spoofing. Answer the DNS query first, or control the resolver, and the client connects to your address believing it is the right host.
- DHCP. Answer a DHCP request and you set the client's gateway and DNS. Simple, and often the cleanest on a lab bench.
- Physical. An in-line tap, a laptop with two interfaces bridging them, a modified cable. On a bench this is the most reliable option, and it needs no protocol trickery at all.
- BGP or upstream. Out of scope for a device assessment, and the reason certificate transparency exists.
What defeats it
Exactly one thing: the endpoints authenticating each other. Encryption alone is not enough, because the attacker in the middle simply terminates one encrypted connection and opens another.
tlswith proper certificate validation stops it, because the attacker cannot produce a certificate for the real hostname that chains to a trusted CA.- Certificate pinning stops it even against a compromised or coerced CA, by narrowing trust to one specific key.
- Mutual TLS additionally stops an attacker impersonating the client.
- On Bluetooth,
ble-mitmcovers the equivalent problem, where the pairing method decides whether the link is authenticated at all.
The recurring embedded failure is not weak cryptography. It is a client that encrypts but does not validate, which produces two perfectly encrypted legs and a fully readable middle.
As an analysis technique
For a device assessment the workflow is routine: put the device on a network you control, force its traffic through a proxy, and install your own CA so the proxy can present certificates the device accepts.
mitmproxy is the standard tool. It terminates TLS, shows the plaintext, and lets you rewrite requests and responses live, which is how you test what a firmware update endpoint or a REST API actually enforces.
When the device pins its certificate, the proxy fails and the device usually just stops working. The normal answer is to patch the pin out of the firmware, or to extract the pinned key and impersonate it, which is why pinning is genuinely effective and also why it is not the end of the assessment.
Pitfalls
- A device that fails closed looks broken, not protected. Distinguish "it refused because validation worked" from "it crashed" before writing either down.
- Interception changes timing. Protocols with tight timeouts, and anything on a real-time bus, may behave differently just because you are there.
- Doing this to traffic you do not own is illegal, regardless of how easy it is. Keep it on a lab network with equipment you control.
- Not all traffic goes through the interface you are watching. A device with a cellular modem, or one that reaches its cloud over a second radio, will happily bypass your proxy.
What it pairs with
mitmproxy is the tool, tls explains what is supposed to stop it, wireshark shows what you captured, and ota-update is the highest-value thing to intercept on an embedded device.
Further reading
Used in these courses
**Advanced.** Hijack the update channel: map the OTA flow, MITM a channel with no TLS or pinning, exploit missing or weak firmware signing, and push a malicious image fleet-wide - the attack that correct Secure Boot stops.
REST API Recon on IoT Cloud Endpoints**Beginner** course (prereq: Hunting Hardcoded Secrets). Most IoT breaches today are the cloud REST API the device talks to. Cover endpoint identification, canonical IoT-cloud mistakes (no rate limit, IDOR, leaky firmware paths), curl + mitmproxy workflow. Validation Box deployment pending.