Bluetooth Exploitation (BlueBorne): No Pairing Needed, No Interaction Required

Bluetooth was designed as a cable replacement — a short-range, low-power protocol for connecting peripherals. Security was something of an afterthought. The protocol’s authentication model assumed that physical proximity implied trust. Pairing, in early versions, was little more than a shared PIN exchanged between devices.

The BlueBorne vulnerability cluster, disclosed by Armis Security in September 2017, shattered that proximity-as-trust assumption. BlueBorne proved that an attacker could achieve remote code execution on a Bluetooth-enabled device — Android phone, Linux server, Windows laptop, IoT device — without the device being discoverable, without any user interaction, and without any prior pairing. The attacker needed only a Bluetooth adapter and proximity.

With approximately 5.3 billion devices exposed at disclosure, BlueBorne remains one of the most significant wireless vulnerability disclosures in history. And the vulnerabilities it represented — flaws in the lowest layers of Bluetooth protocol implementation — have continued to appear in subsequent research: BIAS (2020), BLESA (2020), and BrakTooth (2021).

This post covers how Bluetooth discovery works without pairing, the BlueBorne attack chain, Bluetooth enumeration techniques, BLE sniffing, subsequent vulnerability clusters, detection approaches, and enterprise defense controls.

How Bluetooth Discovery Works (Without Pairing)

Understanding the attack requires understanding the Bluetooth discovery model.

Classic Bluetooth (BR/EDR) Inquiry Process

Bluetooth Classic uses an inquiry procedure to discover nearby devices:

1. An inquiring device sends an inquiry packet on a set of frequencies.
2. Discoverable devices respond with their 48-bit device address (BD_ADDR), device class, and clock offset.
3. Non-discoverable devices do not respond to general inquiries but will respond to directed inquiries — inquiries specifically targeting their known BD_ADDR.

This distinction matters: if an attacker already knows the BD_ADDR of a non-discoverable device (obtained from prior passive observation, OSINT, or by scanning the address space), they can probe it directly even when it is not in discoverable mode.

Once a device address is known, the attacker can attempt to connect at the L2CAP (Logical Link Control and Adaptation Protocol) layer — the layer at which BlueBorne’s most severe vulnerabilities existed — without completing the pairing process.

Bluetooth Low Energy (BLE) Advertisement Packets

BLE devices continuously broadcast advertisement packets to announce their presence. These packets contain:

• The device’s BD_ADDR (or a rotating random address)
• Service UUIDs
• Device name (optionally)
• Manufacturer-specific data

These packets are broadcast continuously and passively capturable with a BLE sniffer regardless of any “pairing” or “discoverable” settings. BLE was not designed with privacy as a primary concern — random address rotation was added later and is not universally implemented.

The BlueBorne Vulnerability Cluster

Armis disclosed eight related CVEs in September 2017, affecting four major platforms:

CVE-2017-0781: Android L2CAP Buffer Overflow

The Android RCE vulnerability existed in the BNEP (Bluetooth Network Encapsulation Protocol) stack. BNEP allows Bluetooth devices to share network connections. The vulnerability was a heap buffer overflow triggered by sending a malformed BNEP setup connection request packet to a target device. The key technical detail: this connection request could be sent to any Android device with Bluetooth enabled — no pairing, no user interaction, no discoverable mode required. The L2CAP connection itself does not require authentication to initiate.

CVE-2017-1000251: Linux BlueZ L2CAP Stack Overflow

The Linux vulnerability was in the L2CAP configuration response handler. A specially crafted L2CAP configuration response packet with a malformed options field could overflow a stack buffer in the kernel, leading to kernel-level RCE. Since BlueZ runs in the kernel, successful exploitation yielded ring-0 code execution. The attack was demonstrated against Ubuntu and Raspberry Pi devices running unpatched BlueZ.

Bluetooth Enumeration and Attack Preparation

Classic Bluetooth Device Discovery

 1# Bring up the Bluetooth adapter
 2hciconfig hci0 up
 3
 4# Scan for discoverable Bluetooth devices (standard inquiry)
 5hcitool scan
 6# Output: BD_ADDR | Device Name
 7# e.g., 00:1A:7D:DA:71:09   Employee-iPhone
 8
 9# Get detailed info on a specific device
