---
name: harden-bluetooth-classic
description: "Discovery and SDP exposure reduction for Bluetooth Classic (BR/EDR) devices left inquiry-scannable with an open Service Discovery Protocol database, letting a nearby attacker inventory the device and browse every advertised profile before pairing or a stack exploit such as BlueBorne or KNOB (MITRE ATT&CK T1046, T1011.001, T1557). The signal is link and HCI layer: HCI and btsnoop traces, SDP requests over L2CAP, BlueZ bluetoothd journald records, and Windows BthPort ETW channels plus event 6416. The skill gives the scan-state and SDP-exposure model to enforce (non-discoverable steady state, SDP profile pruning), defender-view signals, a hunt, and framework-mapped hardening. Use when designing or reviewing a Bluetooth Classic device, cutting discoverable-mode exposure across a fleet, triaging an unknown peer that browsed your service records, or hunting for BR/EDR inquiry and SDP enumeration."
---

# Bluetooth Classic (Discovery / SDP) - Defensive Methodology

> **Tier 2 - methodology skill.** No bespoke UMBRASEC detection rule ships with this skill yet. It gives the defender's method, the log sources and signals, and the hardening, and points to public rule and reference sources. Promotion to Tier 1 (a sourced, tuned UMBRASEC rule) is tracked in [COVERAGE.md](https://github.com/umbrasec-labs/umbra-blue/blob/main/COVERAGE.md). Do not treat the content below as citing a UMBRASEC rule; there is none for this threat yet.

## TL;DR

A Bluetooth Classic device gives an attacker two free gifts before any pairing attempt: it answers inquiry scans (so its `BD_ADDR`, vendor OUI, and class of device are discoverable), and its SDP server will hand the full list of advertised profiles to any peer that asks. Close both. First, set the steady state to **connectable but not discoverable**: `HCI_Write_Scan_Enable` of `0x02` (page scan only), so a device that already knows the address can still reconnect but the radio does not answer inquiries. Second, and more important, **prune the advertised services**: an Extended Inquiry Response (EIR) leaks the service-class UUID list even before an SDP query, so disabling every profile the device does not actually use shrinks the EIR and the SDP database together. Third, **require authentication on every remaining profile** (Secure Simple Pairing, MITM protection for sensitive profiles, no open SPP or OPP channel), because once an attacker knows the address, non-discoverable mode no longer hides anything and per-profile auth is the control that holds. Keep the stack patched for BlueBorne and KNOB. This skill is defensive and ships no inquiry, SDP-browse, pairing-downgrade, or exploitation tooling.

## What it looks like, defender view

An unknown peer performs an inquiry and your device answers with an **Inquiry Result** (`0x02`) or **Extended Inquiry Result** (`0x2F`), then issues a **Remote Name Request** and opens an L2CAP channel to **SDP on PSM `0x0001`**. The enumeration tell is an **SDP ServiceSearchAttributeRequest** (`0x06`) carrying the public **browse-group root UUID `0x1002`** with an attribute range of `0x0000-0xFFFF`: that is a request to dump every public service record and its attributes in one shot, which is what a browse tool does and what a bonded client rarely needs after first pairing. A sequential sweep of page attempts across a range of `BD_ADDR` values, with no prior inquiry, is address brute forcing against non-discoverable devices (the `redfang` pattern). On the device side, the weak posture is the opposite of hardened: the adapter sits in inquiry-and-page scan (`piscan`) indefinitely, the SDP database advertises OPP, FTP, SPP, HID, and HFP whether or not they are used, and an inbound RFCOMM channel to one of those profiles opens without authentication.

## Log sources and signals

The discovery and SDP signal is at the HCI / L2CAP / SDP layer, not in host logs, and a target device usually keeps no record that it was inquired or browsed. BR/EDR link PDUs are not log records, so this is a poor fit for log-oriented rule engines; capture tooling and host-configuration audit are the right instruments.

- **HCI / btsnoop traces.** `btmon` and `hcidump` on Linux, and btsnoop captures opened in Wireshark with display filters `bthci_cmd`, `bthci_evt`, `btsdp`, and `btl2cap`.
  - **Inquiry / scan:** `HCI_Inquiry`, Inquiry Result (`0x02`) and Extended Inquiry Result (`0x2F`) events, `HCI_Remote_Name_Request`, and the local `HCI_Write_Scan_Enable` value (`0x00` none, `0x01` inquiry scan, `0x02` page scan, `0x03` both). The EIR payload carries the service-class UUID list and the device name before any SDP query.
  - **SDP:** L2CAP connection to PSM `0x0001`; ServiceSearchRequest (`0x02`), ServiceAttributeRequest (`0x04`), and ServiceSearchAttributeRequest (`0x06`), with the search pattern (browse-group root `0x1002` means "all public services") visible in the `btsdp` dissection.
