---
name: harden-wpa-enterprise
description: "WPA2/WPA3-Enterprise (802.1X/EAP) credential-theft defense against evil-twin APs backed by a rogue RADIUS server, which harvest the inner identity and PEAP-MSCHAPv2 or EAP-TTLS challenge/response from supplicants that skip server-certificate validation and crack it offline into domain credentials (MITRE ATT&CK T1557.004, T1110.002, T1040). Signal lives at the RF layer and on the client: WLC/WIPS rogue-AP classification, Windows WLAN-AutoConfig and OneX 802.1X failure events, wpa_supplicant certificate errors, NPS/FreeRADIUS baselines, and AD logon anomalies. Gives the supplicant certificate-validation policy, an EAP-TLS migration path, defender-view signals, a hunt, and framework-mapped hardening. Use when reviewing an 802.1X/EAP wireless deployment, choosing PEAP-MSCHAPv2 vs EAP-TLS, auditing GPO/Intune/MDM Wi-Fi profiles, hunting evil-twin or rogue-RADIUS capture, or triaging WIPS rogue-AP alerts on a corporate SSID."
---

# WPA-Enterprise (802.1X/EAP) Rogue-RADIUS Credential Theft - 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, and the hardening, and points to public rule and reference 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

The whole attack turns on one client-side setting. A rogue RADIUS server behind an evil-twin AP can only harvest credentials from a supplicant that does not properly validate the authentication server's certificate. The fix is therefore prevention, not detection: on every managed supplicant, require server-certificate validation, pin trust to your internal RADIUS CA (not "any trusted root"), list the exact RADIUS server name(s) that must appear in the certificate, and remove the user's ability to click through an untrusted or unexpected server. Where you can bear the PKI cost, move from PEAP-MSCHAPv2 and EAP-TTLS to **EAP-TLS**, which authenticates both sides with certificates and leaves no password to crack. Detection is a backstop and lives in two places you do control: RF-side (WIPS rogue-AP classification of a second BSSID carrying your SSID) and downstream (reuse of harvested credentials). This skill is defensive and ships no evil-twin, rogue-RADIUS, or MSCHAPv2 cracking tooling.

## What it looks like, defender view

The rogue RADIUS is not on your network, so the most honest statement is that the authentication event itself generates **no record on your infrastructure**. A correctly configured supplicant that meets the rogue refuses the certificate and logs a validation failure; a misconfigured one completes the EAP tunnel against the attacker silently and you see nothing until the stolen credentials are used elsewhere.

What you can see: on the **RF side**, a BSSID that is not in your access-point inventory beaconing your corporate 802.1X SSID, often with strong signal from an unexpected location, which your controller or WIPS classifies as a rogue or interfering AP. On the **client side**, a fleet-wide spike of supplicant certificate-validation failures (clients that are configured correctly rejecting the wrong server), or, on misconfigured clients, prompts asking the user to trust a new or changed server certificate. **Downstream**, the tell of a successful harvest is credential reuse: a domain account authenticating from a new host, VPN, or geography shortly after, visible as anomalous 4624/4625 patterns rather than as any wireless event.

## Log sources and signals

Because the attacker's RADIUS writes nothing to you, lean on RF telemetry, supplicant logs, and your own RADIUS baseline:

- **Wireless LAN controller / WIPS/WIDS.** Cisco Catalyst/Meraki, Aruba/HPE (Central, AirWave RAPIDS), Juniper Mist, and Ruckus all classify rogue and evil-twin APs. The signal is a BSSID broadcasting a known corporate SSID that is not in the managed-AP list, a duplicate SSID on an unexpected channel, or a sudden new BSSID with corporate-matching beacon parameters. Export these as rogue-AP / rogue-classification events into the SIEM. This is the counterpart data to the `detect-rogue-ap` skill.
- **Windows supplicant.** The `Microsoft-Windows-WLAN-AutoConfig/Operational` channel records the connection outcome: **11006** (wireless security/802.1X failure, with a reason code), **12013** (802.1X wireless authentication failed, with a reason code), and **8002** (association failure). These carry a failure reason code, not the server certificate itself, so pair them with the EAP supplicant channel **`Microsoft-Windows-OneX/Operational`**, which records the 802.1X/EAP method detail including certificate rejection. A cluster of 11006/12013 with certificate-related reasons, or an EAP failure against an unexpected authentication server, is the anomaly.
- **wpa_supplicant (Linux/Android/embedded).** Control-interface events `CTRL-EVENT-EAP-TLS-CERT-ERROR`, `CTRL-EVENT-EAP-STATUS`, and the logged server certificate subject and `depth`. With `ca_cert` and `domain_suffix_match`/`subject_match` set, a mismatch is logged as a TLS certificate error rather than a completed handshake; absence of those settings is itself the finding.
- **RADIUS server (your legitimate one).** Microsoft **NPS**: the Security log Network Policy Server events **6272** (access granted), **6273** (access denied), **6274** (discarded), **6278** (full access granted), plus the IAS-format accounting log; **FreeRADIUS**: `radius.log` / `linelog` and the `Access-Accept`/`Access-Reject` stream with the `Called-Station-Id` (AP BSSID) and `NAS-IP-Address`. You baseline which NAS devices and users normally authenticate; a user who should be on Wi-Fi but is absent from NPS over a window may have been captured by the rogue.
- **Downstream identity logs.** AD domain controller **4624/4625** (logon success/failure), VPN and web-SSO logs, and impossible-travel / anomalous-sign-in analytics (for example Entra ID risky sign-ins). Correlate harvested-credential use here.

