Wireless IDS - Detect network threats

What Is a Wireless Intrusion Detection System (WIDS)?

A Wireless Intrusion Detection System - WIDS - is a monitoring infrastructure that continuously watches 802.11 radio traffic for attack patterns, policy violations, and anomalous behavior. It's the wireless equivalent of a network IDS: always on, passively observing, alerting when something looks wrong.

Enterprise WIDS platforms cost thousands of dollars and require managed AP infrastructure. But the underlying detection concepts are simple, and a device like the BLEShark Nano implements a meaningful subset of them in a pocket-sized package. This article explains how WIDS works at both the enterprise and individual level.

Table of Contents

What WIDS Detects

A WIDS watches for a range of threat categories, each with specific detection signatures:

Deauth and disassociation floods: Burst of management frames attempting to disconnect clients. Detectable by counting deauth/disassoc frames per unit time from a source address.

Rogue access points: APs broadcasting SSIDs that aren't in the approved network list, or APs with MAC addresses not registered in the organization's inventory. A common attack vector for evil portal and rogue AP attacks.

Client probe floods: Devices broadcasting rapid probe requests for specific SSIDs (active scanning at high rate). Can indicate a reconnection attack or client-side scanning tool.

Evil twin / honeypot APs: An AP broadcasting the same SSID as a legitimate network but with a different BSSID. Classic attack for intercepting clients that auto-connect to known SSIDs.

PMKID harvesting: Unusual patterns of association requests that could indicate an automated PMKID collection tool running against the network.

Beacon flooding: AP Spam - a flood of beacons with fake SSIDs, which can cause client devices to display hundreds of networks or create confusion about which network to connect to.

WPS attacks: Repeated WPS PIN attempts, or the specific Pixie Dust attack pattern (repeated offline-cracking-optimized requests).

MAC spoofing: A device using a MAC address that's been registered to a different device, or a MAC that changes repeatedly (indicating MAC randomization in an unusual pattern).

How Enterprise WIDS Works

Enterprise WIDS is built on the same access point infrastructure already deployed for normal WiFi service. Managed AP platforms from vendors like Cisco (CleanAir), Aruba (RFProtect), and Ubiquiti (UniFi Threat Management) enable a subset of APs to operate in "monitoring mode" or "air monitor" mode - they stop serving clients and instead focus entirely on listening to the spectrum.

