How to Detect WiFi Deauth Attacks on Your Network
A WiFi deauthentication attack disconnects devices from their access point by sending forged 802.11 deauth management frames. The frames look legitimate - there's no authentication on management frames in WPA2 - so the victim device just disconnects. Your phone drops. Your smart TV loses its connection. Your laptop starts reconnecting. To a user, it looks like the router is having a bad day.
Detecting that this is happening, rather than assuming it's a hardware fault or ISP problem, requires passive monitoring. This article covers how deauth detection works, what to look for in packet captures, and how the BLEShark Nano's Deauth Checker gives you an always-on passive sensor without needing a laptop or packet capture software.
Note on EU compliance: the BLEShark Nano's active deauth transmission feature is disabled in EU-region firmware per RED regulations. The Deauth Checker (passive detection) operates in all regions.
Table of Contents
- What Deauth Traffic Looks Like
- Passive Detection: Listening for Deauth Frames
- BLEShark Deauth Checker
- Packet Capture Method
- Wireless Intrusion Detection Systems
- False Positives: When Deauth Is Legitimate
- What to Do When You Detect Deauth
- Prevention: PMF and WPA3
What Deauth Traffic Looks Like
An 802.11 deauthentication frame is a management frame (type 0, subtype 12). It contains a destination MAC address (the device being disconnected), a source MAC address (spoofed to look like the access point), and a reason code explaining why the disconnection is happening. Common reason codes used in attacks: 1 (unspecified), 2 (previous authentication no longer valid), 3 (deauthenticating because station is leaving).
sequenceDiagram
participant ATK as Attacker
participant AP as Target AP
(BSSID: AA:BB:CC:DD:EE:FF)
participant C1 as Client 1
participant C2 as Client 2
participant DET as BLEShark Nano
(Deauth Checker)
Note over ATK,DET: Targeted Deauth Attack
ATK->>C1: Deauth (src=AP MAC, reason=7)
Repeat x100/sec
C1->>C1: Disconnected
C1->>AP: Reassociation
ATK->>C1: Deauth again immediately
Note over ATK,DET: Broadcast Deauth Attack
ATK->>AP: Deauth to FF:FF:FF:FF:FF:FF
(all clients)
C1->>C1: Disconnected
C2->>C2: Disconnected
Note over DET: Detection Observations
DET->>DET: Frame count: 100+ deauth/sec
DET->>DET: Source MAC: AP BSSID
(but signal from wrong direction)
DET->>DET: Reason codes: all identical
(legitimate varies)
DET->>DET: No corresponding
reassociation success
DET->>DET: ALERT: Deauth flood detected
Channel 6, target BSSID
Deauth attack traffic patterns - the BLEShark Deauth Checker identifies attacks by monitoring frame rates, reason code uniformity, and the absence of successful reassociations that would indicate normal network behavior.
In a real attack, these frames arrive rapidly - hundreds to thousands per second in a flood attack, or at lower rates in a targeted slow deauth that keeps a specific device from reconnecting. The source MAC address is spoofed to match the access point's BSSID, so the victim device trusts the frame and complies.
You cannot detect this attack by watching your device's behavior alone. The disconnection looks exactly like a normal AP-initiated disconnect. You need to be watching the radio spectrum - passively monitoring 802.11 management frames - to see the forged packets flying.
graph TD
subgraph "Deauth Attack Detection Pipeline"
subgraph "1. Capture Layer"
MON["Monitor Mode
Interface"]
HOP["Channel Hopping
All 2.4GHz channels"]
CAP["Frame Capture
Management frames"]
end
subgraph "2. Analysis Layer"
FILTER["Filter: Type=0
Subtype=12 (Deauth)
Subtype=10 (Disassoc)"]
RATE["Rate Analysis
Count frames/second
per BSSID"]
PATTERN["Pattern Detection
Burst vs single
Broadcast vs targeted"]
SOURCE["Source Validation
Is sender a known AP?
Check signal strength"]
end
subgraph "3. Decision Layer"
THRESH{"Exceeds
threshold?
(>5 deauth/sec)"}
FP_CHECK{"False positive
check"}
LEGIT["Legitimate:
Client roaming
AP maintenance
Firmware update"]
ATTACK["Attack detected:
Continuous deauth
Multiple targets
Anomalous source"]
end
subgraph "4. Response Layer"
ALERT["Alert admin"]
LOG["Log to PCAP"]
LOCATE["Direction-find
attacker"]
MITIGATE["Enable PMF
Switch to WPA3"]
end
end
MON --> HOP --> CAP --> FILTER
FILTER --> RATE --> PATTERN --> SOURCE
SOURCE --> THRESH
THRESH -->|"No"| LEGIT
THRESH -->|"Yes"| FP_CHECK
FP_CHECK -->|"False positive"| LEGIT
FP_CHECK -->|"Confirmed"| ATTACK
ATTACK --> ALERT
ATTACK --> LOG
ATTACK --> LOCATE
ATTACK --> MITIGATE
Deauth detection pipeline - from raw frame capture through rate analysis and pattern matching to attack confirmation, with both alerting and mitigation response options.
Passive Detection: Listening for Deauth Frames
Passive detection works by placing a radio in monitor mode on the channel you want to watch, capturing all 802.11 frames, and filtering for deauth and disassociation frames. You're not sending anything - you're just listening.
The challenge is that monitor mode requires specific hardware. Most consumer WiFi adapters and built-in laptop WiFi chips do not support monitor mode. They only receive frames addressed to them or broadcast frames. To see every frame on the channel (including frames addressed to other devices), you need a radio that supports promiscuous 802.11 capture.
A sudden burst of deauth frames - particularly if they all originate from the same BSSID and are addressed to either broadcast MAC (ff:ff:ff:ff:ff:ff, disconnects all clients) or a specific client MAC - is a strong indicator of an attack in progress.
The threshold matters. A single deauth frame is normal network management. Ten deauth frames per second from the same source to the same destination for 30 seconds is not.
BLEShark Deauth Checker
The BLEShark Nano's Deauth Checker is a passive monitoring mode that puts the radio in monitor mode and listens for deauth and disassociation frames. When the frame count exceeds a threshold within a rolling time window, the OLED displays an alert and the device vibrates (if haptics are enabled).
Setup is straightforward:
- Navigate to the WiFi menu on the BLEShark Nano
- Select Deauth Checker
- The device enters passive monitor mode on the current channel
- Optionally, lock to a specific channel or use channel hopping mode
In channel hopping mode, the BLEShark cycles through 2.4GHz channels (1-13) with a configurable dwell time per channel. This covers the full 2.4GHz band at the cost of reduced detection sensitivity on any single channel - you might miss a brief attack if it happens during the hop to another channel. For monitoring a specific known network, lock to that network's channel for continuous monitoring.
The Deauth Checker logs detected events with timestamps. You can review the log via the file portal to see when attacks occurred, how many frames were sent, and from what source MAC addresses. This is useful for documenting incidents and correlating deauth events with observed network outages.
For whole-building coverage, the Shiver mesh (available in 3/5/7/12/16-node packs) can deploy multiple BLEShark Nanos as distributed sensors. Using coordinated channel partitioning, each node monitors a subset of channels, and detection events propagate to the master node in real time. A mesh of three nodes covers all 13 channels simultaneously with no gaps.
Packet Capture Method
For deeper analysis, the BLEShark Nano also captures handshake and management frames to PCAP format. You can download PCAP files via the file portal and open them in Wireshark for detailed analysis.
In Wireshark, a display filter for deauth frames:
wlan.fc.type_subtype == 0x000c
For both deauth and disassociation frames:
wlan.fc.type_subtype == 0x000c || wlan.fc.type_subtype == 0x000a
To filter for deauth frames from a specific BSSID (replace with your AP's MAC):
wlan.fc.type_subtype == 0x000c && wlan.sa == aa:bb:cc:dd:ee:ff
Look at the rate of these frames in a time-based view. One or two deauth frames over a few minutes is normal network management. Hundreds per minute sustained over time is an attack. Also check the reason codes - legitimate management frames use specific reason codes for specific situations, while attack tools often use code 1 (unspecified) or code 3 for all frames indiscriminately.
Wireless Intrusion Detection Systems
Enterprise networks use Wireless Intrusion Detection Systems (WIDS) - usually built into managed AP platforms (Cisco, Aruba, Ubiquiti UniFi) - that continuously monitor for exactly this kind of attack. The APs act as distributed sensors, forwarding suspicious frame data to a central controller that applies detection rules.
graph LR
subgraph "Detection Method Comparison"
subgraph "BLEShark Deauth Checker"
BS_HOW["Passive monitor mode
Real-time frame counting"]
BS_PRO["Portable, instant setup
No infrastructure needed
Works on any channel"]
BS_CON["Single channel at a time
(channel hopping)
No containment"]
end
subgraph "Wireshark + Monitor NIC"
WS_HOW["Full packet capture
Display filter:
wlan.fc.type_subtype == 0x0c"]
WS_PRO["Deep analysis possible
PCAP for forensics
Granular filtering"]
WS_CON["Requires laptop
Manual analysis
Not real-time alert"]
end
subgraph "Enterprise WIDS"
WI_HOW["Dedicated sensors
24/7 monitoring
Baseline comparison"]
WI_PRO["Automatic alerting
Can contain attacker
Historical trending"]
WI_CON["Expensive hardware
Complex deployment
Requires infrastructure"]
end
end
subgraph "Recommended Stack"
R1["Quick field check:
BLEShark Nano"]
R2["Detailed investigation:
Wireshark + PCAP"]
R3["Ongoing protection:
WIDS + PMF/WPA3"]
end
BS_PRO --> R1
WS_PRO --> R2
WI_PRO --> R3
Three tiers of deauth detection - from portable BLEShark field checks to Wireshark forensics to enterprise WIDS infrastructure, each serving different operational needs.
A WIDS can detect deauth floods, rogue APs, probe floods, unauthorized clients, and MAC spoofing. The controller correlates data across all sensors simultaneously, so attacks that would be missed by a single-channel sensor get caught by the distributed coverage.
For small businesses, home labs, or temporary deployments that lack a full managed AP infrastructure, the BLEShark Nano fills a practical gap. It's not a full WIDS - it's a handheld passive sensor - but for the use cases it serves (verifying your network is protected, checking a hotel or conference network, documenting an incident), it provides the detection capability that matters.
False Positives: When Deauth Is Legitimate
Not every deauth frame is an attack. Understanding false positives prevents unnecessary alarm:
Client roaming: When a device moves from one AP to another on the same network (enterprise multi-AP deployments), the original AP sends a deauth frame to the device to indicate it should associate with the new AP. This produces a single deauth frame followed by a reassociation.
AP reboot or reset: A router restart causes a deauth flood - the AP sends deauth to all connected clients to cleanly terminate connections. This is a burst followed by the AP going offline, distinguishable from an attack by the AP subsequently disappearing from scans.
Client disconnecting: Some devices send deauth frames to the AP when they intentionally disconnect (e.g., when the device turns off WiFi). These come from the client, not the AP, and are easily identified by source MAC.
Network management tools: Some network management software sends deauth frames to force client re-authentication or network refresh. This should only appear in managed network environments.
The BLEShark Deauth Checker applies a threshold and time-window filter to reduce false positives from these legitimate events. A single deauth frame or a brief burst during a router restart doesn't trigger an alert. Sustained high-rate deauth traffic does.
What to Do When You Detect Deauth
If the Deauth Checker fires an alert:
First, don't panic. Confirm this isn't a false positive - check if your router recently rebooted, if there's a network management tool running, or if a device is doing aggressive roaming.
Check the source MAC. In the event log, look at the source MAC address of the deauth frames. If it matches your AP's BSSID, the frames are spoofed to look like your AP (common attack). If it's an unfamiliar MAC, it's a rogue device on the network sending targeted disconnections.
Check whether PMF is enabled on your AP. 802.11w Protected Management Frames makes deauth attacks significantly harder by cryptographically authenticating management frames. If your AP supports WPA3 or PMF (most 2020+ routers do), enabling it is the most effective mitigation. Check your router's security settings.
Identify the attacker's location. RSSI from the deauth frames gives a rough signal strength estimate. Strong signal means the attacker is nearby. Weak signal means they're at distance or through walls. If you're on a Shiver mesh with multiple nodes, RSSI triangulation across nodes can narrow down the physical location.
Document and report. Download the PCAP from the BLEShark's file portal and note timestamps. If this is happening on a network you manage, this documentation is the starting point for an incident response. If it's on a network you don't manage (hotel, conference), notify the network operator.
Prevention: PMF and WPA3
Detection is the reactive measure. Prevention is the proactive one.
802.11w Protected Management Frames (PMF) cryptographically authenticates deauth and disassociation frames between a client and its AP. An attacker who doesn't have the session keys can't forge a valid PMF-protected deauth frame. When the client receives a deauth frame that fails the MIC (Message Integrity Check), it discards it rather than disconnecting. The attack fails.
WPA3 mandates PMF. On WPA3 networks, deauth attacks are significantly less effective. On WPA2 networks, PMF is optional but widely supported - look for "Management Frame Protection" in your router's settings and enable it if available.
Even with PMF, some deauth attacks still work. Deauth during the initial connection (before PMF negotiation completes) can still disrupt the handshake. And not all clients support PMF, meaning mixed-client networks may still have vulnerable devices. But PMF raises the bar substantially, and WPA3 raises it further.
The BLEShark Deauth Checker is a practical tool to verify your PMF configuration is actually working. Enable PMF on your AP, then use the BLEShark to attempt a deauth test against your own network (on a network you own or have authorization to test). If your devices stay connected, PMF is doing its job.