802.11 · WiFi
Evil twin and rogue AP the network that lies
Rogue, evil twin and the cafe next door look identical from the air, and the word everyone uses for them means three different things depending on the vendor. This plate draws the line precisely, shows why the attack needs no exploit at all, and ends where honesty requires: with the three things that bind an access point's identity, and the legal bill for knocking the wrong one off the air.
Three things that get confused, and one question that separates them
Ask what a rogue access point is and you will get the street answer: a fake network pretending to be yours. The vendors who build the detection systems mean something much narrower. Aruba: “An AP is considered to be rogue if it is both unauthorized and plugged in to the wired side of the network. An AP is considered to be interfering if it is seen in the RF environment but is not connected to the wired network.” Extreme: “A rogue AP is defined as an unsanctioned BSS (Basic Service Set) that is attached to your sanctioned wired infrastructure.” Both require two halves — unauthorized AND on your wire. An evil twin out on the sidewalk, copying your SSID and touching nothing of yours, satisfies only the first, and so it is not a rogue in either taxonomy.
That is not pedantry, because the classification decides who owns the problem. A rogue leaves physical evidence: it is learned on a port of your switch and it shows up in your MAC table, so the fix is a walk and a shutdown. An evil twin leaves none, because it was never inside. And the consequence is genuinely uncomfortable: Aruba writes of the interfering AP that “it is not considered a direct security threat since it is not connected to the wired network.” The device that can actually rob your users is, to the enterprise system watching, not a direct threat. The classification is not wrong — it is measuring risk to the network, and you were asking about risk to the user. Cisco complicates it further by using rogue for anything: “Any device that shares your spectrum and is not managed by you can be considered a rogue.” The same word means different things depending on whose console you are reading.
Why it works: the client picks by name, and signal breaks the tie
There is no exploit in this attack. The FCC, describing the protocol in its own enforcement document, puts it plainly: “This process occurs in three primary steps: the client first probes, then authenticates, and finally associates with the access point.” Nowhere in those three steps does the network have to prove it is the one you meant. Apple publishes the full order in which its devices choose between known networks, and it is the most useful public description of what is used as a network's identity: preference, privacy, public networks, configuration method, Wi-Fi standard, band, security, and finally signal strength. The BSSID is not among the eight. What identifies a saved network is its name plus its security type — exactly the pair an attacker copies whole — and the tie is broken by the one criterion an attacker controls directly, by turning up the power. CISA describes the attack in precisely those terms.
Which is why the common advice is not advice. Confirming the network's name is what the attack copies. A suspiciously strong signal is the symptom, not a test a user can run. And a modern phone does not defend itself here: MAC randomization is a privacy control against tracking, and says nothing about the identity of the access point. One documented safeguard does bite, and it is narrow — Apple will not auto-join an open network that was not manually joined in the past two weeks, unless it was installed as a managed network in the last twenty-four hours. It is worth noting what cannot be claimed too: the popular story that a phone broadcasts the names of all its saved networks is not supported by any admissible source, and Apple states the opposite outright — a probe carries the SSID only when the network is hidden, “not otherwise”. Hiding an SSID therefore inverts the problem, making the client publish the name instead of the AP.
Only a private key binds identity
Everything an access point declares about itself can be repeated by somebody else: the SSID is a text field, and the Wi-Fi Alliance notes that “MAC addresses and BSSIDs can be obtained easily by sniffing packets on a Wi-Fi channel.” The capabilities can be copied downwards, which is the whole downgrade attack. Only what an AP must prove with a private key it holds is inimitable, and that leaves exactly three defences. On an open network there is none, and OWE does not supply one: RFC 8110 §7 says “Opportunistic encryption does not provide authentication. The client will have no authenticated identity for the access point, and vice versa”, and describes the impersonation attack in the same section. With a shared password the credential is symmetric, which the Wi-Fi Alliance spells out in the background to SAE-PK: “an adversary with knowledge of the password can launch a man-in-the-middle attack on client STAs by impersonating an AP. This is sometimes known as an ‘evil twin AP’ attack.” The sign on the counter showing the password is the vector. SAE-PK is the repair, turning the password into a fingerprint of the AP's public key — but only in SAE-PK Only mode, because a client that still accepts plain PSK can still be downgraded.
On 802.1X the defence is normative and precise. WPA3 Specification v3.5 §5.1: “A WPA3 STA shall perform server certificate validation when using EAP-TTLS, EAP-TLS, EAP-PEAPv0 or EAP-PEAPv1 EAP methods”, and when that validation fails, “the STA shall not enter into Phase 2 of the EAP exchange.” That single clause is the line between stolen credentials and safe ones, because Phase 2 is where the username and password travel. And the same specification leaves a door: User Override of Server Certificate lets a user accept a certificate the device does not trust, which is why the operator's real control is the certificate policy — TOD-STRICT or TOD-TOFU in the Certificate Policies extension — that forbids the override outright.
The proof is in the wire, and the twin is never in it
Detection systems resolve the honest question — is this thing inside my building? — by crossing what they hear in the air with what they see in the copper. Aruba matches the discovered AP's traffic against the customer's wired MAC addresses, with methods it calls Plus One, Minus One, Equal and OUI. Cisco does the same over the switch CAM table, matching “+1/−1 the rogue MAC address, any rogue client MAC addresses, or an OUI match”. Extreme computes a BSS MAC address range from the wired AP's MAC. All three lean on the same manufacturing pattern — in a typical AP the Ethernet MAC and the radio BSSIDs come out of a contiguous vendor block — which is the seam where this plate meets the MAC-address plate and the switch MAC table of the wired volume. It is a habit of manufacturing turned into forensic evidence, and it works.
It works, and it cannot see the evil twin, because the evil twin is not on the wire. What is left is the name. Cisco's rule condition for exactly this case is called Managed SSID: “Requires that the rogue access point's managed SSID (the SSID configured for the WLAN) be known to the controller.” Which means the most capable detection system in the building catches the twin by the name of the network — the same weak clue the client used. That is the honest end of the story, and it is why the last phase of the plate is about containment and the law: knocking somebody else's access point off shared spectrum is a legal decision, and in the United States it has been settled with money. Marriott's consent decree of 600,000 USD (FCC DA 14-1444) is the canonical case, and the Enforcement Advisory that followed leaves no room: no commercial establishment may intentionally block or disrupt personal Wi-Fi hotspots on its premises.
