A browser-based Bluetooth Low Energy auditing dashboard. Scan nearby devices, monitor signal strength in real time, and explore common BLE security concepts.
Bluetooth Low Energy (BLE) auditing involves scanning, monitoring, and analyzing BLE communications to identify security weaknesses. Unlike classic Bluetooth, BLE is designed for low-power devices that broadcast small packets continuously. These advertisements contain device identifiers, service UUIDs, and manufacturer data - all visible to anyone with a BLE scanner. An auditor uses these signals to map device behavior and test for vulnerabilities.
A BLE device advertises itself with a name and set of service UUIDs that any receiver can read. An attacker can capture these identifiers and retransmit them from a different device, impersonating a legitimate beacon, sensor, or peripheral. This is used to trick mobile apps into connecting to a malicious device, granting the attacker access to data or control paths that should be restricted to authenticated hardware.
BLE operates in the 2.4 GHz ISM band alongside Wi-Fi and ZigBee. An attacker can flood the channel with fake advertisement packets, overwhelming receivers and drowning out legitimate devices. This denial-of-service tactic disrupts BLE-dependent systems - from proximity-triggered locks and asset trackers to medical monitors. Mitigation involves implementing RSSI filtering, MAC whitelisting, and connection-based handshakes rather than trusting advertisement payloads alone.
BLE uses 40 RF channels (37 data, 3 advertising). Dedicated hardware sniffers like the Ubertooth One or Nordic nRF52840 DK can capture all BLE traffic in range. Even without specialized gear, the Web Bluetooth API and common BLE dongles let an auditor observe advertisement payloads. Sensitive data sent in advertisements - such as unlock tokens, health metrics, or location pings - can be collected passively if not encrypted at the application layer.
BLE pairing establishes a shared secret between two devices using the Secure Connections protocol. In older devices using LE Legacy Pairing with Just Works mode, the pairing process produces an encryption key that can be derived by any device that observes the exchange (a man-in-the-middle attack). Modern BLE 4.2+ devices use LE Secure Connections with Elliptic Curve Diffie-Hellman (ECDH) key exchange, which resists passive eavesdropping but remains vulnerable to active MITM when Passkey Entry or Numeric Comparison is not enforced.
For developers building BLE products: always use LE Secure Connections with MITM protection enabled. Encrypt all application-layer data even over encrypted links. Never transmit sensitive data in advertisement packets. Implement MAC address randomization and rotation. Use connection-based communication for any operation that changes device state. Validate all incoming data from a connected peer before acting on it. For auditors: capture advertisement and connection traffic separately, cross-reference observed UUIDs against the Bluetooth SIG database, and test for downgrade attacks.