10hcitool info 00:1A:7D:DA:71:09
11
12# Perform a service discovery (SDP) query — works on connected/known devices
13sdptool browse 00:1A:7D:DA:71:09
14# Reveals: service UUIDs, RFCOMM channels, device capabilities
15
16# Scan for devices including non-discoverable (directed inquiry — requires known address)
17hcitool lecc --random 00:1A:7D:DA:71:09
18
19# Full inquiry with timing parameters
20hcitool inq --length=10 --numrsp=20

BLE Passive Sniffing

 1# Install btlejack for BLE passive sniffing
 2# Requires compatible hardware: Ubertooth One, nRF52840 dongle, or similar
 3pip install btlejack
 4
 5# Scan for BLE advertisement packets passively
 6btlejack -s
 7
 8# Output shows device addresses, RSSI, advertisement data:
 9# [ 12:34:56:78:9A:BC ] RSSI: -67 dBm | ADV_IND | Name: "FitBit Sense"
10# [ AA:BB:CC:DD:EE:FF ] RSSI: -45 dBm | ADV_NONCONN_IND | UUID: 0x180F (Battery)
11
12# For HCI-level BLE scanning without Ubertooth:
13hcitool lescan --passive
14# Lists BLE devices broadcasting advertisement packets
15
16# Capture BLE traffic with hcidump
17hcidump -i hci0 -w capture.hcidump

Nmap Bluetooth Scanning

 1# Install nmap with Bluetooth support
 2sudo apt install nmap
 3
 4# Scan for Bluetooth devices and their services
 5# Requires nmap compiled with Bluetooth support
 6sudo nmap -p 1-65535 --script bluetooth-info <bd_addr>
 7
 8# Check if a device is vulnerable to specific Bluetooth services
 9sudo nmap --script=bluetooth-enum <bd_addr>
10
11# Detect Bluetooth adapter in promiscuous/monitoring mode (IDS perspective)
12# An adapter in HCI RAW mode may indicate a sniffing tool in use
13hciconfig -a | grep -A5 "hci[0-9]" | grep -E "(UP|RUNNING|PSCAN|ISCAN|PTYPE)"
14# PSCAN = Page Scan (accepting connections)
15# ISCAN = Inquiry Scan (discoverable)
16# Look for RAW or SNIFF mode indicators

Subsequent Vulnerability Research

BIAS — Bluetooth Impersonation AttackS (2020)

Disclosed in May 2020 by researchers at EPFL, BIAS exploits a flaw in the Bluetooth Classic authentication procedure. During secure connection establishment, the protocol allows one party to downgrade from mutual authentication to single-directional authentication. An attacker who was previously paired with a victim device — or who can spoof the BD_ADDR of a device the victim has paired with — can negotiate a connection that bypasses the expected authentication, impersonating the trusted device.

Impact: Any Bluetooth Classic device using Secure Simple Pairing or LE Secure Connections is potentially affected. The vulnerability was in the specification, meaning it affected devices from virtually all vendors.

BLESA — BLE Spoofing Attacks (2020)

Disclosed in 2020 by Purdue University researchers, BLESA targets the BLE reconnection process. After a BLE device disconnects and reconnects to a previously paired central device, the specification allows (but does not mandate) skipping re-authentication. Many client implementations simply skip it. An attacker can spoof the address of a previously paired BLE peripheral, reconnect to the central device without authentication, and push spoofed data — for example, injecting false readings from a spoofed medical sensor or industrial IoT device.

BrakTooth (2021)

ASSET Research Group at SUTD disclosed BrakTooth in September 2021: 16 vulnerabilities across the Bluetooth Classic stack implementations of 13 chipset vendors, collectively present in over 1,400 commercial products. The vulnerabilities ranged from denial-of-service (crashing headphones, speakers, laptops via malformed LMP packets) to potential RCE on specific chipsets. Espressif ESP32 (widely used in IoT development boards) was among the affected chipsets.

Detection

Bluetooth IDS and RF Monitoring

 1# BlueZ HCI event monitoring — detect new connections and inquiry responses
 2hcidump -i hci0 | grep -E "(> HCI|Connect|Inquiry)"
 3
 4# Monitor for devices making repeated L2CAP connection attempts (scanning behavior)
 5# hcidump output filter for L2CAP connection requests
 6hcidump -i hci0 -l | grep "l2cap.*connect"
 7
 8# Kismet Bluetooth: passive RF monitoring and device tracking
 9# Kismet can run in Bluetooth passive mode detecting all nearby devices
