Someone's laptop reconnects to "CorpGuest" in the break room without a single click. No prompt, no password screen, nothing to approve. Twenty minutes earlier, a small radio sitting in a backpack under the same table started broadcasting an access point with that exact same name, and every device in earshot that has ever joined "CorpGuest" before treats it as the same network it already trusts.
That's the entire opening move of an evil-twin attack, and it's why it still shows up in nearly every wireless engagement worth doing, years after "don't click phishing links" became standard onboarding material. It doesn't ask anyone to click anything. It exploits a much older assumption: client devices remember network names, not network identities, and most Wi-Fi security models never actually made the access point prove who it is.
Here's the mechanic. Every device that has joined a network before periodically probes for it by name, sometimes broadcasting the SSIDs it remembers, sometimes just willing to associate silently the moment it hears one. An attacker doesn't need to guess those names; passively capturing the surrounding air for a few minutes with something like airodump-ng usually hands over a list of SSIDs devices nearby are already trusting. Point a second radio, running hostapd or a tool built for exactly this, at broadcasting one of those names with a stronger, cleaner signal than the real access point, and devices that already trust that name reconnect to whichever radio answers loudest. If the real network needs a bit of a push, a handful of deauthentication frames aimed at a connected client is usually enough to force a reconnect, and reconnect it will, to whichever AP answers fastest with the name it's looking for.
Once a client lands on the rogue AP, the rest is deliberately mundane: a captive portal that looks exactly like the real SSO login page, or, on an open guest network, no portal needed at all because the traffic was never encrypted between client and AP in the first place. Either way, the attacker is now the network. Every DNS query, every plaintext credential, every session cookie sent over HTTP instead of HTTPS is visible before it ever leaves the building.
The part worth sitting with is why this keeps working: on WPA2-PSK and on most guest networks, the client authenticates itself to the network, but the network never has to prove itself back. The 802.11 handshake checks whether the client knows the right password; it does essentially nothing to confirm the access point answering is the one the organization actually deployed. Any radio that knows the SSID and the PSK, or needs neither because it's an open guest network, is indistinguishable from the real thing to a device that's just looking for a familiar name.
The fix that actually closes this gap is WPA3-Enterprise with 802.1X and EAP-TLS, where the client validates the RADIUS server's certificate before it ever sends credentials, the same way a browser is supposed to validate a TLS certificate before submitting a login form. An evil twin can clone an SSID for free; it cannot forge a certificate signed by a CA the client already trusts. That single certificate check is the difference between "sounds like the right network" and "is the right network," and it's the one control an SSID clone has no answer for.
This is the exact chain, from passive SSID harvesting through rogue AP setup to captive portal credential capture and the certificate-based defense that actually stops it, that Codelivly's Man-in-the-Middle Attack Book walks through with the real tools (hostapd, mitmproxy, ettercap) instead of just the theory. If wireless assessments aren't part of your toolkit yet, the free Wireless & Social Engineering learning path on codelivly.com is the place to build the muscle before you're doing it against a real client network.
Top comments (0)