Wireless Hacking Unleashed: Six Surfaces Your AppSec Program Is Probably Missing

An unauthenticated attacker doesn't always need a CVE. Sometimes they just need a Wi-Fi adapter that supports monitor mode and 90 seconds of unsupervised time near your office. Sometimes a $30 BLE dongle. Sometimes an HackRF and a YouTube tutorial. Wireless protocols sit at the foot of the stack — below TLS, below your WAF, below your SIEM — and the moment your product ships with a radio in it, you have inherited a threat model that AppSec teams are usually not equipped to reason about.

This post is an opinionated tour of the six wireless surfaces every team building connected products has to think about: Wi-Fi, Bluetooth Classic, BLE, sub-GHz RF, NFC / RFID and the IoT transports that ride on top (Zigbee, MQTT, CoAP, LoRa). For each surface we cover the dominant threats, the famous attacks worth knowing by name, and — importantly for an AppSec audience — what static analysis on the source you already have in git can actually catch.

The mental model: six surfaces

"Wireless" is a category, not a protocol. The threat models for each surface are different enough that bundling them together is how vulnerabilities get missed. Keep them separate:

Wi-Fi: still where most teams fail

WPA2-PSK won the standards war and then everyone stopped paying attention. But the configuration surface is wide and the failure modes are durable:

• WEP / WPA-TKIP still on — usually as a "compatibility" SSID for that one 2008 Wi-Fi printer that nobody wants to replace. WEP is broken in seconds, WPA-TKIP is a downgrade attack waiting to happen.
• WPS still enabled — even on routers shipped in 2024. Pixie Dust recovers the WPS PIN offline in seconds for vulnerable chipsets, Reaver does it online in hours for the rest.
• Hardcoded SSID + PSK in firmware — the classic build constant in an ESP-IDF project, an Arduino sketch or a custom Linux image. Once the firmware leaks, the corporate Wi-Fi is in the wild.
• Open SSIDs in production builds — a "factory mode" SSID that was supposed to be disabled, still enabled at first boot.
• Protected Management Frames (PMF / 802.11w) off — deauthentication frames are unauthenticated by default. PMF has been a "should" since 2009 and a "must" for WPA3. It is still off in a surprising number of fleets.

#define WIFI_SSID  "AcmeCorp-Internal"
#define WIFI_PSK   "summer2024"
wifi_config_t cfg = {
    .sta = { .ssid = WIFI_SSID, .password = WIFI_PSK,
             .threshold.authmode = WIFI_AUTH_WPA_PSK }, // accepts TKIP
};

Three problems on six lines: the SSID is leaking your tenant's name, the PSK is in the firmware, and the auth mode accepts WPA — meaning a rogue AP can downgrade clients to TKIP. Static analysis catches all three without ever touching a radio.

Bluetooth Classic: legacy pairing is still alive

Bluetooth 2.1 (2007) introduced Secure Simple Pairing (SSP) and made it mandatory. And yet nineteen years later, a depressing number of devices — especially industrial sensors, medical peripherals and old IoT gateways — still pair with a 4-digit PIN. With KNOB (CVE-2019-9506), an attacker can negotiate the encryption key down to 1 byte of entropy and brute-force it in milliseconds. Static giveaways:

• Default PINs — 0000, 1111, 1234, 123456 hardcoded in setup code.
• Legacy pairing — BTM_PIN_TYPE_FIXED, code paths that do not call SSP equivalents.
• Permanent discoverable — a device that calls setDiscoverable(0, ...) with no timeout is broadcasting its identity forever.
• Reused link keys — same key across the entire fleet, baked into the firmware image.

BLE: the protocol that made Just Works famous

BLE pairing has six modes, and the choice matters. The static analysis question is: which one are we picking, and is it appropriate for the data we handle?

• Just Works — no MitM protection. Fine for a temperature sensor. Catastrophic for a smart lock.
• NoInputNoOutput — declares the peripheral has no UI for pairing — which forces Just Works. Almost always wrong on devices that actually have a UI.
• DisplayOnly / DisplayYesNo / KeyboardDisplay — can do passkey entry and numeric comparison.
• OOB — out-of-band. The most secure but the least common.

Two more BLE static tells worth automating:

• LE Secure Connections (LESC) disabled — the BLE 4.2+ replacement for the original 4.0 pairing. If your BLE stack initialisation does not enable LESC, you are accepting legacy pairing, full stop.
• GATT characteristics without encryption / authentication — a characteristic configured with BLE_GATT_CHR_F_READ but no _ENC / _AUTHEN flag is readable by any nearby device. For anything but a public service, that is a finding.

Sub-GHz RF: the wild west

