CWSP (ABWM) common mistakes
CWSP · Understand the traps and how to avoid them.
Classifying an attack by the tool that performs it ("that's an aircrack-ng attack") instead of by the frame type, layer, and mechanism being exploited.
Hands-on tool demos are the most memorable part of study, so candidates memorize command syntax and tool output rather than the 802.11 behaviour the tool abuses.
What to do instead
For every attack you study, write a one-line record: frame type/subtype abused, OSI layer, authentication state the attacker must be in, and the specific countermeasure. Example: deauthentication flood = management frame, subtype 12, requires no association, mitigated by 802.11w/PMF plus WIPS rate-based detection. Drill attack name to frame to countermeasure with no tool name in the answer.
Treating passive and active scanning as interchangeable and being unable to state which one leaves on-air evidence a WIDS can log.
Both produce an identical BSS list in a client UI, so the frame-level difference (listening for Beacons versus transmitting Probe Requests) is invisible in normal operation and never gets reinforced.
What to do instead
Lock in the pairing: passive = client listens for Beacons and Probe Responses; active = client transmits Probe Requests, with a wildcard/directed SSID. Then answer discovery-detection questions by naming the captured frame, not the concept: a wildcard probe flood appears as Probe Requests, a hidden SSID is exposed by Probe Requests and Association Requests rather than Beacons, and an evil twin is identified by comparing BSSID/SSID/channel/security tuples across sensors.
Mislabeling To DS/From DS bit combinations and the roles of Address 1, 2, 3 and 4 when reading a capture.
The four combinations are read once as a table and never practised, and most study captures fall into only one or two of the four cases.
What to do instead
Rebuild the 2x2 table from first principles: 0/0 = ad hoc (or management frame, both bits clear), 1/0 = client to AP via the DS, 0/1 = AP to client from the DS, 1/1 = wireless distribution system/4-address frame. Then annotate five real frames, naming every address field and the bit values. Target under one minute per frame.
Confusing the cipher suite selector with the AKM suite selector in the RSNE, and skipping the RSN Capabilities field where the PMF/MFP bits live.
Both are 4-byte OUI-plus-type fields sitting near each other in the same information element, so they look alike in a hex dump, and the capability bits are in a separate field that is easy to scroll past.
What to do instead
Decode RSNEs strictly in field order: version, group cipher, pairwise cipher count and list, AKM count and list, RSN capabilities (including MFPC and MFPR), PMKID count. Use a fixed template rather than scanning for a familiar value, and state out loud which count field precedes which list.
Assuming a WIPS can prevent any attack, and never separating what a WIPS detects, what it can mitigate autonomously, and what requires managed-AP or controller cooperation.
Vendor datasheets blur detection and prevention, and exam items hinge on prerequisites such as sensor channel coverage, visibility of management frames, and whether containment requires infrastructure participation.
What to do instead
Maintain a three-column table per attack: detect / mitigate standalone / mitigate only with infrastructure integration, and note the prerequisite for each. Keep three product categories distinct: WIPS (monitoring and containment), WNMS (configuration, firmware, performance management), and spectrum analysis (RF interference, non-802.11 energy).
Placing PMK derivation inside the 4-Way Handshake, or swapping the roles of PMK, PTK and GTK when explaining key delivery.
The 802.1X/EAP exchange and the 4-Way Handshake are taught as one continuous narrative, so the boundary between them blurs and the PMK's origin gets absorbed into the handshake.
What to do instead
Draw two separate phases and label the boundary: phase one, 802.1X/EAP or the PSK produces the PMK; phase two, the 4-Way Handshake derives the PTK from PMK + ANonce + SNonce + both MAC addresses. State explicitly that the authenticator generates the ANonce and the GTK, the supplicant generates the SNonce, and the GTK is delivered encrypted under the KEK portion of the PTK.
Answering EAP-type questions by name association only, without distinguishing outer versus inner authentication and certificate requirements.
Every tunnelled EAP method appears to "just authenticate a user," so the differentiators (client certificate, PAC, server-certificate validation) get flattened into a list of acronyms.
What to do instead
Build a matrix with EAP-TLS, PEAPv0/MSCHAPv2, EAP-TTLS and EAP-FAST as rows and columns for: server certificate required, client certificate required, inner method, tunnel type, credential-replay resistance, and the classic failure mode. Include PEAP or TTLS deployed without server-certificate validation as the evil-twin/rogue-RADIUS credential-capture scenario, and EAP-TLS as mutual certificate authentication with no inner method.
Using "fast roaming" as one undifferentiated concept and mixing up OKC, PMK caching, 802.11r FT, and the roles of 802.11k and 802.11v.
All of these features appear together in vendor roaming feature lists and all reduce roam time, while the real differences lie in the key hierarchy and in which frames are exchanged before reassociation.
What to do instead
Learn them as four separate mechanisms. OKC: PMKID carried in the Reassociation Request, no full 802.1X re-run. PMK caching: AP advertises PMKIDs, client selects one. FT (802.11r): PMK-R0/PMK-R1 hierarchy, FT authentication exchange with the target AP before reassociation, then a 4-Way Handshake deriving the PTK from PMK-R1. Then place 802.11k and 802.11v as neighbour reporting and BSS transition steering aids that change no key material by themselves.
Treating a VPN as a replacement for WLAN-layer security, or choosing between IPsec and SSL/TLS VPN without reference to endpoint type and tunnel termination point.
The defense-in-depth slogan is easy to recite but rarely applied, and candidates import generic VPN knowledge without mapping it onto wireless topologies where the untrusted segment may be the air link itself.
What to do instead
Before selecting a VPN, answer four questions about the scenario: what exactly is the untrusted segment, what is the endpoint (managed laptop versus unmanaged or kiosk device), where does the tunnel terminate, and what does the tunnel not cover. Use those answers to separate IPsec remote access from SSL/TLS VPN, note that PPTP is obsolete and should not be selected, and state explicitly that a VPN sits above the WLAN link and cannot compensate for open or WEP-protected air.
Selecting the most hardened possible configuration on design and policy items instead of the option that satisfies the stated requirements, and answering policy questions with product names rather than enforceable controls.
Security training rewards maximal hardening, so any option containing the strongest cipher or the strictest rule feels correct, and business constraints in the stem read like distractors rather than requirements.
What to do instead
Extract constraints from the stem first: user population, device ownership, guest access, regulatory scope, manageability, and cost. Eliminate any option that violates a stated constraint, then choose the least operationally complex option that meets the requirement. For policy items, phrase the answer as a control statement covering who it applies to, what must or must not be done, the exception process, and the review cadence, not as a named product or technology.