Warmup Guide — Wireless, RF, and IoT Security from First Principles

Zero-to-expert primer for the Wireless/RF/IoT module. It builds the radio attack surface from the ground up: why wireless changes the threat model, the 802.11 security evolution, the 4-way handshake and how WPA2 is cracked, WPA3/SAE and Enterprise/802.1X, rogue APs and evil twins, Bluetooth/BLE pairing, NFC/RFID cloning and relay, and the defensive playbook. Everything is authorized-lab-only and offline — analysis over captured metadata, never live transmission (Phase 00). By the end you can read a wireless survey, judge what's crackable, spot an evil twin, and reason about BLE/NFC.

Table of Contents

Chapter 1: Why Radio Changes the Threat Model

Zero background. Every other phase assumes a wire: to attack you, someone needs a network port, a route, or a foothold. Radio removes that assumption. A wireless signal is broadcast into shared space, so anyone within range can receive it passively (invisibly — no packets sent, nothing logged) and anyone can transmit on the same frequency. The "perimeter" is now a sphere of radio range — a parking lot, the floor above, a drone overhead.

The two consequences that reshape everything:

  • Passive capture is free and undetectable. An attacker can record all your Wi-Fi traffic (encrypted or not) without touching your network. This is why wireless encryption and forward secrecy matter so much: captured ciphertext today must stay safe tomorrow.
  • Identity is tied to a radio you don't control. A device identifies an access point by its name (SSID) and MAC (BSSID) — both trivially forged. An attacker who transmits the same SSID with a stronger signal becomes "the network" to nearby clients (the evil twin, Chapter 5). There's no cable to trust.

Why a defender (or authorized assessor) must learn this. You cannot secure or assess what you can't model. Wireless is a first-class enterprise attack surface — guest networks, IoT devices, badge readers, Bluetooth peripherals — and "it's just Wi-Fi" has cost real breaches.

Misconception to kill now. "Our Wi-Fi is hidden / uses an obscure frequency, so it's safe." Hiding the SSID stops nothing (clients still probe for it, revealing it), and security through frequency obscurity fails to anyone with a $30 software-defined radio. Wireless security comes from cryptography and authentication, not from being hard to find.

Chapter 2: 802.11 and the Wi-Fi Security Evolution

What 802.11 is. The IEEE family of Wi-Fi standards. For security you care about how a client (STA) associates with an access point (AP) and how the link is authenticated and encrypted. Frames come in three types: management (beacons, association, deauthentication — historically unauthenticated), control, and data.

The evolution — each step fixed the previous disaster:

  • WEP (Wired Equivalent Privacy). The original — broken beyond repair. A tiny 24-bit IV reused constantly and an RC4 flaw let the key be recovered from captured traffic in minutes. If you ever see WEP, it is effectively open.
  • WPA / WPA2 (with TKIP or CCMP/AES). WPA2-CCMP (AES) is the long-time baseline. Two modes: Personal (PSK) — everyone shares one passphrase — and Enterprise (802.1X) — each user authenticates individually (Chapter 4). WPA2-PSK's weakness is the offline-crackable handshake (Chapter 3). TKIP is legacy and weak; CCMP/AES is the floor.
  • WPA3. The current standard. Replaces the PSK handshake with SAE (Simultaneous Authentication of Equals — a password-authenticated key exchange) that resists offline cracking and adds forward secrecy, and mandates management-frame protection (802.11w) to stop deauth attacks (Chapter 5).

Misconception to kill now. "WPA2 is fine." WPA2-CCMP is still widely acceptable, but WPA2-PSK with a weak passphrase is offline-crackable from a single captured handshake, and WPA2 lacks mandatory management-frame protection. WPA3/SAE is the answer; WEP and TKIP are non-negotiable removals.

Chapter 3: The 4-Way Handshake and How WPA2 Is Cracked

The mechanism. In WPA2-PSK, the AP and client both already know the passphrase; the 4-way handshake is how they prove it and derive fresh per-session keys without sending the passphrase. From the passphrase (and SSID) both sides compute the PMK (Pairwise Master Key); the handshake exchanges nonces and derives the PTK (Pairwise Transient Key) for the session, and a MIC (message integrity code) proves each side holds the PMK.

Why it's crackable (the key insight). An eavesdropper who captures the handshake has everything needed to verify a guess offline: they take a candidate passphrase, derive the PMK, derive the PTK with the captured nonces, compute the MIC, and check it against the captured MIC. No interaction with the network is needed — it's a pure offline dictionary/brute-force attack, GPU-accelerated. So WPA2-PSK security = passphrase strength. A weak or common passphrase falls in seconds; a long random one is infeasible.

  • Getting the handshake. Wait for a client to join, or send a forged deauthentication frame (WPA2 management frames are unauthenticated) to kick a client off so it reconnects and you capture the handshake (Chapter 5).
  • PMKID attack. Some APs leak a PMKID in the first handshake message, letting an attacker derive the same offline-crackable material from the AP alone — no client needed.

