Rogue Access Points and Client Deauthentication
This domain tests the classic wireless man-in-the-middle chain: knock a client off its real AP, present a look-alike AP, and harvest credentials or traffic.
Deauthentication
A deauth is an unauthenticated management frame (subtype 12) carrying a reason code, with the source address spoofed as the AP. aireplay-ng -0 10 -a <AP> -c <client> wlan0mon sends ten frames; -c FF:FF:FF:FF:FF:FF broadcasts. 802.11w (Management Frame Protection), mandatory in WPA3, authenticates unicast deauth and disassociation frames, so the classic attack simply fails on PMF networks.
Rogue access points
airbase-ng -e "CorpWiFi" -c 6 -P wlan0mon creates a soft AP bound to the at0 interface; -P answers every probe request regardless of SSID, the Karma behaviour. A convincing evil twin clones the ESSID and channel, beacons with stronger signal, and waits while you deauth clients off the legitimate BSSID. For a full AP use hostapd with dnsmasq for DHCP, iptables NAT for uplink, and a captive portal to collect credentials. Against WPA2-Enterprise, hostapd-wpe or eaphammer captures the MSCHAPv2 challenge/response for offline cracking.
Worked example
A client stubbornly stays on the real AP despite your beaconing twin. Reasoning: clients roam on signal strength and only reassociate when the current link degrades or is torn down, so a beacon alone is not enough. The sequence is to deauth the client from the real BSSID while the twin beacons on the same channel; the client scans, sees the familiar SSID at high signal, and joins. If PMF is active the deauth is ignored, so you must wait for natural reassociation or change vector.
Traps
- Forgetting to bring
at0up and give it an address or DHCP pool. - Running the twin on a different channel from the target - clients associate on the AP's channel.
- Deauthing so aggressively that the client gives up and the user notices.
- Skipping the bridge/NAT to the uplink, so the victim gets no internet and abandons the portal.