What a BLE Sniffer Can See About Your Device and How to Stop It

How attackers use BLE sniffers to capture advertising data and track devices

A $30 USB dongle sitting three desks away can log every Bluetooth Low Energy advertisement in the room. Make, model, firmware era, probable owner. No pairing, no proximity trick, no exploit. The device was designed to broadcast this information, and the sniffer was designed to catch it.

Most vendor marketing stops at “BLE is encrypted” or “frequency hopping makes it hard to intercept.” Encryption doesn’t apply to advertising. Frequency hopping is trivial to follow with tools built for the job.

What follows is a map of what a passive attacker actually sees, where the pairing window opens a much larger door, and which defenses are worth asking procurement to enforce.

The BLE Sniffer Threat Spectrum

The toolchain is mature and cheap. An nRF52840 dongle running Nordic’s nRF Sniffer firmware costs under $30. Sniffle, maintained by Sultan Qasim Khan, runs on TI CC26x2 hardware and tracks connections across channel hops. Ubertooth One is older but still useful. All of them pipe into Wireshark’s BTLE dissector, so the analysis workflow is already familiar to anyone who’s done Wi-Fi forensics.

Here’s the practical capability map:

+-------------------------+----------------------+-------------------+
| Attack Class            | Sniffer Capability   | Difficulty        |
+-------------------------+----------------------+-------------------+
| Advertising capture     | Trivial, passive     | Very Low          |
| Device fingerprinting   | Passive, reliable    | Low               |
| MAC-based tracking      | Passive (if static)  | Low               |
| Connection following    | Channel hop tracking | Medium            |
| Legacy pairing crack    | Capture + crackle    | Low-Medium        |
| LESC pairing attack     | Requires active MITM | High              |
| Post-pairing decryption | Only w/ captured LTK | Depends on pairing|
+-------------------------+----------------------+-------------------+

Two rows do most of the damage in real deployments: passive advertising capture (which never touches crypto) and Legacy pairing capture (which defeats it offline). Those are the deep dives worth your time.

Deep Dive #1: What Passive Advertising Capture Reveals

Advertising packets are broadcast in the clear. No encryption layer, no authentication, no handshake. That’s the design, not a flaw, because peripherals need to be discoverable before anyone’s paired with them. The question is how much a well-formed advertisement gives away.

[ Preamble | Access Addr | PDU Header | AdvA (MAC) | AdvData ]
                                         |           |
                                         |           +-- Flags, UUIDs,
                                         |               Name, MfrData
                                         +-- Often static =
                                             tracking primitive

Identity leakage. The Complete Local Name field often carries the device model verbatim, sometimes with user-set strings like “John’s AirPods.” Manufacturer-specific data (identified by Company ID) reveals the vendor and, frequently, a product line and firmware generation. Service UUIDs announce which GATT services the device exposes, which narrows the model further. A researcher with a small fingerprint database can identify most consumer BLE devices in seconds.

Behavioral leakage. Advertising intervals shift with device state. A fitness tracker idle in a drawer advertises on a different cadence than one being worn. Presence and absence over time maps occupancy patterns for any badge, wearable, or asset tag. None of this requires decrypting anything.

MAC address reality. The advertiser address (AdvA) comes in several flavors: Public, Random Static, Non-Resolvable Random, and Resolvable Private (RPA). Only RPA rotates in a way that defeats trivial tracking. Plenty of products marketed as privacy-preserving actually ship with Random Static addresses burned in at manufacture. Those never change for the life of the device.

Even genuine RPA isn’t bulletproof. Becker et al. (PETS 2019) showed that a device can leak a stable identifier elsewhere. Think of a serial-number-derived value in manufacturer data, or a device-specific GATT characteristic. An attacker correlates across address rotations using that payload. The RPA rotates, but the payload gives you away anyway.

Most practical BLE privacy weakness lives here, in choices about what gets put in the advertising payload and which address type the stack is configured to use, not in broken crypto. If you’re designing payloads, the advertising packet structure reference is a useful starting point for what fields carry what.

Deep Dive #2: The Pairing Window and Key Capture

Pairing is the single highest-value window in a BLE device’s life. If advertising is a steady drip, pairing is the flood. Every device goes through it, usually once, and a sniffer that catches those few seconds of exchange can own the relationship forever.

Central  ---- Pairing Request ---->  Peripheral
Central  <--- Pairing Response ----  Peripheral
Central  ---- Confirm/Random ---->   Peripheral     <-- Sniffer
                                                        logs all
             [ Legacy: LTK derivable ]                  frames
             [ LESC:   ECDH opaque  ]

Legacy Pairing (pre-4.2). The Temporary Key is either 0 (Just Works), a 6-digit PIN, or derived from Out-of-Band data. With a captured pairing exchange, Mike Ryan’s crackle tool brute-forces the TK in seconds on a laptop and derives the Long Term Key. That LTK decrypts every future session between those two devices, offline, forever.

LE Secure Connections (4.2+). LESC replaces the TK scheme with ECDH over curve P-256. A passive sniffer sees the public keys and nothing useful. Breaking it requires an active man-in-the-middle during pairing, which is a different, harder attack with a narrower window.

The catch is fallback. Many stacks still advertise Legacy support for backward compatibility. A central that accepts Legacy on an LESC-capable peripheral gets a Legacy-grade key, and the sniffer gets everything it needs. Downgrade attacks against mixed-mode peripherals are a known attack class. They often succeed because someone left the compatibility switch flipped for devices that no longer exist in the field.

The persistence problem compounds this. Once an LTK is compromised, the only fix is re-pairing. Plenty of products pair once at manufacture or during first-use provisioning, then bond for the device’s lifetime. A single captured pairing event can own that device until it’s physically decommissioned.

Procurement question number one for any BLE device should be whether it enforces LESC and refuses Legacy fallback. A vendor that answers “it supports LESC” is answering a different question than the one you asked.

Defenses That Actually Work

Organized by who owns the decision.

IT decision-makers and procurement. Write LESC enforcement into RFPs, with explicit rejection of Legacy fallback. Require documented RPA rotation intervals and a list of every stable identifier in advertising and GATT payloads. Audit advertising payloads before a device is deployed at scale, because “we’ll patch it in firmware later” assumes a firmware update path that plenty of embedded products don’t actually have.

Security teams. Add BLE sniffer sweeps to physical security assessments the same way you walk RF surveys for rogue Wi-Fi. Build a BLE inventory with the same rigor you apply to SSID tracking. In sensitive zones, monitor for unexpected advertisements, especially ones impersonating known device classes.

Product evaluators. Pair the device under test, capture the exchange with Sniffle and Wireshark, then run crackle against the capture. If it recovers an LTK, the product fails. This is a 20-minute test and it filters out a surprising number of shipping products.

A few things that sound like defenses but aren’t. Frequency hopping was never a confidentiality mechanism; sniffers follow the hop sequence by design. “Short range” is a directional-antenna problem, and a decent Yagi pushes practical capture range past 100 meters. Disabling discoverability helps against casual scans but doesn’t stop connection-oriented advertising on many stacks, and it does nothing once a connection is established.

Every mitigation lives at the design-and-configuration layer, not the crypto layer. The crypto is fine when it’s enabled correctly, and it usually isn’t.

Lock the Choices Before the Device Ships

Treat the sniffer as a diagnostic, not a weapon. What it reveals about a BLE device was decided months earlier by firmware engineers and product managers choosing an address type, a pairing mode, and an advertising payload. By the time a device is in the field, those choices are locked in, and the sniffer just reads them back. The procurement checklist is doing more work than any runtime defense.