WiFi Deauthentication Detection Guide

WiFi deauthentication detection comes down to counting management frames. A deauth attack is a flood of spoofed deauthentication or disassociation frames that forcibly disconnect clients — the building block behind evil-twin and handshake-capture attacks. The frames are unauthenticated in the original 802.11 standard, so they are trivial to forge; the upside for defenders is that a wireless IDS sees the flood plainly. This guide ships the detection, explains why 802.11w/WPA3 helps and where it falls short, and lists the hardening.

A deauth flood is endpoint/network denial of service — T1498 — Network Denial of Service — and it is usually a precursor to adversary-in-the-middle, T1557. Detecting it early flags the recon before the real attack lands.

What is a WiFi deauthentication attack?

A deauthentication attack abuses a design flaw in 802.11: management frames — including deauth and disassociation — are sent unauthenticated and unencrypted, even on a WPA2/WPA3 network that encrypts your data. An attacker spoofs the AP’s or a client’s MAC address and sends forged “you are disconnected” frames, knocking devices off the network. It needs no password and no association.

The disconnect is rarely the end goal. It forces clients to reconnect, which an attacker uses to capture a WPA2 handshake for offline cracking, or to push them onto an evil-twin AP. That is why deauth detection is early warning for a larger attack.

What does a deauth attack look like, and what defends against it?

The throughline: PMF is the prevention, a WIDS is the detection, and you need both because PMF has known limits and not every client supports it.

How to detect WiFi deauthentication attacks

Detection needs a sensor that sees 802.11 management frames — a wireless IDS/WIPS (Kismet, nzyme, or vendor WIPS). Feed its events to the SIEM and threshold the flood.

index=wids sourcetype=kismet:alert (frame_type=deauth OR frame_type=disassoc)
| bin _time span=1m
| stats count AS frames, dc(dest_mac) AS clients by _time, bssid
| where frames >= 50
| sort - frames

A spike of 50+ deauth/disassoc frames a minute targeting one BSSID — especially hitting many clients — is an attack, not normal roaming. Tune the threshold to your environment’s baseline. Even on a PMF-protected network, the attempt is hostile reconnaissance worth alerting on.

A second, proactive query confirms your networks actually negotiate PMF, by reading the RSN information element your sensor records from beacons:

index=wids sourcetype=kismet:device type=AP
| eval pmf = if(match(rsn_capabilities,"MFPR|MFPC"),"enabled","disabled")
| search pmf="disabled"
| stats values(channel) by bssid, ssid

How to test your deauth detection

In a lab you own, on your own AP and an RF-isolated channel where possible:

1. Generate deauth frames against your own test client and confirm the WIDS flood rule fires.
2. Enable 802.11w (PMF) and confirm the test client stays connected during the flood — the control validating itself.
3. Read the RSN IE from your AP’s beacon and confirm PMF shows required/optional as intended; confirm the “PMF disabled” query is empty for production SSIDs.
4. Confirm a deauth attempt still alerts even when PMF prevents the disconnect.

How to harden against deauthentication attacks

• Verify the RSN IE, do not assume — confirm PMF is actually negotiated.
• Segment and monitor guest/IoT networks, which often lag on PMF support.
• Treat deauth alerts as evil-twin/handshake-capture precursors, and pivot to WPA2 PMKID detection on alert.

Common deauth-detection mistakes

• No 802.11 sensor. Standard network IDS (IP-based, like Suricata) never sees management frames; you need a WIDS/WIPS.
• Assuming PMF = done. Known bypasses and unsupported clients mean monitoring still matters.
• Not verifying the RSN IE. A network you believe is PMF-protected may not be.
• Treating it as “just DoS.” It is usually the opening move of a bigger attack.

WiFi deauthentication detection checklist

1. Deploy a wireless IDS/WIPS (Kismet, nzyme, or vendor) that captures 802.11 mgmt frames.
2. Forward WIDS events to the SIEM; threshold deauth/disassoc floods per BSSID.
3. Enable WPA3-only with MFPR=1 where supported; WPA2 + PMF optional for legacy.
4. Query the RSN IE to confirm PMF is negotiated; alert on PMF-disabled SSIDs.
5. Patch clients and APs for PMF-implementation flaws (e.g., CVE-2023-21061).
6. Alert on deauth attempts even when PMF blocks them (hostile recon).
7. Treat deauth alerts as evil-twin / handshake-capture precursors and pivot.
8. Test detection and PMF in an authorized lab.

The takeaway

WiFi deauthentication detection is a WIDS counting forged management frames, backed by 802.11w/WPA3 to make the forgery ineffective and patching to cover PMF’s limits. Alert on the attempt, verify PMF is really on, and treat every deauth spike as the opening move of a larger wireless attack — often a rogue AP, covered in evil twin access points: defensive controls. Continue with WPA2 PMKID capture detection and HackRF defensive RF awareness, or browse the full Hardware Security pillar.