OffSec Wireless Professional common mistakes
OffSec Wireless Professional · Understand the traps and how to avoid them.
Spending the first lab hour trying to bring up a monitor-mode interface before confirming the chipset and driver actually support monitor mode plus frame injection, then blaming the card when capture shows nothing.
Candidates assume any USB Wi-Fi adapter works because it appears in iw dev; many adapters (especially built-in laptop cards and Realtek/MediaTek parts with out-of-tree drivers) load a driver that permits managed mode only, and injection silently fails or the interface refuses iw dev wlan0 set monitor control.
What to do instead
Before any engagement, run lsusb/lspci to get the exact vendor:product ID, map it to the chipset (Atheros AR9271, Ralink RT3070/RT3572, Realtek RTL8812AU/8814AU, MediaTek MT7612U), then ethtool -i wlan0 and modinfo <driver> to confirm the loaded module. Verify with airmon-ng start wlan0, then aireplay-ng --test wlan0mon to prove injection. Keep a known-good AR9271 adapter as a control so a failure is attributable to the card, not your procedure.
Leaving NetworkManager, wpa_supplicant, and dhclient running, so airmon-ng starts a monitor interface that immediately gets torn down or produces sporadic captures, and then re-running airmon-ng repeatedly instead of diagnosing the cause.
On modern distros NetworkManager auto-manages any new wireless interface it sees and will reassociate the card to a saved network mid-capture; the symptom looks like an adapter fault, so candidates keep cycling monitor mode rather than stopping the manager.
What to do instead
Run airmon-ng check kill (or explicitly systemctl stop NetworkManager wpa_supplicant and kill dhclient) before starting monitor mode, and confirm with airmon-ng check that no interfering processes remain. Bring the interface down with ip link set wlan0 down before iw dev wlan0 set type monitor when doing it manually. Re-enable the manager only after capture is finished.
Capturing on the wrong channel or a channel set that does not include the target BSSID, then concluding the handshake/PMKID cannot be obtained because the capture file is empty of relevant frames.
Monitor mode captures one channel at a time unless hopping is configured; candidates start airodump-ng without -c and without --bssid, so the card hops away exactly when the target's frames arrive, and 5 GHz targets are missed entirely when the adapter is left in its default band.
What to do instead
Lock to the target with airodump-ng -c <channel> --bssid <BSSID> -w cap wlan0mon, and confirm the channel with iw dev wlan0mon info. For 5 GHz, verify the adapter supports the band and set the channel explicitly. Validate the capture is live by watching the #Data and #/s columns increase before attempting any attack.
Treating a captured EAPOL 4-way handshake as automatically crackable and launching a wordlist run without checking that the handshake is complete (all four messages, valid MIC, matching ANonce/SNonce).
airodump-ng flags WPA handshake: as soon as it sees any EAPOL pair, but a partial capture (often only message 1 and 2, or a replay with a mismatched nonce) will never verify, and candidates burn hours on dictionary runs against an invalid handshake.
What to do instead
Open the capture in Wireshark and confirm messages 1-4 (or the minimum 2 and 3 with matching nonces) are present with wlan_rsna_eapol.keydes.msgnr visible. Run aircrack-ng -w <list> cap-01.cap and read the 'handshake' line: it must say a valid handshake was found, not 'no valid WPA handshakes found'. If invalid, recapture by forcing a fresh association rather than reusing the file.
Using a deauthentication flood as the default first move against every target, which disrupts clients, may be logged or flagged, and often fails to yield a handshake because the client immediately reassociates to a cached profile without a full 4-way exchange.
Deauth is the most-taught technique, so candidates reach for it reflexively; they also broadcast deauths to the whole BSSID instead of targeting one client, and they do not wait for the reassociation EAPOL that actually contains the handshake.
What to do instead
Prefer passive capture first: wait for a natural association, or target a single client with aireplay-ng --deauth 3 -a <BSSID> -c <client MAC> wlan0mon and keep airodump-ng running on the locked channel to catch the resulting handshake. If the goal is PMKID, use hcxdumptool against the BSSID instead of deauthing. Document that deauth is disruptive and scope it to authorised testing windows.
Assuming WPS is unavailable because the AP's beacon shows WPS disabled or because a quick `wash` scan shows nothing, then abandoning the WPS path without verifying with an active probe.
Some APs suppress the WPS information element in beacons while still responding to WPS probe requests, and wash needs the interface on the AP's channel to see the response; candidates scan while hopping and conclude the feature is off.
What to do instead
Lock wash -i wlan0mon -c <channel> to the target channel and confirm the WPS version, locked flag, and AP setup state in the output. Then attempt reaver -i wlan0mon -b <BSSID> -c <channel> -vv (or bully) and read the M-series/status lines to distinguish 'WPS locked', 'no response', and a genuine PIN attempt. Note that many modern APs rate-limit or lock after a few attempts.
Attacking WPA3/SAE or an AP with 802.11w (PMF) enabled using classic deauth and handshake techniques, then reporting the target as uncrackable rather than identifying the actual security configuration.
The presence of WPA3 or PMF changes which attacks are viable (SAE handshakes need different tooling; management frame protection blocks forged deauth), but candidates apply a WPA2 playbook and misinterpret the failure as a tooling problem.
What to do instead
Read the RSN information element in Wireshark: check the AKM suites (PSK vs SAE vs SAE-transition) and the MFPC/MFPR bits for PMF. For SAE, use a tool that supports it (e.g. hcxdumptool/hcxtools for PMKID or SAE capture) and expect dictionary attacks only against weak passphrases. For PMF, note that deauth is ineffective and pivot to PMKID or rogue-AP approaches.
Building a rogue AP (evil twin) that broadcasts the same SSID but uses a different security configuration or channel, so clients never associate and the exercise appears to fail.
Clients match on SSID plus security parameters and often the BSSID in their saved profile; a rogue AP with open security against a WPA2-PSK profile, or on an unexpected channel, will be ignored, and candidates blame the client rather than the clone fidelity.
What to do instead
Clone the target's SSID, security type, and channel exactly, and where the client profile pins the BSSID, spoof the BSSID with airbase-ng --essid <SSID> -c <channel> -a <BSSID> or hostapd with a matching bssid= line. Verify with a second adapter in monitor mode that the beacon matches the original's RSN IE, then test with a controlled client before involving real targets.
Misidentifying the network architecture and security standard from the beacon alone, e.g. labelling an 802.11n AP as 802.11ac because it advertises high rates, or missing that a 'hidden' SSID is simply a zero-length SSID element.
HT/VHT capabilities, channel width, and the presence of a hidden SSID element are easy to misread from airodump-ng's summary columns; candidates rely on the PWR/ENC columns and never inspect the management frames in Wireshark.
What to do instead
Inspect the beacon's HT Capabilities, VHT Capabilities, and HE Capabilities elements in Wireshark to determine the actual PHY (11n/11ac/11ax), and check the SSID element length for hidden networks. Confirm the band from the channel number and the DS Parameter Set. Cross-check the security from the RSN/WPA IEs rather than the airodump-ng ENC shorthand.
Running aircrack-ng or hcxdumptool on a capture taken with the wrong link type or after converting formats incorrectly, so the tool reports no networks or no handshakes despite a visibly populated pcap.
Monitor-mode captures use radiotap headers; converting to pcapng or stripping headers with the wrong tool changes the link type and breaks parsing, and candidates assume the capture itself is bad.
What to do instead
Check the link type with capinfos cap-01.cap (expect 802.11 plus radiotap) and keep the original capture untouched. Convert only with hcxpcapngtool for hash extraction or editcap -F pcap when a tool requires classic pcap, then re-verify with aircrack-ng cap-01.cap that the BSSID and handshake are still recognised before cracking.