- **BlueZ host.** `bluetoothd` via journald (`journalctl -u bluetooth`), the `org.bluez.Adapter1` `Discoverable`, `DiscoverableTimeout`, and `Pairable` properties, the adapter scan state (`hciconfig <dev>` shows `ISCAN`/`PSCAN`), and `/etc/bluetooth/main.conf` (`DiscoverableTimeout = 0` means stay discoverable with no timeout). `sdptool browse local` dumps your own adapter's advertised records for audit.
- **Windows.** The Bluetooth ETW providers `Microsoft-Windows-Bluetooth-BthPort` and `Microsoft-Windows-Bluetooth-Bthmini` for BR/EDR radio and connection state, and the log-shaped host signal **Security Event ID 6416 "A new external device was recognized by the system"** (enable **Audit PnP Activity**) when a Bluetooth device is paired and installed. Enterprise policy state lives in the Bluetooth Policy CSP (`Bluetooth/AllowDiscoverableMode`, `Bluetooth/ServicesAllowedList`, `Bluetooth/SetMinimumEncryptionKeySize`).
- **Device / gateway.** The device's own configured profile list and per-connection authentication state, and any gateway or MDM record of which radios are enabled.

**Baseline.** A hardened device is in page scan only (`0x02`), advertises a short SDP list limited to the profiles it uses, and requires authentication before any profile channel carries data. Known peers reconnect by address without an inquiry, so steady-state Inquiry Result and broad SDP browse traffic against your devices should be near zero.

## Detection approach

Alert on configuration drift and on enumeration behaviour, not on single packets. The high-signal conditions are: (1) an adapter that is left in inquiry scan (`HCI_Write_Scan_Enable` includes `0x01`, or `DiscoverableTimeout = 0`) when policy says it should be connectable-only, which is a standing exposure regardless of whether an attack has occurred; (2) an SDP ServiceSearchAttributeRequest (`0x06`) for the browse-group root `0x1002` with a full attribute range from an unknown or unbonded `BD_ADDR`, i.e. a full service-record dump; (3) a sequential sweep of page or connection attempts across many `BD_ADDR` values with no preceding inquiry (address brute forcing); and (4) an inbound RFCOMM / L2CAP channel to a sensitive profile (SPP, OPP, HID) that opens before any authentication event.