10kismet --no-ncurses --source=hci0
11
12# Check for attached Bluetooth adapters being placed in RAW mode (potential sniffer)
13hciconfig -a | grep -E "RAW|SNIFF"
14
15# Detect btlejack or Ubertooth activity on the local system
16lsusb | grep -E "(Ubertooth|Nordic Semiconductor|1d50:6002)"

Device Inventory for Bluetooth Assets

 1# Enumerate all Bluetooth-enabled interfaces on a Linux system
 2hciconfig -a
 3
 4# List paired Bluetooth devices (potential attack surface)
 5bluetoothctl paired-devices
 6
 7# Check Bluetooth daemon version — ensure it's patched against known CVEs
 8dpkg -l bluez | grep bluez
 9# Compare against patched versions:
10# CVE-2017-1000251 patched in bluez >= 5.46
11# CVE-2022-0204 patched in bluez >= 5.63
12
13# Windows: audit Bluetooth services and paired devices
14Get-PnpDevice -Class Bluetooth | Select-Object Name, Status, DeviceID

Defense and Mitigation Controls

Patch Management (Highest Priority)

 1# Android: ensure monthly security patches applied — BlueBorne patched September 2017 bulletin
 2# Linux: update bluez to latest stable release
 3sudo apt update && sudo apt upgrade bluez
 4
 5# Verify current bluez version
 6bluetoothd --version
 7
 8# Windows: KB4038782 and subsequent patches address CVE-2017-8628
 9# Verify via Windows Update history or:
10Get-HotFix -Id KB4038782

MDM-Enforced Bluetooth Policy

For enterprise devices, use MDM (Intune, Jamf, SOTI) to enforce Bluetooth policy:

1<!-- Intune OMA-URI: Disable Bluetooth on Windows devices -->
2<!-- OMA-URI: ./Device/Vendor/MSFT/Policy/Config/Connectivity/AllowBluetooth -->
3<!-- Value: 0 (Disable), 1 (Allow but disable file transfer), 2 (Allow all) -->
4
5<!-- For iOS via Intune/Jamf: Restrictions payload -->
6<key>allowBluetooth</key>
7<false/>
8<!-- or restrict to specific profiles only -->

For Linux servers and embedded systems with no operational Bluetooth requirement:

1# Disable and mask the Bluetooth service
2sudo systemctl disable bluetooth
3sudo systemctl mask bluetooth
4
5# Blacklist the Bluetooth kernel modules
6echo "blacklist bluetooth" | sudo tee /etc/modprobe.d/disable-bluetooth.conf
7echo "blacklist btusb" | sudo tee -a /etc/modprobe.d/disable-bluetooth.conf
8sudo update-initramfs -u

Operational Controls

• Discoverable mode: Keep devices non-discoverable at all times unless actively pairing. Most modern OS implementations default to non-discoverable.
• Physical proximity policies: Prohibit Bluetooth pairing in sensitive areas (server rooms, executive briefing areas, classified zones).
• Bluetooth profile restriction: Use MDM to restrict Bluetooth to required profiles only (e.g., headset for voice calls only) — disabling OBEX file transfer, tethering, and Bluetooth PAN profiles reduces attack surface.
• Bluetooth 5.x security features: Bluetooth 5.0+ includes enhanced privacy (random address rotation by default for BLE), improved key derivation, and stricter authentication options. Ensure BLE device procurement specifies BT 5.0+ compliance with privacy features enabled.

MITRE ATT&CK Mapping

Related Attacks in This Series

• Firmware Rootkit: Malware That Survives Reinstall
• IoT Botnet Mirai: Your Cameras Are DDoSing Someone
• Evil Twin WiFi: Man-in-the-Middle Attack
• Satellite Hacking: The Viasat Ukraine Internet Attack

References

• Armis Security: BlueBorne Technical White Paper (2017)
• CVE-2017-0781 — Android Bluetooth RCE (NVD)
• CVE-2017-1000251 — Linux BlueZ L2CAP Stack Overflow (NVD)
• BIAS: Bluetooth Impersonation AttackS — EPFL (2020)
• BLESA: Spoofing Attacks against Reconnections in BLE — Purdue University (2020)
• BrakTooth: Causing Havoc on Bluetooth Link Manager — SUTD ASSET (2021)
• MITRE ATT&CK: T1011.001 Exfiltration Over Bluetooth
• NIST SP 800-121 Rev 2: Guide to Bluetooth Security