---
name: detect-rogue-ap
description: "Detection and response methodology for rogue and evil-twin wireless access points, where an attacker stands up an unauthorized AP impersonating a trusted SSID (or plants one on the wired LAN) to lure clients, harvest credentials, and run an adversary-in-the-middle (MITRE ATT&CK T1557.004, T1200; enabling T1557). Signals come from controller rogue-AP classification and WIDS/WIPS (Cisco Catalyst 9800 and RLDP, Meraki Air Marshal, Aruba/HPE WIP), Kismet APSPOOF alerts, the Windows WLAN-AutoConfig Operational log (Event ID 8001), and NPS/RADIUS logs. The skill gives the SSID/BSSID allowlist signal, a hunt that diffs seen BSSIDs against an authorized-AP inventory, and 802.1X certificate validation and WIDS hardening. Use when investigating an unexpected AP broadcasting a corporate SSID, triaging a rogue-AP or Air Marshal SSID-spoof alert, hunting for an evil twin or a rogue AP on the wire, or writing rogue-AP detections."
---

# Rogue and Evil-Twin Access Points - 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 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

A rogue AP is any access point on your airspace or your wired LAN that you did not authorize. An evil twin is the sharpest case: an AP that advertises a legitimate SSID with a BSSID (radio MAC) you do not own, usually with a stronger signal or a weaker security mode, to pull clients onto it and sit in the middle. The decisive truth for detection is that the attacker can clone the SSID but not your authorized BSSID list. Maintain an inventory of approved BSSIDs and alert on any radio broadcasting a corporate SSID that is not in it, on any security-mode downgrade of a known SSID (WPA2/3-Enterprise seen as Open or PSK), and on your controller classifying a rogue as being on the wired network. Close the enterprise evil twin for good by enforcing 802.1X server-certificate validation on clients so a rogue RADIUS cannot harvest credentials. This skill is defensive and ships no AP-impersonation, karma, or captive-portal tooling.

## What it looks like, defender view

Two radios advertise the same SSID at the same time with different BSSIDs, one of them not in your authorized-AP inventory, often on a different channel and frequently with a noticeably stronger RSSI than the real AP as it tries to win client association. The security configuration frequently does not match: a WPA2-Enterprise corporate SSID suddenly appears as Open or WPA2-PSK, because the attacker cannot reproduce your RADIUS back end and downgrades to capture a handshake or credentials instead. On the host side a client's wireless log records a connection to the corporate SSID but with a BSSID whose OUI is not your AP vendor's. Where the rogue is a physical AP plugged into a wall port, the wired side shows an unexpected AP-vendor MAC on an access port, a second DHCP server, or your controller tracing the rogue's wired MAC and flagging "rogue on wire."

## Log sources and signals

The signal spans the radio layer, the controller, and the endpoint. Use as many as you have:

- **Wireless LAN controllers and cloud WLAN (rogue classification).** Cisco Catalyst 9800 and WLC detect, classify, and can contain rogue APs, and use Rogue Location Discovery Protocol (RLDP) and switch-port tracing to decide whether a rogue is on your wired network; Cisco DNA Center / Catalyst Center aWIPS adds WIPS signatures. Cisco Meraki Air Marshal raises rogue-SSID and "SSID spoof" alerts. Aruba/HPE ArubaOS Wireless Intrusion Protection (WIP) classifies rogue, interfering, and suspected-rogue APs and logs containment. Ubiquiti UniFi flags rogue/neighboring APs. Forward these as syslog to the SIEM and alert on the rogue-AP and SSID-spoof events with the offending BSSID, channel, and RSSI.
- **Dedicated WIDS/WIPS sensors.** [Kismet](https://kismetwireless.net/docs/readme/alerts/alerts/) raises `APSPOOF` when a configured SSID is advertised by a BSSID that is not on its approved list, which is exactly the evil-twin condition; the approved SSID/BSSID map is set in `kismet_alerts.conf`. Kismet also writes a PCAP for confirmation in Wireshark.
- **Windows endpoint (host-side, high value and widely available).** The **Microsoft-Windows-WLAN-AutoConfig/Operational** log records association detail no controller sees from the client's perspective. **Event ID 8001** ("WLAN AutoConfig service has successfully connected to a wireless network") carries the SSID, the **BSSID**, the connection mode, the authentication method, and the cipher; **8002** records a failed connection. Collect 8001 fleet-wide and compare each SSID's observed BSSIDs and security settings against the authorized set.
- **RADIUS / NPS (for WPA-Enterprise).** Network Policy Server logs (Event IDs **6272** access granted, **6273** access denied, **6274** discarded) show which supplicants authenticated to the real server. An enterprise evil twin stands up its own RADIUS, so its victims never reach your NPS; a gap between expected and seen authentications, together with endpoint 8001 events showing those clients "connected," is itself a signal.
- **Switch and NAC telemetry (for rogue on wire).** Switch MAC-address tables, port-security violations, and 802.1X/NAC authentication logs surface an unauthorized device (often an AP-vendor OUI) appearing on an access port, or multiple MACs behind a port that should carry one host.

What normal looks like: your authorized APs each present a stable, inventoried BSSID per radio, a consistent security mode per SSID, and clients roam between those known BSSIDs. Neighboring-business APs on other SSIDs are expected noise and should be classified as "interfering," not rogue. The anomaly is an unlisted BSSID carrying your SSID, a security downgrade of your SSID, or an AP appearing on your wire.

## Detection approach

Alert against an allowlist, not against a signature of the attack. The high-signal conditions are: (1) any BSSID advertising a corporate-owned SSID that is not in your authorized-AP inventory; (2) a known SSID observed with a weaker security mode than its policy (Enterprise downgraded to PSK or Open), which is the evil-twin credential-capture tell; (3) your controller classifying a rogue as on-wire via RLDP or switch-port trace, the strongest single signal because it means the device bridges your LAN; and (4) a client (Windows 8001) connecting to a corporate SSID with a BSSID whose OUI is not your AP vendor's or is absent from the inventory. Prefer the purpose-built controller and WIDS rogue classification above, because 802.11 beacons are radio events rather than log records and fit log-oriented rule formats poorly; Sigma-style rules operate on the controller syslog and the Windows WLAN-AutoConfig records, not on the beacons themselves. A tuned UMBRASEC rule is not yet shipped for this threat. For maintained public detections use the vendor rogue-AP and Air Marshal / aWIPS / WIP signatures, Kismet's `APSPOOF` via `kismet_alerts.conf`, MITRE ATT&CK's own detection strategy [DET0379](https://attack.mitre.org/detectionstrategies/DET0379) (analytic AN1069, rogue APs reusing a legitimate SSID with mismatched BSSID or encryption), and any SIEM-side controller or WLAN-AutoConfig rules tracked in the general [SigmaHQ repository](https://github.com/SigmaHQ/sigma).

## Threat hunt

Hypothesis: an unauthorized AP is impersonating a corporate SSID or has been bridged onto the LAN to intercept clients.

1. Export the authorized BSSID/SSID inventory from your WLC or WIDS. Pull every BSSID seen beaconing a corporate SSID over the window from controller and sensor data, and diff against the inventory. Any unlisted BSSID carrying your SSID is the lead.
2. For each corporate SSID, list the distinct security configurations observed (auth method and cipher). More than one config for a single SSID, especially an Open or PSK variant of an Enterprise network, points to an evil twin running a downgrade.
3. Pull Windows **8001** events fleet-wide from Microsoft-Windows-WLAN-AutoConfig/Operational, group by SSID, and enumerate the distinct BSSIDs clients actually connected to. Flag any BSSID absent from the inventory or whose OUI does not match your AP vendor, and any 8001 showing a weaker auth/cipher than policy for that SSID.
4. For rogue-on-wire, correlate the controller's RLDP / switch-port trace with switch MAC tables and port-security logs: look for access ports presenting an AP-vendor OUI, an unexpected second DHCP server, or multiple MACs behind a single-host port.
5. For WPA-Enterprise, compare the set of clients that reached the real NPS (6272 granted, 6273 denied, 6274 discarded) against those the endpoints report as connected (8001). Clients "connected" to the SSID but never seen at your RADIUS may have been served by a rogue RADIUS; also hunt for endpoints whose server-certificate validation was disabled, since those are the ones an enterprise evil twin can harvest.

## Hardening

Shrink the surface so impersonation fails and detection has an allowlist to work from. The decisive control for the enterprise case is client-side **802.1X server-certificate validation**: configure supplicants (by GPO or MDM) to validate the RADIUS server certificate, pin the trusted root CA, and specify the expected server name, so a rogue RADIUS with any other certificate is rejected and no credential is sent. Maintain an authorized-AP inventory in the controller/WIDS so rogue classification and the hunts above have ground truth, and run continuous WIDS/WIPS with a reviewed containment policy. On the wired side, enforce 802.1X/NAC and port security (limit and sticky-learn MACs, disable unused ports) to stop an AP being bridged onto the LAN. Prefer WPA3-Enterprise, and keep 802.11w Protected Management Frames enabled so the deauth that often precedes an evil twin cannot cheaply herd clients. Train users not to connect to open duplicates of corporate SSIDs. The mappings below are grounded in the UMBRASEC [foundation](https://umbrasec.dev/guide/foundation.html), [identity and access](https://umbrasec.dev/guide/identity-and-access.html), and [detection and response](https://umbrasec.dev/guide/detection-and-response.html) guides; the Essential Eight has no control that maps cleanly to wireless AP trust, so those cells are left blank rather than invented.

| Control | What it does | Essential Eight | ISO 27001:2022 | NIST CSF 2.0 |
|---|---|---|---|---|
| Authorized-AP inventory (BSSID allowlist) | Gives rogue classification and the hunts a ground truth of what is yours | - | A.5.9 Inventory of assets | ID.AM Asset management |
| 802.1X server-certificate validation (WPA-Enterprise) | Rejects a rogue RADIUS so an evil twin cannot harvest credentials | - | A.8.5 Secure authentication | PR.AA-03 Users authenticated |
| Continuous WIDS/WIPS monitoring and alerting | Surfaces rogue and spoofed APs and on-wire rogues in near real time | - | A.8.16 Monitoring activities; A.8.15 Logging | DE.CM Continuous monitoring; DE.AE Adverse events |
| Wired 802.1X/NAC and switch port security | Stops a physical rogue AP being bridged onto the LAN | - | A.8.5 Secure authentication | PR.AA-03 Users authenticated |
| User awareness (do not join duplicate open SSIDs) | Removes the human path the lure depends on | - | A.6.3 Awareness | PR.AT Awareness and training |

## Honest limitations

Detection here depends entirely on wireless and controller visibility plus the authorized-AP inventory being complete and current; a stale inventory produces both misses and false positives, and if you run no WIDS/WIPS and your controller emits no rogue events, an airborne evil twin is invisible to a conventional SIEM. The attacker can clone your SSID and spoof a BSSID, so the BSSID identifies the radio presented, not the operator, and a careful attacker can match your AP vendor's OUI to weaken the OUI check. A rogue that does not reuse a corporate SSID (a lure on an entirely new name, or a karma-style response to client probe requests) will not trip an SSID-allowlist rule and needs the behavioral and on-wire signals instead. Server-certificate validation only protects WPA-Enterprise, and only where it is actually enforced on every client; PSK and Open networks have no equivalent and rely on detection. On-wire detection via RLDP and switch tracing can miss a rogue that is wireless-only or that NATs its wired side. Treat the on-wire classification and the honeypot-clean signal of an unlisted BSSID on a corporate SSID as the high-confidence leads, baseline neighboring APs as interfering rather than rogue to keep noise down, and confirm before any automated containment, since containing a neighbor's or a guest AP can cause its own disruption.

## ATT&CK and D3FEND

- MITRE ATT&CK: [T1557.004 Evil Twin](https://attack.mitre.org/techniques/T1557/004/) (Credential Access, Collection; Network Devices platform), a sub-technique of [T1557 Adversary-in-the-Middle](https://attack.mitre.org/techniques/T1557/); [T1200 Hardware Additions](https://attack.mitre.org/techniques/T1200/) where the rogue AP is bridged onto the wired network. Detection Strategy [DET0379](https://attack.mitre.org/detectionstrategies/DET0379); ATT&CK mitigations M1031 Network Intrusion Prevention and M1017 User Training.
- MITRE D3FEND: [D3-NTA Network Traffic Analysis](https://d3fend.mitre.org/technique/d3f:NetworkTrafficAnalysis/) for the rogue and spoofed-AP detection side; the D3FEND Isolate tactic (network and broadcast-domain isolation) covers the wired-side containment of an on-wire rogue. The 802.1X server-certificate control is best read as cryptographic authentication hardening rather than one named D3FEND technique.
- Public rule and sensor sources: [Kismet WIDS alerts](https://kismetwireless.net/docs/readme/alerts/alerts/) (`APSPOOF`); Cisco Catalyst 9800 rogue management / RLDP, aWIPS, and Meraki Air Marshal documentation; Aruba/HPE ArubaOS Wireless Intrusion Protection; [SigmaHQ repository](https://github.com/SigmaHQ/sigma) for controller-log and WLAN-AutoConfig rules.

**Scope note.** This is a defensive skill. It explains rogue and evil-twin access points only to the depth needed to detect and mitigate them and deliberately provides no AP-impersonation, karma, rogue-RADIUS, or captive-portal tooling. UMBRASEC publishes defense, not offense.