Because the evidence is link-layer, a tuned UMBRASEC rule is not yet shipped for this threat, and conditions (1) to (4) are expressed against capture tooling rather than a SIEM log schema. For the host-side events that are log-shaped (BlueZ journald records, Windows BthPort/Bthmini ETW, and Audit PnP Activity event 6416), track SIEM detections in the general [SigmaHQ repository](https://github.com/SigmaHQ/sigma). For the protocol-level analysis use the [Wireshark Bluetooth SDP protocol filter](https://www.wireshark.org/docs/dfref/b/btsdp.html) (`btsdp`, `bthci_cmd`, `bthci_evt`), and [NIST SP 800-121 Rev. 2, Guide to Bluetooth Security](https://csrc.nist.gov/pubs/sp/800/121/r2/upd1/final) for the discovery and SDP security model.

## Threat hunt

Hypothesis: a device is discoverable when it need not be, or its SDP database advertises profiles that are unused and unauthenticated.

1. **Inventory the radios.** List every Bluetooth Classic-capable device and adapter, with `BD_ADDR`, vendor OUI, and class of device. A radio you did not know about cannot be hardened, and disabling it entirely where it is not needed is the strongest control.
2. **Audit scan state.** On each adapter check `HCI_Write_Scan_Enable` / the `ISCAN` flag and `DiscoverableTimeout`. Anything left inquiry-scannable with no timeout is a finding; the hardened steady state is page scan only.
3. **Audit the advertised SDP records.** Dump your own adapter's records with `sdptool browse local` (local adapter, no scanning of others) and compare the advertised profiles against what the device actually uses. OPP, FTP, SPP debug channels, and HID left advertised but unused are each a finding, and each is also visible in the EIR before any SDP query.
4. **Check per-profile authentication.** Confirm each remaining profile requires Secure Simple Pairing and, for sensitive profiles, MITM protection, and that no channel opens data before authentication.
5. **Check the stack version.** Compare the Bluetooth stack against BlueBorne (notably the BlueZ SDP out-of-bounds read, CVE-2017-1000250, which leaks process memory through a crafted ServiceSearchAttributeRequest) and KNOB (CVE-2019-9506). These are patch problems, not detectable without a sniffer, so version audit is the control.

## Hardening

Shrink the surface by fixing the configuration, then detection is a backstop rather than the primary control. The mappings below follow the control codes used in the UMBRASEC [foundation guide](https://umbrasec.dev/guide/foundation.html); a cell is left blank where no single control maps cleanly (the Essential Eight is a Windows-estate model that does not address BR/EDR radio design, so only the patching row maps to it).

| Control | What it does | Essential Eight | ISO 27001:2022 | NIST CSF 2.0 |
|---|---|---|---|---|
| Non-discoverable steady state | Set page scan only (`HCI_Write_Scan_Enable 0x02`), a short `DiscoverableTimeout`, and discoverable only while actively pairing, so the radio does not answer inquiries; on Windows disable discoverable mode via `Bluetooth/AllowDiscoverableMode` | - | A.8.19 Software on systems | PR.PS Platform Security |
| Prune advertised profiles (EIR and SDP) | Disable every profile the device does not use so neither the Extended Inquiry Response nor the SDP database advertises OPP, FTP, SPP, or HID it does not need; on Windows enforce an SDP allowlist via `Bluetooth/ServicesAllowedList` | - | A.8.19 Software on systems | PR.PS Platform Security |
| Per-profile authentication | Require Secure Simple Pairing and MITM protection for sensitive profiles, allow no open SPP or OPP channel, and set a minimum encryption key size (`Bluetooth/SetMinimumEncryptionKeySize`) to blunt KNOB | - | A.8.5 Secure authentication | PR.AA-01 |
| Patch the Bluetooth stack | Remediate BlueBorne (CVE-2017-1000250) and KNOB (CVE-2019-9506) and keep firmware current | Patch operating systems; Patch applications | A.8.8 Technical vulnerabilities | PR.PS Platform Security |
| Radio inventory and disable-where-unused | Maintain an inventory of Bluetooth radios and turn the radio off entirely where it is not needed (BIOS or MDM device-configuration policy, or `Connectivity/AllowBluetooth` on Windows) | - | A.5.9 Inventory of assets | ID.AM Asset Management |

## Honest limitations

Two gaps matter most. First, a target device keeps no host log of being inquired or page-brute-forced: only an RF monitor or an instrumented stack sees a `redfang`-style sequential sweep, so on fielded hardware the configuration audit (hunt steps 2 to 4) matters more than live detection. Second, non-discoverable mode defeats only casual inquiry; an attacker who already knows the `BD_ADDR` (from an earlier capture, a sticker, a vendor OUI guess, or a brute sweep) can still page and connect, so per-profile authentication, not scan state, is the control that holds against a motivated attacker. Pruning SDP removes casual enumeration but does not stop a peer that already knows the channel number, and KNOB and BlueBorne are patch problems that a passive defender cannot see without a sniffer. The browse-root enumeration signal has a benign source too: a device pairing for the first time is unbonded and some stacks do a full SDP browse at that moment, so detection condition (2) will fire during legitimate provisioning and should be tuned against your own pairing flow. Baseline your environment before enforcing: some accessories genuinely need a profile you might otherwise prune.

## ATT&CK and D3FEND

- MITRE ATT&CK: [T1046 Network Service Discovery](https://attack.mitre.org/techniques/T1046/) (Discovery) for the SDP service browse; [T1011.001 Exfiltration Over Bluetooth](https://attack.mitre.org/techniques/T1011/001/) (Exfiltration) for data pulled over the BR/EDR medium; [T1557 Adversary-in-the-Middle](https://attack.mitre.org/techniques/T1557/) (Credential Access, Collection) for the KNOB / legacy-pairing downgrade that follows discovery.
- MITRE D3FEND: [D3-ACH Application Configuration Hardening](https://d3fend.mitre.org/technique/d3f:ApplicationConfigurationHardening/), which is the centerpiece here (non-discoverable scan state and SDP / profile pruning are configuration hardening of the Bluetooth stack); [D3-NTA Network Traffic Analysis](https://d3fend.mitre.org/technique/d3f:NetworkTrafficAnalysis/) for the capture-side detection of inquiry and SDP-browse behaviour.
- Public rule and reference sources: [NIST SP 800-121 Rev. 2, Guide to Bluetooth Security](https://csrc.nist.gov/pubs/sp/800/121/r2/upd1/final); [Wireshark Bluetooth SDP protocol filter](https://www.wireshark.org/docs/dfref/b/btsdp.html); [Microsoft Bluetooth Policy CSP](https://learn.microsoft.com/en-us/windows/client-management/mdm/policy-csp-bluetooth) for the Windows enterprise controls; [SigmaHQ repository](https://github.com/SigmaHQ/sigma) for host-side BlueZ and Windows Bluetooth device-event rules.

**Scope note.** This is a defensive skill. It explains Bluetooth Classic discovery and SDP only to the depth needed to reduce exposure and detect enumeration, and deliberately ships no inquiry, SDP-browse, pairing-downgrade, or exploitation tooling. UMBRASEC publishes defense, not offense.