CWSP study materials
CWSP study resources

CWSP (ABWM): Loading-Dock Alarm: Evil Twin, or the Contractor's Label Printer?

CWSP · Put your knowledge to work in context.

All case studies

Loading-Dock Alarm: Evil Twin, or the Contractor's Label Printer?

A 900-employee manufacturer runs a WIPS with 55 APs and 8 dedicated sensors. At 02:15 the console raises an SSID-match rogue alarm: BSSID 00:1A:2B:xx:xx:xx, SSID identical to the corporate SSID, channel 6, RSSI -52 at sensor 3 near the loading dock, open authentication, 802.11n enabled. The authorized corporate SSID uses WPA2-Enterprise and 802.11n-only is disabled in the corporate profile. Ten minutes later the same sensor reports an unclassified AP with a printer-vendor OUI at -78 dBm. The night supervisor says a contractor was replacing label printers that evening. Last month an auditor wrote that all rogues must be classified, mitigated, or authorized within 24 hours, and that mitigation must be documented.

1. Classify both alarms and identify what additional evidence determines whether the SSID-match device is actually attached to your wired network.

Read the worked answer

Alarm 1 - SSID match: treat as a suspected evil twin until disproved. Three attributes conflict with the corporate profile: no encryption where the real SSID requires WPA2-Enterprise, 802.11n on an SSID whose profile excludes it, and a signal level (-52 dBm) consistent with a device inside or immediately outside the building. None of those alone is proof; a neighbour's AP with a copied SSID looks the same.

Alarm 2 - printer OUI at -78 dBm: most likely the contractor's printer in Wi-Fi Direct / soft-AP mode. Low risk, but confirm it is not in ad-hoc mode and that the SSID is not the corporate one.

Evidence that settles it:

  1. Search switch CAM tables, DHCP leases, and ARP/NAC data for the BSSID's MAC and any MAC seen transmitting from that radio. A hit behind a known access port moves this from 'neighbour' to 'rogue on the LAN' and triggers incident response.
  2. Check whether any of your own client MACs are associating to it, and whether a rogue DHCP server is answering - that is active man-in-the-middle, not just a lookalike.
  3. Check whether your clients are receiving deauthentication toward it (containment by the attacker to force reassociation).

Do not classify from OUI or SSID alone; those two fields are trivially spoofed.

2. The duty engineer wants to enable automatic containment on both alarms at 02:20. Evaluate that decision and describe the safer mitigation sequence.

Read the worked answer

Containment is not a passive action - it works by transmitting spoofed deauthentication or disassociation frames on the rogue's channel, which is deliberate interference and can be unlawful against equipment you do not own, and can also disrupt clients that are legitimately using a neighbour's network. Auto-containment on an unclassified alarm at 02:20, when nobody can confirm the device is inside the facility, is the wrong default.

Correct sequence:

  1. Locate physically. Use sensor triangulation and, if available, a spectrum/locate tool. Containment policy should be scoped to 'inside our premises only'.
  2. Try the wired side first. If the BSSID or its clients appear in CAM tables, shut the port or let port-security/NAC err-disable it. That is precise and carries no RF liability.
  3. If RF containment is the only option, contain the single offending BSSID rather than a wildcard SSID rule, time-box it (for example 30 minutes with auto-expiry), and require an approval step in the workflow.
  4. Authorize the printer so it stops generating alarms and does not train the night shift to ignore the console.
  5. Document the classification decision, evidence, approver, and containment start/stop times to satisfy the audit finding.

3. Two weeks earlier the same AP-based scanning missed a short-lived rogue near the same dock. Explain why, and what you would change in the discovery configuration.

Read the worked answer

APs that are serving clients can only scan off-channel part-time. Typical behaviour is a short dwell (tens of milliseconds) per channel on a rotation that may revisit 2.4 GHz channels only every 10-30 seconds. A device that beacons or is used briefly between dwell windows is simply not observed; the AP's first duty is its own BSS.

Changes to consider:

  • Move or add a dedicated sensor covering the dock and yard, since a sensor in full-time monitor mode has no off-channel duty cycle.
  • Shorten the off-channel scan interval and lengthen dwell on 2.4 GHz channels 1, 6, and 11 if the platform allows per-band tuning; accept the small client-throughput cost knowingly.
  • Enable monitoring of the 5 GHz channels used by the corporate profile as well, not just 2.4 GHz, because an evil twin on 5 GHz will be missed entirely by a 2.4 GHz-only rotation.
  • Correlate RF alarms with wired-side data (CAM/NAC) so an alarm that appears and disappears is still resolvable after the fact.

The judgement point is that discovery coverage is a design parameter with a cost: more scanning time buys detection probability and costs client airtime.