The defense. A long, high-entropy passphrase makes offline cracking infeasible; better, move to WPA3-SAE, whose handshake is not offline-crackable (each guess requires a fresh online interaction the AP can rate-limit), or Enterprise 802.1X (no shared passphrase at all).

Misconception to kill now. "They'd have to break AES." They don't — they capture the handshake and brute-force the passphrase offline. The cipher is fine; the shared human-chosen secret is the weak link.

Chapter 4: WPA3, SAE, and Enterprise 802.1X

WPA3-SAE (Personal). SAE is a password-authenticated key exchange (a "dragonfly" handshake): both sides prove knowledge of the passphrase through an interactive exchange that yields no offline- crackable artifact and provides forward secrecy (a later passphrase compromise doesn't decrypt past captures). An attacker must guess online, against an AP that can throttle — turning an offline GPU attack into an infeasible online one. (The early "Dragonblood" side-channel/downgrade bugs were patched; transition modes that allow WPA2 fallback reintroduce risk.)

Enterprise / 802.1X (the right answer for organizations). Instead of a shared passphrase, each user/device authenticates individually to a RADIUS server via EAP (Extensible Authentication Protocol). The robust variant is EAP-TLS — mutual certificate authentication, no password to phish or crack. The components: the supplicant (client), the authenticator (AP/ switch), and the authentication server (RADIUS). Benefits: per-user keys and revocation, no shared secret, and integration with your identity provider (Phase 02/05).

The classic Enterprise pitfall. If clients don't validate the RADIUS server's certificate, an attacker stands up a rogue AP + rogue RADIUS (an "evil twin" for Enterprise) and harvests the EAP credentials (e.g., MSCHAPv2 hashes to crack). The defense is server-certificate validation pinned to your CA on every client — the wireless echo of Phase 02's "validate the cert, not just the name."

Misconception to kill now. "Enterprise Wi-Fi is automatically secure." Only if clients validate the server certificate; a misconfigured supplicant trusts any RADIUS server and leaks credentials to a rogue one. Configuration, not the protocol name, is the control.

Chapter 5: Rogue APs, Evil Twins, and Deauthentication

Rogue AP. Any unauthorized access point on (or impersonating) your network — a malicious one an attacker plants, or a careless employee's personal router bridged to the corporate LAN (a backdoor around all your wired controls).

Evil twin. An attacker AP that clones a legitimate network's SSID (and often BSSID) and broadcasts a stronger signal, so nearby clients — which auto-connect to the "best" known network — associate with the attacker. Now the attacker is the client's gateway: they can capture traffic, run a captive-portal phishing page, or (for Enterprise) harvest EAP credentials. The defining lesson: a matching SSID proves nothing — SSID/BSSID are forgeable, so "the right name and a strong signal" is exactly what an attacker presents.

Deauthentication attack. Because WPA2 management frames are unauthenticated, an attacker can spoof a deauth frame to disconnect a client — to cause a denial of service, or to force a reconnect so they can (a) capture the 4-way handshake (Chapter 3) or (b) push the client onto their evil twin. 802.11w (management-frame protection), mandatory in WPA3, cryptographically protects these frames and shuts the attack down.

Detection (the defender's job, and Lab 01). A Wireless IDS spots evil twins and rogue APs by the contradictions: the same SSID on an unexpected BSSID/vendor, a known SSID suddenly on a different channel or with a much stronger RSSI, a BSSID not in your approved inventory, or an open clone of a secured network. You build exactly this classifier in Lab 01.

Misconception to kill now. "My phone connected to our network name, so it's our network." Your phone connected to the strongest radio claiming that name. Without server-certificate validation (Enterprise) or WPA3, that can be an evil twin.

Chapter 6: Bluetooth and BLE

What it is. Bluetooth Classic (BR/EDR) and Bluetooth Low Energy (BLE) are short-range radio for peripherals and IoT. BLE dominates modern devices (wearables, locks, medical, beacons). Two security questions matter: how devices pair (establish keys) and how they're identified.

Pairing methods — the security hinges here:

  • Just Works — pairing with no user verification. It encrypts the link but provides no MITM protection: an attacker present during pairing can interpose. Ubiquitous in cheap IoT because it needs no display/keypad — and a frequent finding.
  • Passkey Entry — a 6-digit code shown on one device, entered on the other: MITM resistance if the passkey is random and not reused.
  • Numeric Comparison (Secure Connections / LE Secure Connections) — both devices show a number the user confirms; the strongest, using ECDH so a passive eavesdropper can't derive the key.

Other BLE issues. Static or predictable MAC addresses enable tracking (mitigated by MAC randomization); legacy pairing's weak key derivation; sniffing during pairing; and the perennial default credentials / no authentication on the application layer (a BLE lock that opens for any phone that speaks its protocol). Bluetooth has also had implementation-bug families (e.g., BlueBorne, KNOB key-negotiation downgrade) — patch currency matters.

Misconception to kill now. "It's paired, so it's secure." Just Works pairing encrypts but does not authenticate — an attacker can MITM the pairing — and many devices add no application-layer auth on top, so "paired" can mean "anyone nearby can drive it."

Chapter 7: NFC, RFID, and Relay Attacks

What they are. RFID (radio-frequency identification) and NFC (near-field communication, a short-range RFID subset) power badges, transit cards, payment, and tags. Security depends entirely on whether the tag does cryptographic challenge-response or just presents a static identifier.

The attacks:

  • Cloning. A tag that emits a fixed ID (older 125 kHz badges, MIFARE Classic with its broken Crypto1 cipher) can be read and copied to a blank — an attacker brushes past your badge with a pocket reader and walks in. Secure tags (DESFire, modern e-passports, EMV cards) use a secret key in challenge-response that never leaves the chip, so the response can't be replayed.
  • Relay attack. Even a cryptographically sound contactless system can be defeated by relaying the radio exchange in real time: one attacker's device near the victim's card, another near the reader, tunneling the challenge/response over the internet so the reader thinks the card is present. The defense is distance bounding (measuring round-trip time so a far-away card is rejected) and requiring user intent (tap-to-confirm, on-device biometric).

Misconception to kill now. "Our badges are RFID, so they're secure." A static-ID badge is a password you broadcast to anyone with a reader. Security requires challenge-response with a key the tag never reveals — and even then, relay attacks need distance bounding.

Chapter 8: IoT and the Broader RF Surface

Why IoT concentrates wireless risk. IoT devices are cheap, long-lived, rarely patched, and often ship with default credentials, no secure update (OTA) mechanism, unauthenticated local protocols, and hardcoded keys (Phase 13). They speak Wi-Fi, BLE, Zigbee/Z-Wave (mesh home/ building automation), LoRa (long-range), and proprietary sub-GHz RF (garage doors, sensors, car key fobs). Many sub-GHz remotes use static codes or weak rolling codes that are replayable or roll-jam-able with a software-defined radio.

The IoT security checklist (what an assessor looks for): unique per-device credentials (no shared defaults), authenticated + signed OTA updates with anti-rollback (Phase 13), encrypted + authenticated radio links (not Just Works / static codes), no hardcoded secrets, a documented patch lifecycle, and — critically at the architecture level — network segmentation so a compromised camera can't reach the rest of the network (Phase 06/07).

Misconception to kill now. "It's just a sensor / a lightbulb." A foothold device with weak RF and no segmentation is a pivot into the whole network (Chapter 7 of the Offensive module) and a botnet recruit (Mirai). The cheapest device sets your wireless security floor.

Chapter 9: The Wireless Defensive Playbook

Pulling it together — the controls, mapped to the mechanisms they fix:

  • Use WPA3-SAE (or strong WPA2-CCMP with a long random passphrase as a floor); never WEP or TKIP. For organizations, Enterprise 802.1X with EAP-TLS and enforced server-certificate validation on every client.
  • Mandate 802.11w (management-frame protection) to kill deauth/evil-twin forcing.
  • Run a Wireless IDS/IPS to detect rogue APs and evil twins against an approved BSSID inventory (Lab 01), and physically locate them.
  • Segment guest, corporate, and IoT onto separate VLANs/networks with least-privilege routing (Phase 06/07); a guest or IoT device must not reach corporate systems.
  • BLE/NFC: require Secure Connections (Numeric Comparison) pairing, application-layer authentication, challenge-response (not static-ID) tags, and distance bounding for high-value contactless.
  • IoT: unique credentials, signed OTA + anti-rollback (Phase 13), and an inventory + patch lifecycle.

Misconception to kill now. "We set a Wi-Fi password, so wireless is handled." A passphrase is one control on one link type. The wireless surface is APs (rogue/evil-twin), management frames, Bluetooth, NFC badges, and dozens of unpatched IoT radios — each needs its own control, and segmentation is what limits the blast radius when one fails.

Lab Walkthrough Guidance

Two labs turn the radio surface into runnable analysis (all synthetic/offline):

  1. Lab 01 — Wireless Survey Analyzer. From a scan (SSID/BSSID/vendor/security/channel/RSSI), classify each AP's posture (open/WEP/WPA2-PSK/WPA3/Enterprise), rate handshake crackability, and detect rogue/evil-twin APs against an approved inventory (Chapters 2–5).
  2. Lab 02 — BLE/IoT Posture Evaluator. From device metadata (BLE pairing method, app-layer auth, default creds, OTA support, tag type), flag the weaknesses — Just Works, static-ID tags, default credentials, no signed OTA — with severity (Chapters 6–8).
LAB_MODULE=solution pytest -q   # reference (passes)
pytest -q                        # your implementation after the TODOs

Success Criteria

You have internalized this module when you can, without notes:

  1. Explain why radio removes the wired perimeter and makes passive capture free.
  2. Explain the 4-way handshake and why WPA2-PSK is offline-crackable (and PMKID), versus WPA3-SAE.
  3. Explain Enterprise 802.1X/EAP-TLS and the server-certificate-validation pitfall.
  4. Detect an evil twin and explain why a matching SSID proves nothing.
  5. Compare BLE Just Works / Passkey / Numeric Comparison and the MITM implications.
  6. Explain RFID/NFC cloning vs. relay attacks and their defenses.
  7. Give the wireless defensive playbook and why IoT segmentation is the blast-radius control.

Common Mistakes

  • Treating a hidden SSID or an obscure frequency as a security control.
  • Running WEP/TKIP, or WPA2-PSK with a weak passphrase (offline-crackable from one handshake).
  • Deploying Enterprise Wi-Fi without enforcing RADIUS server-certificate validation on clients.
  • Trusting a network by SSID match (evil twin) or a badge by static RFID ID (cloning).
  • Accepting BLE "Just Works" pairing for anything sensitive; assuming "paired" means "authenticated."
  • Putting IoT on the flat corporate network with default credentials and no signed OTA.

Interview Q&A

Q: How is WPA2-PSK cracked, and how does WPA3 change it? A: An eavesdropper captures the 4-way handshake (waiting for a join or forcing one with a spoofed deauth), then brute-forces offline: for each candidate passphrase, derive the PMK→PTK with the captured nonces, compute the MIC, and compare to the captured MIC — no network interaction, GPU- accelerated, so security equals passphrase entropy (PMKID makes it client-free). WPA3-SAE replaces this with a password-authenticated key exchange that yields no offline-crackable artifact and adds forward secrecy, so guessing must happen online against a rate-limiting AP.

Q: What's an evil twin and how do you detect it? A: A rogue AP cloning a legitimate SSID (often BSSID) with a stronger signal so clients auto-associate to the attacker, who then captures traffic, phishes via captive portal, or harvests Enterprise EAP credentials. A matching SSID proves nothing — names and MACs are forgeable. Detection is contradiction- spotting against an approved inventory: the same SSID on an unexpected BSSID/vendor/channel, an open clone of a secured network, or an anomalous signal — a wireless IDS, plus enforced server-cert validation (Enterprise) and WPA3/802.11w to prevent the forcing.

Q: A client wants BLE locks — what do you check? A: The pairing method (reject Just Works — it encrypts but gives no MITM protection; require LE Secure Connections / Numeric Comparison), application-layer authentication (the lock must authenticate the phone, not just be "paired"), no default/shared keys, MAC randomization to prevent tracking, signed OTA updates, and resistance to relay (proximity/intent confirmation). "Paired" is not "authenticated."

Q: Why isn't an RFID badge secure by default? A: A static-ID tag broadcasts a fixed identifier any reader can capture and clone to a blank — it's a password you transmit on demand. Security needs challenge-response with a key the tag never reveals (DESFire, EMV), and even those need distance bounding to defeat real-time relay attacks.

References

  • IEEE 802.11 (incl. 802.11i security, 802.11w management-frame protection); Wi-Fi Alliance WPA3 / SAE.
  • "Dragonblood" (Vanhoef & Ronen) — WPA3 SAE analysis; KRACK (Vanhoef) — WPA2 handshake reinstallation.
  • Bluetooth Core Spec (LE Secure Connections, pairing); BlueBorne and KNOB attack research.
  • MIFARE Classic / Crypto1 break (Nohl et al.); EMV and NFC relay-attack and distance-bounding research.
  • IoT: OWASP IoT Top 10; the Mirai botnet retrospective; Phase 13 (firmware, OTA, anti-rollback).
  • Phase cross-references: P02 (TLS/identity), P06/P07 (segmentation), P13 (hardware/firmware).