---
name: detect-wifi-attacks
description: "Overview detection methodology for the 802.11 attack family: evil-twin and rogue APs, deauth floods, handshake and PMKID capture for offline PSK cracking, rogue-RADIUS against WPA-Enterprise, WPS PIN brute force, and KRACK/FragAttacks (MITRE ATT&CK T1557, T1557.004, T1498.001, T1040, T1110.002, T1200). The signal lives in the radio layer and on controllers: wireless IDS/IPS (Kismet alerts), Cisco aWIPS, Aruba WIP, Meraki Air Marshal, the Windows WLAN-AutoConfig Operational channel, NPS RADIUS events, and raw 802.11 captures. This hub skill maps each attack class to its defender-side signal, a hunt, and the hardening that closes it, and points to public rule sources. Use when triaging a wireless IDS or controller alert, investigating a spoofed SSID/BSSID, hunting for an evil twin or rogue AP, deciding what Wi-Fi telemetry to collect, scoping 802.11 detection coverage, or hardening WLANs against the attack family."
---

# 802.11 Attack Family - Defensive Overview

> **Tier 2 - methodology skill.** No bespoke UMBRASEC detection rule ships with this skill yet. It gives the defender's method, the log sources and signals, and the hardening, and points to public rule and sensor sources. Promotion to Tier 1 (a sourced, tuned UMBRASEC rule) is tracked in [COVERAGE.md](https://github.com/umbrasec-labs/umbra-blue/blob/main/COVERAGE.md). Do not treat the content below as citing a UMBRASEC rule; there is none for this threat yet.

## TL;DR

Wi-Fi attacks almost never show up in the logs a SIEM usually ingests, because 802.11 management frames and the RF layer are not events your endpoints record. You see them in three places: a wireless IDS/IPS, the WLAN controller or cloud dashboard, and the client's own WLAN subsystem. This hub covers the attack family at overview depth and routes the one class with a dedicated sibling skill to it. The recurring signal is an SSID you trust appearing from a BSSID, channel, or security suite you do not, plus client disconnect/reconnect churn around it. Run an always-on wireless IDS/IPS, forward controller rogue-AP and WIPS events to the SIEM, collect `Microsoft-Windows-WLAN-AutoConfig/Operational` from clients, and move SSIDs to WPA3 with Protected Management Frames so the cheapest spoofing attacks simply fail. This skill is defensive and ships no frame-injection, cracking, evil-twin, or RF tooling.

## What it looks like, defender view

The attack family breaks into a handful of classes, each with a distinct defender-side tell:

- **Evil twin / rogue AP.** A second AP beacons an SSID you already run, from a different BSSID, on a different channel, often with weaker or open security than the real one, and frequently with a stronger signal to win clients. Clients connect to the wrong BSSID; captive-portal or credential prompts may follow. Covered at overview depth here; see the dedicated [detect-rogue-ap](../detect-rogue-ap/SKILL.md) skill for depth.
- **Deauth / disassociation flood.** A burst of spoofed deauthentication (subtype `0x0c`) or disassociation (subtype `0x0a`) frames knocks clients off, as a denial of service or to force a reconnect the attacker can capture. Covered in depth in [detect-deauth](../detect-deauth/SKILL.md); only summarized here.
- **Handshake / PMKID capture.** The attacker records the WPA 4-way handshake (or a single PMKID from the first message) and cracks the PSK offline. You cannot see the cracking. What you can see is the setup: a deauth burst immediately followed by reassociations, or an unknown station that associates and pulls EAPOL frames but never completes a session.
- **Rogue RADIUS against WPA-Enterprise.** A fake 802.1X authenticator with an untrusted or mismatched server certificate harvests credentials from clients that do not validate the server cert. The tell is a spike in authentication failures and certificate-validation errors.
- **WPS PIN brute force.** Repeated WPS registration attempts against an AP whose WPS is still enabled.
- **KRACK / FragAttacks.** Key-reinstallation (KRACK) attacks against unpatched stacks are visible as handshake nonce reuse; fragmentation/aggregation (FragAttacks) design and implementation flaws do not present as nonce reuse and are closed mainly by patching.

## Log sources and signals

The detection is radio-layer and controller-layer first, host-layer second.