**Baseline.** Steady state: every corporate-SSID BSSID is a managed AP in inventory; supplicant certificate-validation failures are near zero; each wireless user appears in NPS/FreeRADIUS `Access-Accept` from an expected NAS; no user is prompted to trust a new server certificate because policy forbids the prompt.

## Detection approach

Alert on the three things you can observe, and accept that the rogue RADIUS itself is unobservable to you:

1. **RF-side rogue classification.** Alert when the controller/WIPS reports a BSSID advertising a corporate 802.1X SSID that is not in the managed-AP inventory, or a duplicate-SSID / evil-twin classification. This is the earliest signal and the only one that can fire before credentials are stolen.
2. **Client-side certificate-validation failures.** Alert on a rise in Windows WLAN-AutoConfig 11006/12013 802.1X failures (with the EAP certificate detail from the OneX/Operational channel), or in wpa_supplicant `CTRL-EVENT-EAP-TLS-CERT-ERROR`, across many devices in a short window. A correctly hardened fleet rejecting a rogue server produces exactly this burst; it means the attack is present and your supplicant config is working.
3. **Downstream harvested-credential use.** Alert on anomalous 4624/4625 and risky-sign-in patterns for accounts that are wireless users, as the delayed consequence of a successful PEAP/TTLS harvest.

