---
name: harden-wps
description: "Disable Wi-Fi Protected Setup (WPS) and verify access points are not exposed to online WPS PIN brute force or the offline Pixie-Dust attack, which recover the WPA/WPA2 pre-shared key and give an attacker in radio range full network access (MITRE ATT&CK T1110, T1110.001, T1110.002; CERT/CC VU#723755). Signal lives at the wireless edge: hostapd/OpenWrt WPS control-interface events (WPS-FAIL, WPS-AP-SETUP-LOCKED), router and WLAN-controller syslog, 802.11 captures of the EAP-WSC exchange, and WIPS alerts such as Kismet WPSBRUTE. Gives an on-air exposure check that reads the WPS information element from your own beacons, the disable-and-verify procedure, defender-view signals, a hunt, and framework-mapped hardening. Use when disabling WPS on an AP or fleet, checking whether WPS is still advertised, assessing Pixie-Dust or PIN brute-force exposure, triaging WPS lockout or repeated WPS-FAIL events, or hardening SOHO and branch Wi-Fi."
---

# Wi-Fi Protected Setup (WPS) Exposure - Defensive Methodology

> **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, the hunt, and the hardening, and it points to public rule and standards 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

WPS was meant to make joining Wi-Fi easy and in doing so added a second credential path next to the WPA/WPA2 passphrase: an eight-digit registrar PIN. The PIN is validated in two independent halves and the last digit is only a checksum, so the real keyspace is about 11000 values, brute-forceable in hours (CERT/CC VU#723755). Worse, the offline **Pixie-Dust** attack recovers the PIN in seconds against access points whose WPS implementation generated the registration nonces (E-S1, E-S2) with little or no entropy, needing only a single captured M1 to M3 exchange. Both paths end the same way: the attacker derives your WPA pre-shared key and is on the network, having never guessed the passphrase. The only complete fix is to **turn WPS off and prove it is off on the air**, because many consumer and SOHO firmwares keep advertising the WPS information element, or keep the PIN method active, after the UI says WPS is disabled. This skill is defensive and ships no PIN brute-force, Pixie-Dust, or handshake-capture tooling.

## What it looks like, defender view

An online PIN brute force (the Reaver pattern) presents as a client that associates and then runs the WPS registration protocol over and over: a long run of **EAP-WSC** exchanges that reach the M4 or M6 message and then fail, each one a WSC_NACK, all from one station MAC against one BSSID, far faster and more repetitive than any human pressing a button. A well-behaved access point reacts by entering **AP setup lock** after a handful of failures, which on hostapd surfaces as the `WPS-AP-SETUP-LOCKED` event; a vulnerable firmware either never locks or has a lockout that resets too quickly, so the run simply continues.

Pixie-Dust is the quieter and more dangerous case. The attacker needs only one WPS exchange that reaches M3, from which they capture PKE, PKR, E-Hash1, E-Hash2 and the enrollee nonce, then computes the PIN offline. On the air that is a single short EAP-WSC conversation that stops abruptly after M3 with no M4 follow-up and no repetition. There is almost no volume signal, which is exactly why the defensive answer is to remove WPS rather than to try to catch the capture.

The on-air giveaway for both is that your beacons and probe responses carry a WPS information element at all, often with `Wi-Fi Protected Setup State = Configured`, `AP Setup Locked = False`, and a `Device Password ID` and `Config Methods` list that still include the PIN method. A client presenting itself as an external registrar with the EAP-Response/Identity string `WFA-SimpleConfig-Registrar-1-0` is taking the posture a PIN attack uses.

## Log sources and signals

The evidence is at the wireless edge. What you have depends on whether the access point is managed and whether it ships logs anywhere.

- **hostapd / OpenWrt access points.** The richest source. The hostapd control interface emits named WPS events you can log from `hostapd_cli` or syslog: `WPS-PIN-NEEDED`, `WPS-ENROLLEE-SEEN`, `WPS-REG-SUCCESS`, `WPS-FAIL` (carries a config-error and error-indication), `WPS-AP-SETUP-LOCKED` and `WPS-AP-SETUP-UNLOCKED`, `WPS-TIMEOUT`, `WPS-OVERLAP-DETECTED`, `WPS-PBC-ACTIVE`. A burst of `WPS-FAIL` followed by `WPS-AP-SETUP-LOCKED` from one peer is the online brute-force signal; a lone `WPS-ENROLLEE-SEEN` or single exchange is the Pixie-Dust posture. The configuration state itself (`wps_state`, `ap_setup_locked`, `config_methods`) is the exposure signal.
- **Consumer and SOHO routers.** System logs and the admin UI event log, where present, record WPS button presses, PIN attempts, and registration success. Many of these devices do not export logs at all, which is why the audit (below) matters more than monitoring on this class of hardware.
- **Enterprise WLAN controllers.** Cisco Catalyst 9800 / AireOS, Aruba (HPE) controllers and Instant APs, Juniper Mist, Ubiquiti UniFi, and MikroTik: AP event and association syslog. Note the Cisco naming collision - in Cisco WLC terminology "WPS" means **Wireless Protection System** (rogue and IDS signatures), which is a different thing from Wi-Fi Protected Setup; filter accordingly so a log search does not mislead you. Most enterprise APs do not expose a WPS registrar PIN at all, so the exposure here is usually on unmanaged SOHO or branch gear rather than the controller fleet.
- **802.11 monitor-mode captures.** A monitor-mode capture opened in Wireshark shows the WPS information element in beacons and probe responses, and the full **EAP-WSC** registration (expanded EAP type 254, WFA vendor) when a PIN attempt runs. Useful fields: `wps.wifi_protected_setup_state`, `wps.ap_setup_locked`, `wps.device_password_id`, `wps.config_methods`, and `wps.configuration_error` on the NACK (the error is named, for example Device Password Authentication Failure or a setup-locked condition, rather than reliably numbered across dissector versions). Repeated NACKs from one STA is brute force; one exchange ending at M3 is Pixie-Dust capture.
- **Wireless IDS/IPS (WIPS).** Kismet raises `WPSBRUTE` for excessive WPS negotiation attempts (a stateful/trend alert) and carries WPS-aware alerts such as `BCMWPSMONITOR`, `WPSFRAGLEN`, and `WPSFRAGPROBE`. Commercial WIPS (Cisco Adaptive WIPS, Aruba WIP) carry equivalent WPS brute-force signatures; use the exact signature name from your product rather than assuming one.

**Baseline.** In a hardened estate WPS is off, so the steady state is no WPS information element in any of your beacons and zero WPS events in any log. If WPS is intentionally left on for a specific device, legitimate use is a rare, human-paced, button-initiated PBC registration, not a sustained run of PIN exchanges.

## Detection approach

Prefer the configuration and exposure check over live detection, because the most dangerous variant (Pixie-Dust) is nearly silent and because the fix removes the attack rather than merely alarming on it. The high-signal conditions, where you can observe them, are: (1) any WPS information element advertised by an access point that policy says has WPS disabled, which is a misconfiguration finding regardless of whether an attack has happened; (2) a run of `WPS-FAIL` / WSC_NACK events from one station MAC against one BSSID in a short window, the online PIN brute force; (3) the access point entering AP setup lock (`WPS-AP-SETUP-LOCKED`), which is a strong signal that a brute force was attempted; and (4) a station presenting as an external registrar (`WFA-SimpleConfig-Registrar-1-0`) or a single EAP-WSC exchange that stops after M3, the Pixie-Dust capture posture.

There is no widely maintained public Sigma ruleset dedicated to WPS access-point or hostapd events today, so this skill does not point you at one that does not exist. The practical path is to normalize the hostapd control-interface events or controller syslog into your SIEM and author correlations (2) and (3) against those event strings, and to run the exposure check (1) as a recurring audit. Use the public [SigmaHQ repository](https://github.com/SigmaHQ/sigma) as the rule format and category reference, the [Wireshark WPS/EAP-WSC dissector reference](https://www.wireshark.org/docs/dfref/w/wps.html) for the exact field names your captures carry, the [hostapd / wpa_supplicant WPS documentation](https://w1.fi/cgit/hostap/tree/wpa_supplicant/README-WPS) for the control-interface event strings, and [MITRE D3FEND](https://d3fend.mitre.org/) for the countermeasure framing. A tuned UMBRASEC rule for this threat is not yet shipped; see the Tier 2 banner above.

## Threat hunt

Hypothesis: an access point still exposes WPS, or a WPS PIN brute force is being attempted against one.

1. **Read the air, not the UI (the Pixie-Dust exposure check done defensively).** Passively scan your own SSIDs and inspect the WPS information element rather than trusting the admin page. On a Linux client with the Wi-Fi interface up, `iw dev <iface> scan` prints a `WPS:` block per BSS showing `Wi-Fi Protected Setup State`, `AP setup locked`, `Selected Registrar`, `Device Password ID`, and `Config methods`; Wireshark's `wps` display filter on a monitor capture shows the same. The goal state is **no WPS information element at all**. An element that is present, with the PIN config method listed and AP setup locked false, is an exposed access point even if its web UI shows WPS as off.
2. **Inventory and reconcile.** List every access point (managed and unmanaged, including anything staff plugged in) and record its WPS state from step 1. Any device advertising WPS that is not on an explicit, justified exception list is a finding.
3. **Check firmware against vendor advisories.** For each exposed device, record chipset and firmware version and compare against the vendor's security advisories. Pixie-Dust affected implementations that generated the E-S1/E-S2 registration nonces with constant or predictable values, documented in public research in 2014; a weak WPS lockout that an attacker can reset is a separate firmware defect. Patch or replace, do not just toggle.
4. **Hunt the logs where you have them.** On hostapd/OpenWrt APs and controllers, pull WPS events over a long window, group by station MAC and BSSID, and flag any peer with repeated `WPS-FAIL` / WSC_NACK, any `WPS-AP-SETUP-LOCKED`, or an unexpected `WPS-REG-SUCCESS`. Correlate with WIPS `WPSBRUTE` alerts if you run one.
5. **Rank by blast radius.** An exposed access point on a flat network that reaches sensitive systems outranks one on an isolated guest VLAN, because a recovered PSK there yields more. Fix the high-blast-radius devices first.

## Hardening

Shrink the surface by removing WPS and proving it is gone, then detection is a backstop rather than the primary control. The mappings below use control codes grounded in the UMBRASEC [foundation guide](https://umbrasec.dev/guide/foundation.html), [identity and access guide](https://umbrasec.dev/guide/identity-and-access.html), and [detection and response guide](https://umbrasec.dev/guide/detection-and-response.html); a cell is left blank where no single control maps cleanly. The ASD Essential Eight is a Windows-estate model and most of its mitigations do not address Wi-Fi radio configuration, so much of its column is blank by design, which is honest rather than a gap.

| Control | What it does | Essential Eight | ISO 27001:2022 | NIST CSF 2.0 |
|---|---|---|---|---|
| Disable WPS and verify no WPS IE on the air | Removes the PIN and Pixie-Dust credential path entirely; `wps_state=0` on hostapd, off in vendor UI, then confirmed by passive scan | - | A.8.5 Secure authentication | PR.PS |
| Strong WPA2/WPA3 passphrase; prefer WPA3-SAE or 802.1X | Ensures the PSK is not independently cheap to recover, and WPA3-SAE removes the offline-capture path WPS targets | - | A.8.5 Secure authentication; A.5.17 Authentication information | PR.AA |
| Patch or replace AP/router firmware | Fixes predictable-nonce (Pixie-Dust) implementations and weak WPS lockout, which a toggle alone does not | Patch operating systems (firmware) | A.8.8 Technical vulnerabilities | PR.PS |
| Harden and restrict the AP admin interface | Prevents WPS being silently re-enabled by an attacker or a careless reset; least privilege and strong admin credentials | Restrict administrative privileges | A.8.2 Privileged access rights; A.5.15 Access control | PR.AA |
| Inventory access points and their WPS state | Makes every radio and its WPS exposure visible, including shadow SOHO gear | - | A.5.9 Inventory of assets | ID.AM |
| Ship AP/controller logs and alert on WPS events | Turns `WPS-FAIL` and `WPS-AP-SETUP-LOCKED` into alerts rather than silent events | - | A.8.15 Logging; A.8.16 Monitoring | DE.CM; DE.AE |

## Honest limitations

Most WPS exposure is on consumer and SOHO access points that do not ship logs to a SIEM, so for the majority of estates this is an **audit-and-disable** control, not a monitored one: the exposure check in the hunt is the real work, and live detection is a bonus only where you have hostapd or a controller feeding events. Client MAC randomization weakens any per-station brute-force threshold, since an attacker rotating MACs spreads the failures. The Pixie-Dust variant is nearly silent on the air (one short exchange), so a volume-based alert will not catch it, which is the whole reason the fix is removal rather than detection. Disabling WPS also removes the detection surface entirely - once there is no WPS information element, there are no WPS events to watch, and that is the point, not a gap. Finally, a firmware whose UI reports WPS off while it still advertises the information element will fool a configuration audit that trusts the UI; only the on-air check in hunt step 1 is authoritative. Baseline your own estate, verify on the air, and leave the final call to the defender.

## ATT&CK and D3FEND

- MITRE ATT&CK: [T1110 Brute Force](https://attack.mitre.org/techniques/T1110/) (Credential Access), with [T1110.001 Password Guessing](https://attack.mitre.org/techniques/T1110/001/) for the online WPS PIN brute force and [T1110.002 Password Cracking](https://attack.mitre.org/techniques/T1110/002/) for the offline Pixie-Dust recovery of the PIN and PSK.
- MITRE D3FEND: [D3-ACH Application Configuration Hardening](https://d3fend.mitre.org/technique/d3f:ApplicationConfigurationHardening/) for disabling WPS and removing the WPS information element; [D3-SU Software Update](https://d3fend.mitre.org/technique/d3f:SoftwareUpdate/) for patching predictable-nonce and weak-lockout firmware; [D3-AL Account Locking](https://d3fend.mitre.org/technique/d3f:AccountLocking/) for a correct WPS AP setup lock after failed PIN attempts; [D3-SPP Strong Password Policy](https://d3fend.mitre.org/technique/d3f:StrongPasswordPolicy/) for the WPA passphrase; [D3-NTA Network Traffic Analysis](https://d3fend.mitre.org/technique/d3f:NetworkTrafficAnalysis/) for the capture-side detection.
- Standards and vendor sources: [CERT/CC Vulnerability Note VU#723755](https://www.kb.cert.org/vuls/id/723755) (Wi-Fi Protected Setup PIN brute force, Dec 2011); [Wi-Fi Alliance Wi-Fi Protected Setup](https://www.wi-fi.org/); [hostapd / wpa_supplicant WPS documentation](https://w1.fi/cgit/hostap/tree/wpa_supplicant/README-WPS); [Wireshark WPS dissector reference](https://www.wireshark.org/docs/dfref/w/wps.html); [Kismet alerts documentation](https://www.kismetwireless.net/docs/readme/alerts/) (`WPSBRUTE`); public rule format reference at [github.com/SigmaHQ/sigma](https://github.com/SigmaHQ/sigma).

**Scope note.** This is a defensive skill. It explains WPS only to the depth needed to find, disable, and detect abuse of it, ships no PIN brute-force, Pixie-Dust, or handshake-capture tooling, and leaves the verdict to the defender.