- **Wireless IDS/IPS: Kismet.** [Kismet's WIDS alerts](https://kismetwireless.net/docs/readme/alerts/alerts/) name most classes directly. For evil-twin and rogue APs: `APSPOOF` (a configured SSID seen from a MAC not on its allowlist), `CRYPTODROP` (a known AP starts advertising a weaker security suite), `ADVCRYPTCHANGE` (advertised encryption changed), `BSSTIMESTAMP` (out-of-sequence BSS timestamps consistent with spoofing), `CHANCHANGE` and `PROBECHAN` (channel inconsistencies), and `KARMAOUI` (the predictable OUI used by some karma-style tools). For handshake-capture precursors: `DEAUTHFLOOD` and `BCASTDISCON`. For WPS: `WPSBRUTE`. For KRACK-style attacks: `NONCEREUSE` and `NONCEDEGRADE`. `NOCLIENTMFP` flags clients not advertising 802.11w, a coverage gap rather than an attack. Alert rate limits live in `kismet_alerts.conf`; Kismet also writes PCAP for confirmation in Wireshark.
- **Enterprise controllers and cloud WLAN.** Cisco Catalyst 9800 / WLC with Advanced Wireless IPS (aWIPS) and rogue-AP classification, Aruba/HPE Wireless Intrusion Protection (WIP), Cisco Meraki Air Marshal, and Ubiquiti UniFi all maintain rogue-AP and spoofed-SSID tables and raise containment events. Forward them to the SIEM as syslog and alert on the rogue/evil-twin classification together with the offending BSSID and channel.
- **Windows client side.** The `Microsoft-Windows-WLAN-AutoConfig/Operational` channel records what a client actually joined. Event ID `8001` on a successful connection carries the SSID, BSS type, authentication, and encryption/cipher (but not the AP MAC); `8002` on connection failure carries a failure reason; `8003` on disconnect carries a reason code. The peer AP MAC, the BSSID itself, is recorded in the wireless-security association events in the same channel: `11003` (wireless security started) and `11006` (wireless security failed) both carry a `Peer MAC Address` field alongside SSID, authentication, and encryption. A fleet of clients whose `8001` events show a known SSID joined at a weaker authentication type than policy (an Enterprise SSID appearing as Open or WPA2-Personal), or whose `11003` events bind a trusted SSID to a `Peer MAC Address` outside your AP inventory, is a strong evil-twin indicator you can see without a sensor.
- **Windows NPS / RADIUS (WPA-Enterprise).** The Security log carries `6272` (network policy granted access), `6273` (denied, with a Reason Code), and `6274` (discarded). A spike in `6273` tied to one AP or to many clients failing server-certificate validation at once is the rogue-RADIUS signal.
- **Linux AP/supplicant.** `hostapd` and `wpa_supplicant` log association, EAPOL, and PMF events to journald on APs and clients you control.
- **Raw 802.11 capture (confirmation).** With a monitor-mode interface, Wireshark/tshark display filters isolate frames for verification: `wlan.fc.type_subtype == 0x08` (beacon), `wlan.fc.type_subtype == 0x05` (probe response), `wlan.fc.type_subtype == 0x0c` (deauth), `eapol` for handshakes. Compare `wlan.bssid`, `wlan.ssid`, and `wlan.ds.current_channel` against your known-good inventory.

What normal looks like: APs roam, load-balance, and emit occasional management frames; clients legitimately see neighboring SSIDs. The anomaly is a trusted SSID bound to an untrusted BSSID/channel/cipher, a sustained frame storm, or a cluster of security-handshake failures, not the existence of wireless activity.

## Detection approach

Alert on identity and configuration mismatch, not on single frames. The high-signal conditions across the family are: (1) a known SSID advertised from a BSSID or channel outside your AP inventory, or with a weaker security suite than policy (`APSPOOF`, `CRYPTODROP`, controller rogue classification, a `WLAN-AutoConfig` `8001` with a weaker authentication type than policy, or an `11003` whose `Peer MAC Address` is outside your inventory); (2) deauth or disassoc volume above a learned per-AP baseline, especially broadcast-destination frames, which precedes handshake capture and is handled in [detect-deauth](../detect-deauth/SKILL.md); (3) handshake nonce reuse (`NONCEREUSE`); (4) a burst of WPS registration attempts (`WPSBRUTE`); and (5) a spike of NPS `6273` denials or client certificate-validation errors indicating a rogue RADIUS. Because 802.11 management frames are not log records, prefer the purpose-built wireless IDS/IPS and controller signatures above for the RF classes; log-oriented formats such as Sigma operate on the controller syslog and on the Windows `WLAN-AutoConfig` / NPS events, not on the frames themselves. A tuned UMBRASEC rule is not yet shipped for this family; for maintained public detections use the Kismet alert engine, the vendor aWIPS/WIP/Air Marshal signatures, and track controller-log and NPS/WLAN-AutoConfig SIEM rules in the general [SigmaHQ repository](https://github.com/SigmaHQ/sigma).

## Threat hunt

Hypothesis: an attacker is impersonating a corporate SSID or capturing material to crack the PSK.

1. Build a known-good AP inventory: every authorized SSID mapped to its set of BSSIDs, channels, and the security suite policy requires. This is the baseline everything else is measured against.
2. Pull wireless IDS/controller data and list every (SSID, BSSID, channel, cipher) tuple observed. Diff against the inventory. Any trusted SSID from an unknown BSSID, on an unexpected channel, or with a weaker cipher is a rogue/evil-twin candidate.
3. Pull `Microsoft-Windows-WLAN-AutoConfig/Operational` events fleet-wide. Group `11003` by SSID then `Peer MAC Address` to find clients that bound a trusted SSID to a BSSID outside your inventory, and group `8001` by SSID then authentication type to find clients that joined at a weaker security than policy. Both mean the client actually connected to the suspect AP. Correlate `8003` disconnect reasons and `8002` failures around the same window.
4. For handshake-capture hunting, look for the sequence deauth burst then reassociation then EAPOL from the same client set within seconds, and for stations that pull EAPOL but never establish a session.
5. For WPA-Enterprise, pull NPS `6273` and group by calling station / AP; a cluster of certificate-validation denials points at a rogue RADIUS or clients with validation disabled.
6. Confirm the top candidates in a Wireshark/Kismet PCAP, comparing `wlan.bssid` and advertised security against inventory, and check whether affected SSIDs have 802.11w enabled.

## Hardening

Shrink the surface the whole family depends on. Two controls ground cleanly to the UMBRASEC guides: logging and monitoring in the [detection and response guide](https://umbrasec.dev/guide/detection-and-response.html), and the Essential Eight patch strategies in the [foundation guide](https://umbrasec.dev/guide/foundation.html) with vulnerability management (A.8.8) in the [governance and maturity guide](https://umbrasec.dev/guide/governance-and-maturity.html). The Wi-Fi-specific cryptographic controls do not map onto a single framework code and are kept in prose below the table.

| Control | Essential Eight | ISO 27001:2022 | NIST CSF 2.0 |
|---|---|---|---|
| Always-on wireless IDS/IPS with controller rogue/evil-twin events forwarded to the SIEM | - | A.8.15 Logging; A.8.16 Monitoring activities | DE.CM; DE.AE |
| Patch AP, controller, and client Wi-Fi stacks for KRACK and FragAttacks | Patch operating systems; Patch applications | A.8.8 Management of technical vulnerabilities | - |

Beyond the table, the cryptographic and configuration controls that neutralize the cheap attacks are: enable **802.11w Protected Management Frames** (Required where clients allow, Capable as a transition) so spoofed deauth/disassoc are rejected and the handshake-capture precursor fails; **move SSIDs to WPA3**, which mandates PMF and SAE and removes the offline-dictionary path against the PSK; enforce a **long, random pre-shared key** on any PSK network that remains; for WPA-Enterprise, **require server-certificate validation on clients** and pin the trusted CA and RADIUS server name so a rogue RADIUS cannot harvest credentials; and **disable WPS** to remove the PIN brute-force surface entirely. None of these is a single named framework control, so they are deliberately not forced into the table rather than invented.

## Honest limitations

This is an overview, not six detections: each class has a dedicated sibling on the roadmap that will carry tuned rules and thresholds, and only [detect-deauth](../detect-deauth/SKILL.md) and [detect-rogue-ap](../detect-rogue-ap/SKILL.md) exist today. Everything here depends on radio-layer visibility; if you run no wireless IDS/IPS and your controller emits no WIPS signatures, the RF-level attacks are invisible to a conventional SIEM, and the Windows `WLAN-AutoConfig`/NPS signals only catch attacks that clients actually interact with. A transmitter address is spoofable, so it identifies the impersonated AP, not the attacker. PMF and WPA3 stop spoofed-frame and offline-cracking attacks but not RF jamming, association/authentication floods, or spoofed Channel Switch Announcements. Offline PSK cracking itself is never visible to the defender; only its setup is, which is why hardening the PSK and moving to SAE matter as much as any alert. Baselines are environment-specific; build and maintain the known-good AP inventory, and treat a trusted SSID from an untrusted BSSID as the near-binary high-confidence signal.

## ATT&CK and D3FEND

- MITRE ATT&CK: [T1557 Adversary-in-the-Middle](https://attack.mitre.org/techniques/T1557/) and [T1557.004 Evil Twin](https://attack.mitre.org/techniques/T1557/004/) (Credential Access, Collection); [T1498.001 Direct Network Flood](https://attack.mitre.org/techniques/T1498/001/) (Impact, the deauth/flood class); [T1040 Network Sniffing](https://attack.mitre.org/techniques/T1040/) and [T1110.002 Password Cracking](https://attack.mitre.org/techniques/T1110/002/) (Credential Access, the handshake-capture-then-crack path); [T1200 Hardware Additions](https://attack.mitre.org/techniques/T1200/) (Initial Access, a planted rogue AP).
- MITRE D3FEND: [D3-NTA Network Traffic Analysis](https://d3fend.mitre.org/technique/d3f:NetworkTrafficAnalysis/) for the detection side. The Wi-Fi hardening controls (PMF, WPA3/SAE, 802.1X server-cert validation, disabling WPS) are cryptographic and configuration measures that do not map onto a single named D3FEND technique, so none is asserted rather than forcing a poor fit.
- Public rule and sensor sources: [Kismet WIDS alerts](https://kismetwireless.net/docs/readme/alerts/alerts/); Cisco Catalyst 9800 / aWIPS, Aruba/HPE WIP, and Meraki Air Marshal documentation; [SigmaHQ repository](https://github.com/SigmaHQ/sigma) for controller-log, NPS, and WLAN-AutoConfig SIEM rules.

**Scope note.** This is a defensive skill. It explains the 802.11 attack family only to the depth needed to detect and mitigate it and deliberately provides no frame-injection, cracking, evil-twin, rogue-RADIUS, or RF tooling. UMBRASEC publishes defense, not offense.