Certificate Validation, Shared PSKs and a Travel Router in the Loading Bay

The question behind the question is whether an attacker who stands up a fake AP can harvest crackable MSCHAPv2 challenge/response pairs. That requires clients to (a) accept an untrusted certificate and (b) send the response over it. Both can be assessed without touching a real employee.

First, configuration review. On the managed Windows and macOS builds, check whether the PEAP profile has 'validate server certificate' enabled and the private CA pinned, and whether users can accept a new certificate. On MDM-managed devices this is often a one-line answer that takes twenty minutes and carries zero risk; do this before any radio work.

Second, a controlled live test with the test laptop only. Stand up a rogue AP with a self-signed certificate mimicking the corporate SSID, using low power so its footprint stays inside the room you are in, and observe whether your enrolled test device prompts, refuses, or associates silently. If it associates, the certificate check is not enforced; you now know the answer without ever seeing a real employee's exchange. Do not run asleap or similar against captured production traffic, and do not keep any handshake that includes a real username.

Third, since deauth is prohibited, do not force clients to roam. Instead rely on natural association of the test device and on the fact that the attacker scenario in the real world involves a user who connects voluntarily after a strong-signal lure, which is a social-engineering step you can describe rather than execute.

Record certificate subject, the client's behaviour, the device build and the time. The finding is 'PEAP without server validation enables offline cracking of MSCHAPv2 responses', evidenced by your own account.

A single pre-shared key held by 40 devices, unchanged since 2019, means the key is effectively public within the operational staff and any contractor who has ever provisioned a scanner. Anyone with the key joins the same layer-2 segment as the scanners, and the blast radius depends entirely on segmentation you have not yet verified.

Testing, in order of cost:

1. Confirm whether the scanner SSID is on its own VLAN and what the firewall permits toward corporate subnets and the internet. Often the answer here is worse than the key itself.
2. Determine whether the PSK is reused on the guest SSID or any other SSID, which is common and turns one weak secret into two entry points.
3. Capture a four-way handshake passively during the night window and attempt an offline dictionary attack against it, with the wordlist stage run on your own hardware. This is passive and safe. If the key falls, do not join the network with it; report it and stop.
4. Check whether WPS is enabled and whether PMF/802.11w is enforced.

Remediation advice, sequenced for a 24/7 site:

• Short term: rotate the PSK in a maintenance window, accepting that 40 devices need re-provisioning, and isolate the scanner VLAN from corporate with explicit allow rules to the inventory application only.
• Medium term: move scanners to 802.1X with device certificates, or to WPA3-SAE with per-device keys (MPSK) if the hardware supports it, so one lost handheld does not compromise the fleet.
• Verify MAC filtering is not being relied on as a control; it is trivially spoofed and gives false comfort.

The incident is a detection and control problem, not a Wi-Fi encryption problem: a device was plugged into a live wall port and stayed there for three weeks.

Controls to recommend, in order of effect:

• 802.1X or MAC authentication bypass with profiling on access ports, so an unknown device on a wall port lands in a quarantine VLAN or is refused. Port security with a sticky MAC limit of one or two is a cheap partial substitute.
• NAC/asset inventory reconciliation, so a device that appears on the network without a ticketed asset record raises an alert the same day.
• WIPS or a managed AP infrastructure with rogue classification, which catches the wireless side of a travel router, plus a documented procedure for physical sweeps of high-risk areas such as the loading bay.
• DHCP snooping, dynamic ARP inspection and unused-port shutdown on switch ports in public areas.

Testing detection, safely:

1. Get written authorisation naming the exact port, the test device's MAC and the window.
2. Agree with IT what a 'detection' means: an alert raised, a ticket opened, or the port shut, and the time limit, for example 30 minutes.
3. Connect a labelled test AP that cannot route to production (no bridging, no NAT to the corporate VLAN) and time how long until someone responds.
4. Remove it yourself at the end, photograph the port state, log the timestamps, and confirm with IT that the device is gone from the asset inventory.

Report the measured time-to-detect; a number like 'three weeks' versus '22 minutes' is what changes budget.