Sub-GHz is where AppSec instincts fail hardest, because there is no SDK to scan. But there is still source code:

• Fixed-code remotes — a const uint32_t REMOTE_CODE = 0x... in source means an attacker with an RTL-SDR captures it once and replays forever.
• Hardcoded ISM frequencies — setFrequency(433.92e6) on its own isn't a vulnerability, but combined with the above it tells the attacker exactly where to listen.
• Plain LoRa without LoRaWAN — LoRa is a physical layer; LoRaWAN is what gives you AES-128 with NwkSKey / AppSKey separation. Direct LoRa packets are clear-text on the air.

NFC / RFID: short range is not security

"It's only 10cm" is not a threat-model argument, especially in 2026 when NFC-relay attacks over the internet are a stable hobby project. The static analysis pattern most worth flagging is MIFARE Classic still in production. Crypto1, the cipher MIFARE Classic uses, was broken academically in 2008 and weaponised in commodity tools like Proxmark3 and Flipper Zero. Any source that still references MIFARE_CLASSIC, FFFFFFFFFFFF default keys, or builds against MIFARE Classic UIDs as the only authorisation factor is a finding.

IoT transports: where the blast radius lives

Wi-Fi gets you onto the network. Bluetooth gets you near a peripheral. But the application-level damage on connected devices is usually done over IoT transports:

• Zigbee with the default trust-centre key — ZigBeeAlliance09 is a public string. Any product that does not provision a unique TC key during commissioning is broadcasting its network in clear.
• MQTT without TLS — mqtt://broker:1883 is plaintext. The fact that we still see this in production firmware in 2026 is shameful but reliable.
• CoAP without DTLS — CoAP / RFC 7252 has the equivalent of HTTPS in DTLS. Static analysis flags coap:// URIs and coap.NewClient() without the secure variant.
• ESP-IDF Wi-Fi credentials in menuconfig — CONFIG_ESP_WIFI_SSID and CONFIG_ESP_WIFI_PASSWORD defaults end up baked into sdkconfig and shipped with the build.

What an AppSec scanner can actually do here

You will not catch a KNOB attack with a static scanner. You will not detect a rogue AP from source. But you can — reliably and at zero radio cost — catch the configuration mistakes that make those attacks trivial. SF365 ships a dedicated WirelessScanner as the 12th engine in its orchestrator, with 18 detection rules across the six surfaces above:

• Wi-Fi: WEP/WPA-TKIP, WPS, hardcoded SSID+PSK, open SSIDs (5 rules)
• Bluetooth Classic: default PINs, legacy pairing, permanent discoverable (3 rules)
• BLE: Just Works, NoInputNoOutput, LESC off, GATT without encryption, hardcoded passkey/bonding key (5 rules)
• RF: fixed-code, hardcoded ISM frequencies, plain LoRa (3 rules)
• NFC: MIFARE Classic, UID-only authorisation (2 rules)
• IoT: default Zigbee TC key, plain MQTT, CoAP without DTLS (3 rules)

And alongside the engine, the SF365 SecretScanner ships 10 IoT/wireless cloud secret patterns that the AppSec scanners you already own do not have: Azure IoT Hub Device SAS, AWS IoT MQTT endpoints, GCP IoT device JWTs, Particle.io tokens, Tuya cloud secrets, SmartThings PATs, HomeKit setup codes, MQTT URLs with embedded credentials, and ESP-IDF Wi-Fi credential defines.

Compliance: the missing baseline

Each surface has authoritative guidance — NIST SP 800-153 for Wi-Fi, NIST SP 800-121 Rev 2 for Bluetooth, NIST SP 800-97 for 802.1X/EAP, IEEE 802.11i for WPA2 cryptographic constructions — but no one publishes a single auditable framework that stitches them together for a connected-device program. SF365 ships one: a 24-control Wireless Security Baseline covering WIFI.01–07, BT.01–08, RF.01–03, NFC.01–02, and IOT.01–04, exportable as a PDF with per-control evidence.

Where to start tomorrow

1. Inventory which radios your products actually use. Half the teams who think they "ship Wi-Fi" also ship BLE for commissioning and forgot.
2. For each surface, agree on which threats are in scope and which are accepted risk. "We accept Just Works for non-sensitive characteristics" is a position; "we don't know" is not.
3. Add static checks to CI for the failure modes above. Most are exact strings or shallow regex matches.
4. Adopt a baseline (the SF365 24-control set, or your own). The point is to make the answer to "are we OK on Wi-Fi?" auditable rather than vibes-based.
5. Run a benchmark against a known-vulnerable target like IoT-Goat, DVRF or BLE CTF so you can prove the detections fire.