graph TD
    subgraph "WIDS Architecture"
        SENSORS["Distributed
Wireless Sensors"] --> COLLECTOR["Data Collector
/ Aggregator"]
        SENSOR2["Sensor Node 2"] --> COLLECTOR
        SENSOR3["Sensor Node 3"] --> COLLECTOR
        COLLECTOR --> ENGINE["Analysis Engine"]

        subgraph "Detection Methods"
            SIG["Signature-Based
Known attack patterns"]
            ANOM["Anomaly-Based
Behavioral baseline"]
            POLICY["Policy-Based
Rule violations"]
        end

        ENGINE --> SIG
        ENGINE --> ANOM
        ENGINE --> POLICY

        SIG --> ALERT["Alert System"]
        ANOM --> ALERT
        POLICY --> ALERT
        ALERT --> ADMIN["Admin Dashboard"]
        ALERT --> SIEM["SIEM Integration"]
        ALERT --> AUTO["Auto-Response
(containment)"]
    end

Typical WIDS architecture - distributed sensors feed a central analysis engine using signature, anomaly, and policy-based detection

The monitoring APs forward raw frame data or pre-processed event data to a central wireless controller or cloud management platform. The controller aggregates data across all sensors simultaneously, applying detection algorithms that would be impossible on a single-AP basis.

For example, detecting an evil twin requires knowing the MAC addresses of all legitimate APs on the network. A single monitoring AP can see a rogue AP broadcasting the same SSID, but only the controller - which has the full AP inventory - can definitively classify it as rogue versus a neighboring organization's AP with the same SSID.

Alert thresholds are configurable. Most organizations set deauth detection at something like "more than 20 deauth frames per 30 seconds from a single source." This avoids false positives from normal management traffic while catching active attacks.

Detection Methods

WIDS detection methods fall into a few categories:

Signature-based detection: Pattern matching against known attack frame sequences. A deauth flood has a recognizable signature: high-rate type-0-subtype-12 frames from a single source. Beacon flood: high-rate type-0-subtype-8 frames from a single source MAC cycling through multiple SSIDs. These signatures are reliable but only catch known attacks.

Anomaly-based detection: Baseline normal behavior and alert on deviations. If your office normally has 3 APs and 25 clients connected, a sudden appearance of 15 new APs is anomalous. If client X always connects from the same MAC but today is connecting from a different MAC claiming the same device name, that's anomalous. Anomaly detection catches novel attacks but generates more false positives.

Protocol analysis: Check whether frames are internally consistent. A deauth frame claiming to come from an AP but broadcast on a channel the AP doesn't use is suspicious. A device claiming to support a capability in its probe requests but behaving inconsistently with that capability during association is flagged for review.

RF fingerprinting: Advanced WIDS can fingerprint devices by their specific radio characteristics - modulation quality, clock drift, antenna patterns. These physical-layer signatures are harder to spoof than MAC addresses and can identify a device even when it's changing its MAC.

stateDiagram-v2
    [*] --> Monitoring: Sensors active

    Monitoring --> FrameCapture: 802.11 frame received
    FrameCapture --> Classification: Parse frame type

    Classification --> ManagementFrame: Beacon/Probe/Auth/Deauth
    Classification --> DataFrame: Data/QoS
    Classification --> ControlFrame: ACK/RTS/CTS

    ManagementFrame --> SignatureCheck: Compare known attacks
    ManagementFrame --> AnomalyCheck: Check baseline

    SignatureCheck --> DeauthFlood: Deauth flood?
    SignatureCheck --> RogueAP: Unknown BSSID?
    SignatureCheck --> EvilTwin: SSID spoofing?
    SignatureCheck --> Normal: No match

    AnomalyCheck --> RateAnomaly: Unusual rate?
    AnomalyCheck --> Normal: Within baseline

    DeauthFlood --> ThreatAlert: Generate alert
    RogueAP --> ThreatAlert
    EvilTwin --> ThreatAlert
    RateAnomaly --> ThreatAlert

    ThreatAlert --> Containment: Auto-response
    ThreatAlert --> Monitoring: Log and continue
    Containment --> Monitoring: Mitigated
    Normal --> Monitoring: Continue

WIDS detection state machine - from frame capture through classification, signature and anomaly analysis, to threat alerting and containment

Rogue AP Detection

Rogue AP detection is one of the most valuable WIDS capabilities. A rogue AP is any wireless access point that's connected to your wired network without authorization, or broadcasting your SSID without being part of your infrastructure.

Detection relies on correlating over-the-air observations with the wired network inventory. If a monitoring AP hears an 802.11 beacon from a device with a MAC address that doesn't appear in the managed AP inventory, and if that device appears to be reachable on the wired LAN (detected via ARP or DHCP logs), it's likely a rogue AP that someone plugged into a network jack.

A second category of rogue AP - the "neighbor AP" - broadcasts on the same channel as your APs and can cause interference. WIDS detects these but doesn't classify them as security threats unless they're broadcasting your SSID.

The BLEShark Nano's Deauth Checker, while not a full rogue AP detection system, can identify unexpected APs broadcasting on monitored channels. Reviewing the BLE scanner logs and WiFi scan results can reveal devices broadcasting unusual SSIDs or BSSIDs not in your expected inventory.

Deauth and Disassociation Flood Detection

Deauth detection is where even simple monitoring tools provide real value. The attack produces distinctive frame patterns:

In a broadcast deauth flood, the source MAC is spoofed to match the target AP's BSSID, and the destination MAC is either ff:ff:ff:ff:ff:ff (disconnects all clients) or a specific client MAC. The frames arrive at rates of 100-1000 per second during an active attack.

Detection algorithm:

  1. Count deauth frames per source MAC per rolling 10-second window
  2. If count exceeds threshold (typically 20-100 depending on sensitivity setting), flag as potential attack
  3. Cross-reference source MAC with known AP inventory - if it matches a known AP MAC, it may be legitimate management traffic (router restart, roaming event)
  4. If source MAC is unknown or count is extremely high, classify as attack and alert

The BLEShark Deauth Checker implements a version of this logic directly on-device. The specific threshold is configurable, and the on-device alert fires within seconds of a threshold being crossed.

Probe Flood and Reconnaissance Detection

Active WiFi scanning tools send probe request frames to every channel, asking for any APs within range to identify themselves. At normal scan rates, this is unremarkable - every phone and laptop does it. At tool-level scan rates (hundreds of probes per second from a single MAC), it looks like reconnaissance.

WIDS detects probe floods by counting probe requests per source MAC per time window. A device sending 200 probe requests in 10 seconds is either a scanning tool or a device with a driver bug. Either way, it's worth logging.

Probe request monitoring also reveals the historical SSIDs that devices have connected to - devices include their "preferred network list" (ESSID list) in active probe requests. This is a privacy concern for individuals and a network intelligence concern for security teams. A device probing for "Corporate_HQ_WiFi" on your guest network reveals that its owner has been connected to a corporate network, which may be useful context for an attacker or a BYOD security policy conversation.

WIDS Limitations

WIDS is a passive, detection-focused tool. It has meaningful limitations:

Detection lag: WIDS detects attacks that are already in progress. A brief deauth burst to capture a WPA2 handshake (a few seconds of deauth, then stop) may not trigger alert thresholds before the attack achieves its goal.

Channel coverage: A single monitoring AP can only listen on one channel at a time. With 13 2.4GHz channels and 25+ 5GHz channels, a small WIDS deployment has coverage gaps. Enterprise deployments address this with dedicated monitoring APs on every channel.

5GHz blind spots: The BLEShark Nano (ESP32-C3) operates on 2.4GHz only. Attacks on 5GHz networks are outside its monitoring capability. This is a hardware constraint - the ESP32-C3 has no 5GHz radio.

Encrypted management frames: With 802.11w (PMF) and WPA3, management frames are cryptographically protected. A WIDS sensor can still see that deauth frames are being sent but may not be able to determine whether they're legitimate management traffic or spoofed attacks without access to the session keys.

No response capability: WIDS detects and alerts. It cannot block attacks in progress. Active countermeasures (sending deauth frames to disconnect the attacker) require a Wireless Intrusion Prevention System (WIPS), which has its own legal and operational considerations.

The BLEShark as a Pocket WIDS

The BLEShark Nano's Deauth Checker is a practical pocket-sized implementation of WIDS concepts. It's not a full enterprise platform - no centralized management, no multi-channel simultaneous coverage from a single unit, no RF fingerprinting, no rogue AP correlation with wired network inventory. But it provides:

  • Passive deauth/disassociation frame monitoring on any 2.4GHz channel
  • Configurable alert thresholds
  • On-device alerts without requiring a connected phone or laptop
  • PCAP capture for post-event analysis in Wireshark
  • Event logging with timestamps

For a security professional checking whether a venue's WiFi is under attack, a network admin who wants to verify that PMF is deflecting deauth attempts on their network, or a student learning WIDS concepts in a lab environment, these capabilities are genuinely useful.

With the Shiver mesh (3-16 node deployments via Shiver packs, ESP-NOW at 250kbps Long Range mode, 20-50m per-hop range), each node acts as an independent sensor. The master node aggregates deauth alerts from all nodes in real time. This multi-node architecture covers all 13 2.4GHz channels simultaneously through coordinated channel partitioning - the same distributed sensing model that enterprise WIDS uses, at a fraction of the cost.

Practical Use Case: SMBs and Home Labs

Small and medium businesses that can't afford enterprise WiFi platforms get most of the WIDS value they need from a few practical measures:

Enable PMF on all APs. This doesn't stop detection but makes deauth attacks ineffective against protected clients. Periodically scan with the BLEShark Deauth Checker to confirm deauth attempts are failing. Check for unexpected APs broadcasting your SSID - a 5-minute WiFi scan reveals any evil twins within range.

For a home lab or classroom, the BLEShark gives you a hands-on understanding of what WIDS detects. Run a deauth test against your own test network (authorized access only), observe the Deauth Checker fire, download the PCAP, and analyze it in Wireshark. This workflow teaches the same detection concepts that enterprise WIDS platforms implement, using a $36.99 device.

Get BLEShark Nano

Back to blog

Leave a comment