A laptop reconnected to a fake Wi-Fi network with zero prompts, and that’s the whole attack

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 in a backpack under the same table started broadcasting an access point with that exact same name, and every device nearby that's 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 a big part of why it still shows up in wireless engagements years after "don't click phishing links" became standard security training. It doesn't need anyone to click anything. It exploits something older: client devices remember network names, not network identities, and most Wi-Fi security models never actually make the access point prove who it is.

The mechanic is simple once you see it. Devices that have joined a network before periodically probe for it by name, and some will associate silently the moment they hear a familiar SSID. You don't need to guess the names either, passively capturing the air for a few minutes with something like airodump-ng usually hands you a list of SSIDs nearby devices already trust. Broadcast one of those names from a second radio (hostapd works fine) with a stronger signal than the real AP, and devices reconnect to whichever radio answers loudest. If the legit network needs a push, a few deauth frames at a connected client force a reconnect, and it'll land on whichever AP is fastest to answer with the right name.

From there it's mundane on purpose: a captive portal cloned from the real SSO page, or nothing at all on an open guest network, since that traffic was never encrypted client-to-AP anyway. Either way you're now the network. DNS queries, plaintext creds, HTTP session cookies, all visible before any of it leaves the building.

Here's the part that actually explains why this still works: on WPA2-PSK and most guest networks, the client proves itself to the network, but the network is never required to prove itself back. The handshake checks whether you know the password. It does nothing to confirm the AP answering is the one IT actually deployed. Any radio that knows the SSID and PSK, or needs neither on an open network, looks identical to the real thing from the client's side.

The actual fix is WPA3-Enterprise with 802.1X and EAP-TLS, where the client has to validate the RADIUS server's certificate before sending any credentials, same idea as a browser validating a TLS cert before you submit a login form. Cloning an SSID costs nothing. Forging a certificate signed by a CA the client already trusts is a different problem entirely, and it's the one thing an evil twin has no answer for.

Codelivly's Man-in-the-Middle Attack Book walks through this whole chain, SSID harvesting, rogue AP setup, captive portal harvest, and the certificate-based defense, with real tools (hostapd, mitmproxy, ettercap) instead of just theory. If wireless assessments aren't in your rotation yet, the free Wireless & Social Engineering learning path on codelivly.com is a decent place to start before doing this against a real client network.