Evil Twin / Rogue Wi-Fi Access Point
Also known as: Evil twin, Rogue access point, Rogue AP, Fake hotspot, Wi-Fi impersonation
A wireless impersonation attack where an unauthorised access point advertises a trusted network name so nearby devices join it and expose credentials and traffic.
Watch it in 60 seconds
How it works
An evil twin is a wireless access point that is not part of the organisation's network but advertises the same network name as a trusted one. Devices choose networks largely by name and signal strength, so a client in range may join the impostor believing it is the real network.
Once a client is associated, the impostor sits in the path of that device's traffic. It can observe unencrypted traffic, present a fake sign-in page to harvest credentials, or relay requests to the real network while recording them. Open networks and shared pre-shared-key networks are the easiest to imitate because the client has no way to cryptographically prove which access point it is talking to.
Defenders see the attack as inconsistencies. The same SSID appears from a hardware address that is not in the managed inventory, often on an unusual channel or with weaker security. Clients may be nudged away from the genuine access point by bursts of management frames, which appear in wireless-controller logs as repeated deauthentication or disassociation events followed by a re-association elsewhere.
The decisive protection is mutual authentication. WPA2/WPA3-Enterprise with 802.1X makes the client validate the authentication server's certificate before sending credentials, and protected management frames stop forged disconnects. A device configured to trust any server certificate, or an open guest network with a branded sign-in page, gives the user no reliable way to tell the real network from the twin.
Walk through it
- 1One name, two radios
- 2Why did clients leave?
- 3Inspect the sign-in page
- 4Contain and harden
The wireless controller raised a duplicate-SSID alert at the hotel. Compare the beacons against the authorised AP inventory and identify the hardware address that does not belong.
$ wids list --ssid HarbourviewGuestBSSID CH SEC VENDOR-OUI MANAGEDa4:2b:b0:11:3c:80 36 WPA2-ENT Aruba yesa4:2b:b0:11:3c:c0 149 WPA2-ENT Aruba yes02:5e:c0:17:9b:44 6 OPEN unregistered no# Authorised inventory: only the two Aruba radios above.
Spot it
- An SSID from your estate is advertised by a BSSID that is not in the managed AP inventory.
- Same SSID with a different security mode (for example open instead of WPA2/WPA3-Enterprise) or an unexpected channel.
- Bursts of deauthentication or disassociation frames for one or many clients, followed by re-association to a different BSSID.
- Sensors in different locations hear a managed SSID at implausible signal strength from an unknown vendor prefix.
- Users report a sign-in or certificate warning page on a network that normally connects silently.
- Authentication-server logs show clients abandoning EAP exchanges or failing certificate validation.
Wireless controller / WIDS
ts=2026-10-11T09:41:55Z event=deauth_burst client=9c:b6:d0:44:1a:7e src=a4:2b:b0:11:3c:80 count=24 window=2s pmf=off
ts=2026-10-11T09:41:56Z event=assoc client=9c:b6:d0:44:1a:7e bssid=02:5e:c0:17:9b:44 ssid=HarbourviewGuest managed=false
ts=2026-10-11T09:42:10Z event=rogue_detected bssid=02:5e:c0:17:9b:44 ssid=HarbourviewGuest sec=open channel=6 sensor=LOBBY-2kqlManaged SSID advertised by an unmanaged BSSID
WirelessBeacons
| where Ssid in ("HarbourviewGuest", "HarbourviewCorp")
| join kind=leftanti (ManagedAccessPoints | project Bssid) on Bssid
| project Timestamp, Ssid, Bssid, Channel, Security, SensorNameAssumes a beacon table from your WIDS and an authoritative managed-AP inventory table.
splDeauthentication bursts per client
index=wireless event=deauth
| bin _time span=10s
| stats count by _time client
| where count > 10Tune the threshold to your normal roaming and controller behaviour.
Stop it
Use 802.1X with server-certificate validation
WPA2/WPA3-Enterprise makes the client authenticate the network as well as the network authenticating the client. Push a profile through device management that pins the trusted CA and server name and forbids users from accepting unknown certificates, so an impostor cannot complete the exchange.
Require protected management frames and WPA3
Protected management frames (802.11w) and WPA3 stop forged deauthentication and disassociation from being accepted, removing the easy way to push clients off the genuine network. WPA3 also protects open guest networks with opportunistic encryption.
Monitor the air and the inventory
Run wireless intrusion detection or controller rogue detection against an authoritative AP inventory, classify unknown radios, and enable policy-based containment and physical location workflows. Pair this with user guidance never to enter corporate credentials on a sign-in page reached over a shared network.
Managed Wi-Fi profile (illustrative)
Hardened
ssid: HarbourviewCorp
security: wpa3-enterprise
pmf: required
eap:
method: eap-tls
trusted_ca: harbourview-root-ca
server_names: [radius.harbourview.example]
allow_user_trust_prompt: false
auto_join: trueField names vary by device-management product; the intent is certificate pinning and no user trust prompt.
- Maintain an authoritative inventory of authorised APs and alert on any other radio advertising your SSIDs.
- Require protected management frames and prefer WPA3 on all managed networks.
- Use certificate-based authentication (EAP-TLS) or at minimum validated server certificates for enterprise Wi-Fi.
- Disable user prompts that let people accept unknown certificates or auto-join open networks.
- Use a VPN or zero-trust access path for corporate resources over untrusted networks.
- Serve any guest sign-in page over HTTPS from a domain you control and never ask for corporate credentials on it.
If it already happened
Classify the unknown radio as rogue, enable policy-based containment where your controller and local rules allow, and send staff to the estimated location. Do not touch third-party networks outside your own premises.
Physically locate and remove the device. Identify clients that associated to it and any credentials entered on its sign-in page, then reset those credentials and revoke active sessions.
Require protected management frames and enterprise authentication on the impersonated SSID, push the managed profile to devices, and notify affected users with plain instructions.
Record the BSSID, channel, timeline and lure page, add them to detections, close the inventory gap that delayed discovery, and add rogue-AP exercises to wireless monitoring runbooks.
Check yourself
1. WIDS reports your corporate SSID advertised by a BSSID that is not in the managed inventory, using open security on an unused channel. What is the most likely classification?
2. Which control most directly stops forged deauthentication frames from forcing clients off the genuine access point?
3. Which configuration best prevents a client from sending its credentials to an impostor access point on an enterprise network?