AV-12 · Wireless rogue access and evil twin attacks

Wireless environments can be abused through rogue access points, evil twin networks, and credential capture because Wi-Fi is physically accessible to anyone within radio range — and users connect by name, not by cryptographic identity.

$ action: Monitor the wireless environment for rogue SSIDs, enforce strong authentication and certificate validation, segment wireless networks by trust level, and train users to recognize trusted SSIDs and certificate prompts.

1. Why Wireless Threats Persist

Wireless is physically accessible. An attacker doesn't need a cable in your building — they need to be within radio range. That changes the defender's control model: you can't rely on physical access controls to keep attackers off your network boundary.

Evil twin attacks persist because users connect by SSID name and often ignore certificate warnings. If a rogue AP broadcasts a name that matches corporate Wi-Fi and the captive portal looks plausible, users connect — especially in lobbies, conference rooms, and hotel networks where certificate prompts are already common and confusing.

Wireless risk isn't only about cracking the encryption. Poorly segmented guest networks that route to internal systems, unmanaged BYOD devices, and inadequate RF monitoring all create paths that a careful attacker can exploit.

2. What Attackers Can Do in Wireless Scenarios

A rogue or evil-twin AP can capture enterprise authentication credentials if 802.1X is misconfigured, capture web session cookies from unencrypted traffic, or redirect users to credential-harvesting portals. In proximity attacks at offices or conferences, these are real-world techniques, not just lab exercises.

Once a device connects to a rogue AP, all unencrypted traffic is visible to the attacker. Even with encrypted traffic, DNS queries often reveal destinations, and a determined attacker can run SSLstrip-style attacks against systems that don't enforce HSTS properly.

Weakly segmented wireless networks are the secondary risk. A guest network that can reach internal management interfaces, or a BYOD VLAN that can reach production servers, turns a wireless entry point into a full network compromise path.

3. How Defenders Mitigate Wireless Attack Vectors

Use enterprise wireless authentication (802.1X/EAP) with server certificate validation required on client devices. Deploy the certificate correctly and validate that clients actually reject untrusted certificates — don't assume they do. Test it.

Monitor the RF environment for unexpected SSIDs, BSSID spoofing, and unusual signal sources near your facilities. Wireless controller logs often surface rogue AP detections automatically; the question is whether anyone is watching those alerts.

Segment wireless networks by trust level — separate VLANs and firewall policies for employee, guest, BYOD, and IoT traffic. Test those boundaries. A wireless client on the guest VLAN should not be able to reach internal management systems. Validate that with an actual nmap scan from the guest network.

detection-signals

$Wireless controller or Kismet detects an SSID matching corporate naming conventions but with a BSSID not in the authorized AP inventory.
$A user reports being prompted for credentials or a certificate warning on a known corporate SSID — when no network changes were made.
$A wireless client appears on an internal VLAN or subnet it shouldn't be able to reach given the network segmentation policy.
$RADIUS or 802.1X authentication logs show repeated failed attempts from an unusual client MAC address or EAP identity.
$Wireless controller management interface logs show an unauthorized access point association or RF survey anomaly near a facility.

telemetry-sources

$Wireless controller / AP logs and WLAN management dashboards.
$RADIUS/802.1X/auth logs for enterprise Wi-Fi authentication behavior.
$Kismet or authorized wireless monitoring telemetry in lab/defender programs.
$Network segmentation/firewall logs for wireless VLANs and internal access attempts.
$Endpoint/user reports and certificate-warning telemetry where available.

recommended-tools-and-guides

open Kismet Monitor wireless spectrum and detect rogue/unauthorized AP activity in authorized environments. open Aircrack-ng Learn wireless protocol behavior and defensive validation in controlled labs. open Wireshark / TShark Inspect wireless/authentication traffic captures and validate protocol events. open tcpdump Capture supporting network-side evidence from WLAN gateways and VLAN boundaries. open /learning/tools/paths#wireless-defense-path Follow the guided wireless defense path for structured labs and operational learning.

related-learning-modules

Build fundamentals and workflows that directly support defending against this threat pattern.

open /learning/tcp-ip-dns-http-tls-routing-switching TCP/IP, DNS, HTTP, TLS, Routing and Switching Fundamentals open /learning/packet-capture-protocol-analysis-wireshark-tshark Packet Capture and Protocol Analysis with Wireshark / TShark open /learning/subnetting-nat-firewall-policy-segmentation Subnetting, NAT, Firewall Policy Logic, and Segmentation Basics

related-tool-pages

Use these detailed tool guides to practice safe validation, evidence collection, and triage workflows for this threat.

open /learning/tools/kismet Kismet open /learning/tools/aircrack-ng Aircrack-ng open /learning/tools/wireshark-tshark Wireshark / TShark open /learning/tools/tcpdump tcpdump

lab-safe-detection-workflows

These commands are for learning, validation, and defensive triage in your own lab or authorized environment. Adapt to your tooling and log locations.

Wireless environment monitoring (authorized lab / defensive survey)

kismet -c wlan0mon
tshark -r wireless-auth-sample.pcap -Y eapol -T fields -e frame.time -e wlan.sa -e wlan.da
tcpdump -ni any -c 200 '(udp port 67 or udp port 68 or tcp port 443)'

$ why: Combine RF visibility and network-side captures to understand whether suspicious wireless activity led to real DHCP/auth/network access.

Wireless segmentation validation (authorized)

nmap -sn 10.20.30.0/24
nmap -Pn -p 22,3389,445 10.10.10.20
printf "ssid,vlan,allowed_paths,blocked_paths,test_result\n" > wireless-segmentation-validation.csv

$ why: Validate that guest/BYOD/employee WLANs can only reach intended resources and cannot access sensitive management/internal paths.

triage-questions

?Is the detected SSID or BSSID in the authorized AP inventory, and does its physical location match where the signal is coming from?
?Are users receiving certificate prompts or captive portal pages on SSIDs that shouldn't have them — indicating something between the user and the real AP?
?Did the suspicious wireless activity result in a successful client association, DHCP lease, or authentication event that warrants network-side investigation?
?Are wireless VLANs enforcing the intended segmentation — can a guest VLAN client reach internal management or production systems?
?What immediate action is appropriate: block the switch port the rogue AP is connected to, push a user advisory, or increase monitoring while gathering more evidence?

defender-actions.checklist

$Monitor wireless environment for rogue APs and SSID impersonation.
$Enforce strong auth and certificate validation for enterprise Wi-Fi.
$Segment guest/BYOD/IoT/employee/admin wireless networks.
$Correlate WLAN telemetry with auth and network logs during triage.
$Train users to report suspicious SSIDs, captive portals, and certificate prompts.

study-workflow

Learn what normal behavior looks like for this area (auth, exposure, config, or internal traffic).
Identify the logs and telemetry that should show the behavior.
Practice one safe validation in a lab or authorized environment.
Write a short playbook for detection, triage, and response.
Review the related tool guides under /learning/tools.

<- previous threat AV-11 · DNS abuse, tunneling, and command-and-control open /learning Continue into curriculum modules and tool paths