This chapter covers the attack surface of Bluetooth and Bluetooth Low Energy (BLE) technologies, which are critical for the PT0-002 exam under Objective 3.5 (Attacks and Exploits). Approximately 5-10% of exam questions touch on wireless attack vectors, with Bluetooth and BLE being a significant subset. You will learn the underlying mechanisms of Bluetooth discovery, pairing, and communication, and how attackers exploit weaknesses in these processes. Mastery of this topic is essential for identifying vulnerabilities during penetration tests of IoT devices, medical devices, and mobile peripherals.
Jump to a section
Imagine a party with many people using walkie-talkies. Each walkie-talkie has a unique channel number (like a Bluetooth MAC address). To talk, two people must first agree on a channel and a hop pattern (frequency-hopping spread spectrum). One person acts as the host (master), deciding the hopping sequence and timing (clock). The other follows (slave). They exchange a link key (pairing) that encrypts their conversation. Nearby parties on different channels can talk simultaneously without interference because they hop in different patterns. However, an eavesdropper with a scanner can listen if they know the hopping pattern and link key. If a party is careless (e.g., leaves their walkie-talkie in discoverable mode), anyone can see they're there and try to join. Bluetooth Low Energy (BLE) is like a whisper mode: shorter range, lower power, but still discoverable. Attackers can scan for devices, attempt to pair without proper authentication, or jam the channel by transmitting noise on the current hop frequency. The key takeaway: the security of the conversation depends entirely on the strength of the link key and the secrecy of the pairing process.
Overview of Bluetooth and BLE
Bluetooth is a short-range wireless communication standard operating in the 2.4 GHz ISM band. Classic Bluetooth (BR/EDR) supports data rates up to 3 Mbps and is used for streaming audio and file transfer. Bluetooth Low Energy (BLE), introduced in Bluetooth 4.0, is designed for low-power applications like IoT sensors and beacons, with data rates up to 1 Mbps. Both use frequency-hopping spread spectrum (FHSS) to mitigate interference, but their packet structures and security mechanisms differ significantly.
Bluetooth Classic (BR/EDR) Architecture
Piconet: A master device communicates with up to 7 active slaves. The master determines the frequency-hopping sequence and timing (clock). All slaves synchronize to the master's clock.
Inquiry and Paging: Devices discover each other via inquiry (discoverable mode) and connect via paging (paging scan). Inquiry scan windows are typically 11.25 ms every 2.56 seconds. Paging scan windows are 11.25 ms every 1.28 seconds.
Security Modes:
Mode 1: No security (legacy).
Mode 2: Service-level security (authentication after L2CAP channel establishment).
Mode 3: Link-level security (authentication before link setup).
Mode 4: Secure Simple Pairing (SSP) – introduced in Bluetooth 2.1, uses Elliptic Curve Diffie-Hellman (ECDH) for key exchange.
Pairing: The process of establishing shared secret keys. In SSP, four association models exist: Just Works, Numeric Comparison, Passkey Entry, and Out of Band (OOB). Just Works is vulnerable to man-in-the-middle (MITM) because no user verification occurs.
Bluetooth Low Energy (BLE) Architecture
Advertising and Scanning: BLE devices advertise on three primary channels (37, 38, 39) to avoid Wi-Fi interference. Advertisements can contain up to 31 bytes of data. Scanning devices listen for advertisements; passive scanning does not send requests, while active scanning sends scan requests for more data.
Connection: After receiving an advertisement, the master (initiator) sends a connection request specifying a hop interval (7.5 ms to 4 seconds), latency, and timeout. The connection event occurs at each hop interval.
Security: BLE uses AES-128 encryption with a 128-bit LTK (Long Term Key). Pairing can be LE Legacy Pairing (vulnerable to passive eavesdropping if no MITM protection) or LE Secure Connections (based on ECDH, introduced in Bluetooth 4.2). Key distribution includes LTK, IRK (Identity Resolving Key), and CSRK (Connection Signature Resolving Key).
Privacy: BLE supports private addresses that change periodically (e.g., every 15 minutes) to prevent tracking. The IRK allows trusted devices to resolve the identity.
Bluetooth Attack Surface
Bluejacking: Sending unsolicited messages to discoverable devices. Low impact, but demonstrates discoverability.
Bluesnarfing: Unauthorized access to data (contacts, calendar) via OBEX or RFCOMM. Exploits weak or no authentication in legacy pairing.
Bluebugging: Remote control of a device's features (make calls, send texts) using AT commands over RFCOMM. Requires pairing or a known PIN.
BlueBorne: A set of vulnerabilities (CVEs 2017-0781-0785) that allow remote code execution and man-in-the-middle attacks without pairing. Exploits the Bluetooth stack's handling of L2CAP and SDP packets.
KNOB (Key Negotiation of Bluetooth): Attackers downgrade the encryption key length to 1 byte (instead of 16 bytes) during pairing negotiation. Works on BR/EDR and BLE. Patched in Bluetooth 5.1.
BIAS (Bluetooth Impersonation Attack): Exploits the lack of authentication in the secure connection establishment phase. The attacker impersonates a previously paired device to bypass authentication.
Sweatt and Sweatt-tooth: BLE vulnerabilities in the advertising channel where an attacker can spoof advertisements to trigger actions (e.g., unlock a smart lock).
Jamming: Transmitting noise on the 2.4 GHz band or specifically on Bluetooth hop frequencies can disrupt communication. Jamming is a denial-of-service attack.
Eavesdropping: If encryption is not used or keys are weak, an attacker can capture and decrypt packets. With known LTK, an attacker can decrypt all traffic.
Bluetooth Security Mechanisms and Weaknesses
Pairing Models: Just Works is vulnerable to MITM because no user verification occurs. Numeric Comparison requires users to verify a 6-digit number. Passkey Entry requires entering a PIN (6 digits for SSP, up to 128 bits for LE Secure Connections). OOB uses an external channel (e.g., NFC) to exchange keys.
Encryption Key Length: Classic Bluetooth supports encryption key lengths from 1 to 16 bytes. The KNOB attack downgrades this to 1 byte. BLE always uses 128-bit AES.
Authentication: In BR/EDR, authentication is based on a shared link key. The challenge-response mechanism uses a 128-bit random number and the link key to generate a signed response. BLE uses a 128-bit LTK for encryption and authentication.
Privacy: BLE private addresses are resolved using the IRK. If the IRK is compromised, the device can be tracked. Additionally, passive scanning can still observe advertisement payloads even with private addresses.
Bluetooth Scanning and Reconnaissance
Penetration testers use tools like hcitool, bluetoothctl, hciconfig, sdptool, and l2ping on Linux. For BLE, hcitool lescan, gatttool, and bettercap are common.
- Discovering devices: sudo hcitool scan for classic, sudo hcitool lescan for BLE (requires Bluetooth 4.0 adapter).
- Service discovery: sdptool browse <BD_ADDR> lists all services (RFCOMM channels, L2CAP PSMs).
- Pairing: bluetoothctl interactive tool: pair <BD_ADDR>, trust <BD_ADDR>, connect <BD_ADDR>.
- Packet capture: btmon or wireshark with Bluetooth interface.
Exploitation Tools
BlueMaho: GUI tool for classic Bluetooth attacks (bluejacking, bluesnarfing, bluebugging).
Bluetooth Hacking Tools: btscanner, blueranger, redfang (for range detection).
Bettercap: Supports BLE scanning, spoofing, and GATT read/write.
Gatttool: Command-line tool for interacting with BLE GATT services and characteristics.
BLEAH (BLE Attack Helper): Automates discovery, pairing, and exploitation of BLE devices.
Defensive Measures
Disable Bluetooth when not in use.
Use non-discoverable mode for devices that don't need to be found.
Require authentication and encryption for all connections (Security Mode 4 for BR/EDR, LE Secure Connections for BLE).
Keep firmware updated to patch known vulnerabilities (BlueBorne, KNOB, BIAS).
Use Out-of-Band pairing where possible (e.g., NFC) to prevent MITM.
Implement application-layer encryption and authentication beyond Bluetooth security.
For BLE, use random resolvable private addresses and rotate keys regularly.
Device Discovery and Scanning
The attacker first puts their Bluetooth interface in scan mode. For classic Bluetooth, they run `hcitool scan` to discover nearby devices in inquiry scan mode. The attacker listens for inquiry responses containing the device's BD_ADDR and class of device (CoD). For BLE, the attacker runs `hcitool lescan` to listen for advertising packets on channels 37, 38, and 39. The attacker collects advertising data, including the device name, services, and TX power level. This step identifies potential targets and their capabilities.
Service Enumeration via SDP
Using the discovered BD_ADDR, the attacker queries the Service Discovery Protocol (SDP) with `sdptool browse <BD_ADDR>`. This returns a list of RFCOMM channels, L2CAP PSMs, and service names (e.g., OBEX File Transfer, Headset Audio Gateway). The attacker identifies vulnerable services such as OBEX Push (bluesnarfing) or RFCOMM with no authentication. For BLE, the attacker uses `gatttool -b <BD_ADDR> --primary` to enumerate GATT services and characteristics, looking for writable characteristics without authentication.
Pairing Exploitation or Bypass
If the target device is in pairing mode or uses weak pairing (Just Works), the attacker initiates pairing using `bluetoothctl` or custom scripts. In Just Works, the attacker can perform a MITM attack by intercepting the public keys during ECDH exchange (if using SSP) or by forcing a downgrade to legacy pairing. The attacker may also attempt to use a known default PIN (e.g., 0000) or brute-force short PINs (6 digits) using tools like `btcrack`. For BLE, the attacker can attempt to read/write characteristics without pairing if the device does not enforce encryption.
Data Exfiltration or Command Injection
Once paired or connected, the attacker uses RFCOMM channels to access services. For bluesnarfing, the attacker connects to OBEX Push (RFCOMM channel 3) and uses `obexftp` to pull contacts or calendar data. For bluebugging, the attacker sends AT commands over RFCOMM to control the phone (e.g., `ATD<number>` to make calls). For BLE, the attacker writes to a characteristic that controls a device (e.g., unlock a smart lock) or reads sensitive data (e.g., heart rate monitor). The attacker may also exploit buffer overflows (BlueBorne) by sending malformed L2CAP packets.
Persistence and Lateral Movement
After initial access, the attacker may attempt to maintain a connection by storing the link key (pairing) for later reconnection. This is done by trusting the device in `bluetoothctl` (`trust <BD_ADDR>`). The attacker can then reconnect without user interaction. If the target device is a mobile phone, the attacker may use it as a pivot to attack other Bluetooth devices in range. For example, the attacker can pair with a car's hands-free system using the compromised phone's link key. This step is often tested in exam scenarios where the attacker establishes a persistent backdoor via Bluetooth.
Scenario 1: IoT Smart Lock Penetration Test
A penetration tester is hired to assess the security of a BLE-enabled smart lock used in a corporate building. The lock uses BLE advertising to broadcast its presence. The tester uses a Raspberry Pi with a Bluetooth 4.0 dongle and runs hcitool lescan to discover the lock's BD_ADDR. Using gatttool, the tester enumerates GATT services and finds a characteristic for 'lock control' with write permissions but no authentication required. The tester writes a 1-byte value (0x01) to unlock the door. The vulnerability is that the device does not require encryption or pairing for this critical function. The tester recommends enabling LE Secure Connections and requiring authenticated pairing before allowing writes. In production, the lock should also use a random resolvable private address to prevent tracking.
Scenario 2: Medical Device Bluesnarfing
A hospital uses Bluetooth-enabled insulin pumps that communicate with a patient's smartphone app. The pump uses classic Bluetooth with Just Works pairing for convenience. The tester discovers the pump's BD_ADDR via hcitool scan and uses sdptool browse to find an OBEX Push service. Using obexftp -b <BD_ADDR> -p <file>, the tester downloads patient data (blood sugar levels) from the pump's memory. The vulnerability is that the pump allows unauthenticated data transfer after pairing. The tester recommends disabling OBEX Push and using Security Mode 4 with numeric comparison pairing. In production, the pump should also encrypt the data at the application layer.
Scenario 3: BlueBorne Remote Code Execution A corporate environment has many Bluetooth-enabled laptops and smartphones. The tester scans for devices using a custom script that sends malformed L2CAP packets to trigger the BlueBorne vulnerability (CVE-2017-0781). The tester finds a laptop with an unpatched Bluetooth stack and sends a crafted packet that causes a buffer overflow, allowing remote code execution. The tester then installs a backdoor and exfiltrates sensitive files. The mitigation is to apply the security patch from the vendor. In production, the company should disable Bluetooth on devices that don't need it and use a centralized patching system.
The PT0-002 exam under Objective 3.5 tests your ability to identify and exploit Bluetooth and BLE vulnerabilities. Expect 2-3 questions that ask you to select the correct attack type based on a scenario.
Common Wrong Answers and Why Candidates Choose Them: 1. Bluejacking vs. Bluesnarfing: Candidates often confuse sending unsolicited messages (bluejacking) with unauthorized data access (bluesnarfing). The exam will describe a scenario where data is stolen; the answer is bluesnarfing, not bluejacking. 2. KNOB vs. BIAS: Both are key negotiation attacks. KNOB downgrades encryption key length; BIAS bypasses authentication. If the scenario mentions 'downgrading encryption', it's KNOB. If it mentions 'impersonating a previously paired device without authentication', it's BIAS. 3. Just Works vs. Numeric Comparison: Just Works is vulnerable to MITM because no user verification. Numeric Comparison is resistant to MITM because users verify a 6-digit number. The exam may ask which pairing model is most secure against MITM; the answer is Numeric Comparison (or OOB). 4. Classic Bluetooth vs. BLE: BLE uses advertising channels 37, 38, 39; classic uses inquiry/paging. If a question mentions 'advertising', it's BLE. If it mentions 'inquiry', it's classic.
Specific Numbers and Terms: - BLE advertising channels: 37 (2402 MHz), 38 (2426 MHz), 39 (2480 MHz). - BLE connection interval: 7.5 ms to 4 seconds. - Classic Bluetooth piconet: 1 master, up to 7 active slaves. - SSP association models: Just Works, Numeric Comparison, Passkey Entry, OOB. - KNOB encryption key downgrade: 1 byte (8 bits). - BlueBorne CVEs: 2017-0781, 0782, 0783, 0784, 0785.
Edge Cases: - Devices in non-discoverable mode can still be found by brute-forcing BD_ADDRs (though this is slow). - BLE private addresses change, but the IRK can be extracted from a compromised device to track it. - Bluetooth 5.1 introduced Angle of Arrival (AoA) and Angle of Departure (AoD) for location, which can be spoofed.
How to Eliminate Wrong Answers: - Read the scenario carefully: Is data being stolen? (bluesnarfing) Is a device being controlled? (bluebugging) Is encryption being downgraded? (KNOB) Is authentication being bypassed? (BIAS) Is a malformed packet causing RCE? (BlueBorne) - Eliminate answers that don't match the attack vector (e.g., if the attack is passive eavesdropping, it's not jamming).
Bluetooth operates in 2.4 GHz ISM band using frequency-hopping spread spectrum (FHSS) with 79 channels (1 MHz spacing) for BR/EDR and 40 channels (2 MHz spacing) for BLE.
Classic Bluetooth discovery uses inquiry scan (11.25 ms window every 2.56 s) and paging scan (11.25 ms window every 1.28 s).
BLE advertising channels are 37, 38, 39 to avoid Wi-Fi channels 1, 6, 11.
Secure Simple Pairing (SSP) has four association models: Just Works (vulnerable to MITM), Numeric Comparison (MITM-resistant), Passkey Entry, and Out of Band.
KNOB attack (CVE-2019-9506) downgrades encryption key length to 1 byte; affects both BR/EDR and BLE.
BIAS attack (CVE-2020-10135) bypasses authentication in secure connection establishment; works on BR/EDR and BLE.
BlueBorne vulnerabilities (CVE-2017-0781-0785) allow remote code execution without pairing.
Tools: hcitool, bluetoothctl, sdptool, gatttool, bettercap, btmon, Wireshark.
Defenses: disable Bluetooth when not in use, use non-discoverable mode, enable Security Mode 4 or LE Secure Connections, apply patches, use OOB pairing.
BLE privacy uses resolvable private addresses (RPAs) that change periodically; IRK is needed to resolve identity.
These come up on the exam all the time. Here's how to tell them apart.
Classic Bluetooth (BR/EDR)
Data rates up to 3 Mbps (EDR).
Inquiry/paging for discovery.
Piconet: 1 master, up to 7 active slaves.
Security Modes 1-4, with SSP for pairing.
Used for audio streaming, file transfer.
Bluetooth Low Energy (BLE)
Data rates up to 1 Mbps (LE) or 2 Mbps (LE 2M PHY).
Advertising on three channels (37, 38, 39).
Connection interval 7.5 ms to 4 s.
LE Legacy or LE Secure Connections pairing.
Used for IoT sensors, beacons, wearables.
Mistake
Bluetooth is only vulnerable if discoverable mode is on.
Correct
Even in non-discoverable mode, an attacker can brute-force the BD_ADDR (48-bit, but often predictable) or use a sniffer to capture inquiry responses when the device does respond. Also, BLE devices always advertise, even with private addresses; the payload can still reveal the device type.
Mistake
BLE is more secure than Classic Bluetooth because it uses AES-128.
Correct
AES-128 is strong, but BLE's security depends on the pairing model. LE Legacy Pairing is vulnerable to passive eavesdropping if no MITM protection. LE Secure Connections (ECDH) is better, but Just Works still lacks user verification. Also, many BLE devices skip encryption for performance.
Mistake
Just Works pairing is secure because it uses encryption.
Correct
Just Works uses ECDH to establish a shared secret, but there is no user verification of the public keys. An attacker can perform a MITM attack by intercepting the public keys and establishing separate keys with both devices. The encryption is between the attacker and each device, so the attacker can decrypt and re-encrypt all traffic.
Mistake
Bluetooth jamming is illegal and not part of penetration testing.
Correct
Jamming is illegal in most countries due to regulatory restrictions (e.g., FCC). However, the exam may ask about jamming as a denial-of-service attack. In a penetration test, you should not actually jam; you would demonstrate the risk conceptually. The exam expects you to know that jamming disrupts communication by transmitting noise on the 2.4 GHz band.
Mistake
The KNOB attack only works on Classic Bluetooth.
Correct
The KNOB attack (CVE-2019-9506) affects both Classic Bluetooth (BR/EDR) and BLE. It exploits the encryption key length negotiation during pairing. For BLE, the attacker can force the encryption key to be 1 byte (8 bits) instead of 16 bytes (128 bits). The vulnerability was fixed in Bluetooth 5.1.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Bluejacking is the act of sending unsolicited messages (vCards) to a Bluetooth device without pairing, exploiting the OBEX Push service. It is a nuisance but does not involve data theft. Bluesnarfing is unauthorized access to data (contacts, calendar) from a Bluetooth device, typically via OBEX Object Push or OBEX File Transfer. Bluesnarfing requires the device to be in discoverable mode and often exploits weak or no authentication. For the exam, if data is stolen, it's bluesnarfing; if only a message is sent, it's bluejacking.
The KNOB (Key Negotiation of Bluetooth) attack exploits the encryption key length negotiation during Bluetooth pairing. The attacker, positioned as a MITM, intercepts the pairing process and forces both devices to agree on a very short encryption key (as low as 1 byte or 8 bits). This short key can be brute-forced quickly, allowing the attacker to decrypt all subsequent encrypted traffic. The attack works on both Classic Bluetooth and BLE that support encryption key length negotiation. The fix is to enforce a minimum key length of 7 bytes (56 bits) or use Bluetooth 5.1+ which mandates a minimum key length of 7 bytes.
BLE uses three advertising channels: channel 37 (2402 MHz), channel 38 (2426 MHz), and channel 39 (2480 MHz). These channels are specifically chosen to avoid the three most common Wi-Fi channels (1, 6, 11) in the 2.4 GHz band, reducing interference. Advertising packets are sent on these channels, and scanning devices listen on them to discover devices. After connection, data is sent on the remaining 37 data channels using frequency hopping.
The BIAS (Bluetooth Impersonation Attack) is a vulnerability (CVE-2020-10135) that allows an attacker to impersonate a previously paired device without knowing the long-term key. It exploits the fact that Bluetooth Secure Connection establishment does not require authentication of the master's identity during the link key generation phase. The attacker can establish a secure connection with a target device by claiming to be a device that has previously paired with it, bypassing the need for authentication. The attack works on both BR/EDR and BLE. Mitigation includes using Secure Connections only (Bluetooth 4.2+) and implementing additional authentication at the application layer.
Yes, Bluetooth can be jammed by transmitting noise on the 2.4 GHz frequency band, especially on the frequencies used by Bluetooth hops. Jamming is a denial-of-service attack that prevents devices from communicating. However, jamming is illegal in many jurisdictions (e.g., FCC regulations in the US) because it disrupts licensed and unlicensed communications. In a penetration test, you should not actually jam; instead, you can demonstrate the risk by showing that the device loses connection when interference is present. The exam may ask about jamming as a potential attack vector.
Common tools include: `hcitool` for scanning and connecting, `bluetoothctl` for pairing and trust, `sdptool` for service discovery, `l2ping` for l2cap ping, `btmon` for capturing Bluetooth packets, `gatttool` for BLE GATT interactions, `bettercap` for BLE scanning and spoofing, `BlueMaho` for classic Bluetooth attacks, and `Wireshark` for packet analysis. On mobile, apps like 'BlueScanner' or 'nRF Connect' are used for BLE. The exam expects you to know which tool is appropriate for a given task (e.g., `sdptool` for service enumeration).
LE Legacy Pairing (introduced in Bluetooth 4.0) uses AES-128 for encryption but relies on a Temporary Key (TK) derived from a PIN or set to 0 in Just Works. It is vulnerable to passive eavesdropping because the TK can be brute-forced if short. LE Secure Connections (introduced in Bluetooth 4.2) uses Elliptic Curve Diffie-Hellman (ECDH) for key exchange, providing stronger security against eavesdropping. Secure Connections also supports Numeric Comparison for MITM protection. For the exam, remember that LE Secure Connections is more secure and resistant to passive attacks.
You've just covered Bluetooth and BLE Attack Surface — now see how well it sticks with free PT0-002 practice questions. Full explanations included, no account needed.
Done with this chapter?