A tuned UMBRASEC rule is not yet shipped for this threat. For the log-shaped sources, point at public, maintained rules: the [SigmaHQ repository](https://github.com/SigmaHQ/sigma) `rules/windows/` tree for NPS and Windows authentication (4624/4625/6273) analytics and for WLAN-AutoConfig where coverage exists, and your WIPS vendor's rogue-AP analytics (Cisco Catalyst 9800 rogue management, Aruba RAPIDS). For the protocol background use the EAP and EAP-TLS RFCs below. Do not expect a SIEM rule to catch the rogue RADIUS directly; it is off your wire by design.

## Threat hunt

Hypothesis: a managed device will complete 802.1X against a rogue RADIUS because its supplicant does not validate the server certificate. Hunt the configuration, not just the event stream.

1. **Audit supplicant profiles across the fleet.** In GPO wireless policy, Intune/MDM Wi-Fi profiles, and `wpa_supplicant.conf`, confirm for every corporate-SSID profile that: server-certificate validation is enabled; a specific **Trusted Root CA** (your internal RADIUS CA) is selected rather than "any" root; the expected **RADIUS server name(s)** are listed (matching the server certificate SubjectAltName/CN); and "Do not prompt the user to authorize new servers or trusted certification authorities" is set (Linux equivalent: `domain_suffix_match` / `subject_match` pinned). Any profile missing any of these is a finding regardless of whether an attack has occurred - it is the precondition the whole attack needs.
2. **Enumerate corporate-SSID BSSIDs.** From controller/WIPS data or an RF survey, list every BSSID beaconing each corporate 802.1X SSID. Any BSSID not in the managed-AP inventory is a rogue candidate; investigate location and signal.
3. **Pull supplicant certificate events.** Query WLAN-AutoConfig 11006/12013 and the OneX/Operational EAP channel on Windows, and wpa_supplicant TLS cert errors on Linux, over a long window. Clusters of validation failures, or events showing an unexpected authentication-server certificate, indicate a rogue was in range.
4. **Reconcile against RADIUS.** For wireless users active on the network, confirm matching `Access-Accept` in NPS/FreeRADIUS from an expected NAS. A user clearly on Wi-Fi but absent from your RADIUS over the window is a candidate for rogue capture; pivot to their downstream logons.

## Hardening

Shrink the surface by fixing the supplicant and the authentication method; detection is then a backstop rather than the primary control. The mappings below follow the control codes used in the UMBRASEC [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 maturity model and does not address wireless RADIUS design, so those cells are blank by nature.

| Control | What it does | Essential Eight | ISO 27001:2022 | NIST CSF 2.0 |
|---|---|---|---|---|
| Enforce server-certificate validation on every supplicant | The single control that defeats rogue RADIUS: the client cryptographically verifies the authentication server before sending any inner credential | - | A.8.5 Secure authentication | PR.AA-03 Users authenticated |
| Pin trust to the internal RADIUS CA and expected server name(s) | Trust only your issuing CA and the named RADIUS server(s), not "any trusted root", so a valid certificate from an unrelated CA is still rejected | - | A.8.5 Secure authentication; A.5.15 Access control | PR.AA-03 Users authenticated |
| Remove user override of untrusted servers | Policy forbids the "trust this new server?" prompt, so a user cannot click through an evil twin | - | A.5.17 Authentication information | PR.AA-03 Users authenticated |
| Migrate PEAP-MSCHAPv2 / EAP-TTLS to EAP-TLS | Mutual certificate authentication leaves no password to harvest or crack; MSCHAPv2 is cryptographically weak and must not be exposed to an unvalidated server | - | A.8.5 Secure authentication; A.5.17 Authentication information | PR.AA-01 Identities and credentials; PR.AA-03 Users authenticated |
| WIPS rogue detection and monitoring | Continuous RF monitoring to classify and locate rogue/evil-twin APs on corporate SSIDs | - | A.5.15 Access control | DE.CM Continuous monitoring |
| Phishing-resistant MFA on downstream services | Devalues any credential that is harvested, so a cracked MSCHAPv2 secret does not grant single-factor access | - | A.5.17 Authentication information | PR.AA-01 Identities and credentials |

## Honest limitations

The defining limitation is that the rogue RADIUS is the attacker's own equipment and produces **zero telemetry on your side**; there is no log to alert on at the moment of capture, which is why this is a hardening skill before a detection one. A correctly hardened supplicant that validates the certificate simply refuses to connect, so the "signal" is often a non-event (a connection that did not happen) plus a client-side failure that is easy to lose in noise. WIPS can miss a brief, low-power, or off-channel rogue, or one operating from an adjacent building outside your sensor coverage, and rogue containment is legally and operationally constrained. 802.11w (Protected Management Frames) hardens against deauthentication and does not stop evil-twin credential capture at the EAP layer. Crucially, MSCHAPv2 is cryptographically broken, so once a PEAP/TTLS inner exchange is captured it cracks offline regardless of its length; certificate validation is the only thing preventing the capture in the first place, which is why EAP-TLS migration, not stronger passwords, is the durable fix. Audit the supplicant configuration (hunt step 1) before relying on any detection.

## ATT&CK and D3FEND

- MITRE ATT&CK: [T1557.004 Adversary-in-the-Middle: Evil Twin](https://attack.mitre.org/techniques/T1557/004/) (Credential Access, Collection) for the rogue AP + rogue RADIUS credential capture, under parent [T1557 Adversary-in-the-Middle](https://attack.mitre.org/techniques/T1557/); [T1110.002 Password Cracking](https://attack.mitre.org/techniques/T1110/002/) (Credential Access) for offline cracking of the captured MSCHAPv2 challenge/response; [T1040 Network Sniffing](https://attack.mitre.org/techniques/T1040/) (Credential Access, Discovery) for capture of the EAP identity and inner exchange.
- MITRE D3FEND: [D3-CBAN Certificate-based Authentication](https://d3fend.mitre.org/technique/d3f:Certificate-basedAuthentication) maps to EAP-TLS mutual authentication and to the supplicant validating the RADIUS server certificate, which directly counters the AiTM case; [D3-CA Certificate Analysis](https://d3fend.mitre.org/technique/d3f:CertificateAnalysis) (with sub-techniques D3-ACA Active and D3-PCA Passive) for verifying the authentication-server certificate against the pinned CA and expected name; [D3-NTA Network Traffic Analysis](https://d3fend.mitre.org/technique/d3f:NetworkTrafficAnalysis) for WIPS rogue-AP detection; [D3-MFA Multi-factor Authentication](https://d3fend.mitre.org/technique/d3f:Multi-factorAuthentication) for devaluing harvested credentials downstream.
- Public rule and reference sources: [SigmaHQ repository](https://github.com/SigmaHQ/sigma) (`rules/windows/` for NPS 6273 and logon 4624/4625 analytics); [RFC 3748 Extensible Authentication Protocol (EAP)](https://www.rfc-editor.org/rfc/rfc3748) and [RFC 5216 EAP-TLS Authentication Protocol](https://www.rfc-editor.org/rfc/rfc5216); [RFC 2865 RADIUS](https://www.rfc-editor.org/rfc/rfc2865); [NIST SP 800-153 Guidelines for Securing Wireless Local Area Networks](https://csrc.nist.gov/pubs/sp/800/153/final); Microsoft Learn on NPS logging and the WLAN-AutoConfig and OneX operational channels; vendor WIPS rogue-management documentation (Cisco Catalyst 9800 rogue management, Aruba RAPIDS).

**Scope note.** This is a defensive skill. It explains 802.1X/EAP rogue-RADIUS credential theft only to the depth needed to harden supplicants and detect abuse, and deliberately ships no evil-twin, rogue-RADIUS, or MSCHAPv2 cracking tooling. UMBRASEC publishes defense, not offense.