USB & external devices
Bluetooth paired devices
Bluetooth devices cheat sheet: BTHPORT paired device keys, MAC addresses and names, LastSeen/LastConnected times, BTHENUM, event logs and fsquirt transfers.
- Location
- SYSTEM\CurrentControlSet\Services\BTHPORT\Parameters\Devices\<MAC>
- Proves
- Which Bluetooth devices were paired with the computer, their names and MAC addresses, and roughly when they were last seen
- Timestamps
- Key LastWrite times plus, on some builds, LastSeen/LastConnected REG_QWORD values, all FILETIME in UTC
- Retention
- Paired device keys stay until the device is removed in Settings; removal deletes the key but it may survive in shadow copies or hive slack
- Access
- Admin to read the SYSTEM hive offline; the Keys subkey (link keys) is readable only as SYSTEM on a live host
- Type
- Registry
- Windows
- Vista / 78 / 8.11011
- KAPE target
- RegistryHivesSystemEventLogs
- Velociraptor
- No dedicated target
Tools
Compare all toolsWhat it is
When a Bluetooth device (phone, headset, keyboard, speaker) is paired with Windows, the Bluetooth stack records it in the SYSTEM hive. Each paired device gets a key named after its MAC address, with its friendly name, device class and, on newer builds, timestamps. Plug and Play also creates enumeration entries for each service the device exposes. In insider cases this is where you prove a personal phone was paired, and a pairing followed by the Bluetooth File Transfer wizard is a classic low-tech exfiltration path.
Location
| Item | Path (SYSTEM hive) |
|---|---|
| Paired Classic devices | ControlSet00x\Services\BTHPORT\Parameters\Devices\<MAC> |
| Pairing keys | ControlSet00x\Services\BTHPORT\Parameters\Keys\<local adapter MAC>\<device MAC> |
| Classic service enumeration | ControlSet00x\Enum\BTHENUM\{<service UUID>}_...\<instance> |
| Bluetooth LE devices | ControlSet00x\Enum\BTHLE\ and Enum\BTHLEDevice\ |
| Local adapter | ControlSet00x\Enum\USB\VID_xxxx&PID_xxxx\ (USB radios) |
The MAC is stored as 12 hex digits without separators (for example a4c3f0112233). Resolve the first 6 digits (OUI) to a manufacturer, keeping in mind that many phones use randomised addresses for BLE.
What it proves
- Proves a device with that MAC and name was paired with this computer at some point.
- Proves (with the
Keysentry) a bond was established, not just a discovery. - Timestamps give an approximate last-seen or last-connected time where the values exist.
- It does not prove data was transferred. Transfers must be shown separately (fsquirt execution, file references, received files).
- It does not attribute the pairing to a user: the data sits in
SYSTEM. Correlate with logons and user-hive activity. - Device names are user-editable on the phone and are not unique identifiers.
Key fields
Value (under Devices\<MAC>) | Meaning |
|---|---|
Name | Friendly name, REG_BINARY holding a null-terminated UTF-8 string |
COD | Class of Device (phone, audio, peripheral) |
LastSeen | Last time the radio saw the device (FILETIME; not present on every build) |
LastConnected | Last connection time (FILETIME; not present on every build) |
VID, PID, Version | Device identifiers, when advertised |
LEName, LEAddressType | Present for some LE devices |
The exact value set varies between Windows versions and between Classic and LE devices; always look at what is actually present rather than expecting a fixed schema.
Timestamps
| Timestamp | Format | Notes |
|---|---|---|
LastSeen / LastConnected | FILETIME (REG_QWORD), UTC | Version-dependent; validate against a reference system |
Devices\<MAC> key LastWrite | FILETIME, UTC | Changes when any value is updated, often at each connection |
Enum\BTHENUM device properties | FILETIME, UTC | The Plug and Play property keys for install and last arrival/removal (as with USB devices) may be present; verify per build |
setupapi.dev.log entries | Local time text | First driver install for each Bluetooth service |
Retention and clearing
- Keys persist until the user removes the device in Settings or Control Panel, which deletes the
DevicesandKeysentries.BTHENUMentries may remain longer. - Deleted keys can be recovered from volume shadow copies, the hive transaction logs, or unallocated hive cells with Registry Explorer.
- Removing a device shortly before an investigation is itself worth noting; compare the current hive with older copies.
Collection
# Offline: collect the SYSTEM hive and its logs
kape.exe --tsource C: --tdest E:\case --target RegistryHivesSystem,EventLogs
# Live overview
reg query "HKLM\SYSTEM\CurrentControlSet\Services\BTHPORT\Parameters\Devices" /s
Get-PnpDevice -Class Bluetooth | Select-Object FriendlyName, InstanceId, Status
Also collect C:\Windows\INF\setupapi.dev.log and the user hives for the transfer traces below.
Parsing tools
- Registry Explorer / RECmd (Eric Zimmerman): browse
BTHPORT, decode FILETIME values; RECmd batch files can include the Bluetooth keys. - RegRipper: the
bthportplugin lists paired devices and names. - BluetoothView (NirSoft): live view of nearby and paired devices.
- EvtxECmd: parse Bluetooth-related channels and Kernel-PnP logs.
Investigation tips
- Exfiltration via Bluetooth File Transfer: the wizard is
C:\Windows\System32\fsquirt.exe, also reachable through Send to > Bluetooth device. Look forFSQUIRT.EXEin Prefetch (the referenced files list can show the documents sent), Amcache, BAM and UserAssist. Received files land in a folder the user picks in the wizard; check recent LNK files and the user's Documents. - Channels such as
Microsoft-Windows-Bluetooth-BthLEPrepairing/OperationalandMicrosoft-Windows-Bluetooth-MTPEnum/Operationalexist on recent builds; their content and default state vary, so check what the host actually logged.Microsoft-Windows-Kernel-PnP/Configurationrecords device installs. - A Bluetooth PAN or phone tethering connection also appears in network profiles.
- Link the MAC to a seized phone: its Bluetooth address is shown in the phone settings and in mobile extractions.
Related artifacts
- USB device historyUSB forensics cheat sheet: USBSTOR and USB keys, serial numbers, first and last connection times, drive letters, volume serials, setupapi.dev.log and event IDs.
- Registry hivesRegistry hives cheat sheet: SYSTEM, SOFTWARE, SAM, SECURITY, NTUSER.DAT, UsrClass.dat, transaction logs, RegBack, LastWrite times and collection.
- Prefetch Files (.pf)Windows Prefetch cheat sheet: .pf location per version, run count, the last eight run times, referenced files, retention limits and how to parse.
- Amcache.hveAmcache.hve cheat sheet: file and program inventory keys, SHA-1 hashes, PE metadata, timestamps and why an entry alone does not prove execution.
- Windows event logs (EVTX)Windows event log cheat sheet: EVTX locations, must-know event IDs for logons, processes, services and log clearing, retention, audit policy and parsing tools.
- Network profiles (NetworkList)NetworkList cheat sheet: network profiles, SSIDs, gateway MAC addresses, first and last connection times (local time), WLAN profile files and WLAN events.
Glossary terms
- Registry key LastWrite timeThe single FILETIME stored in every registry key that records when the key or one of its values was last changed, in UTC.
- ControlSet and CurrentControlSetThe numbered configuration sets in the SYSTEM hive; CurrentControlSet is a runtime link that does not exist in an offline hive file.
- FILETIMEThe 64-bit Windows timestamp format counting 100-nanosecond intervals since 1 January 1601 UTC, used by NTFS, the registry and many artifacts.
- Registry HiveAn on-disk file that backs part of the Windows Registry, such as `SYSTEM`, `SOFTWARE`, or `NTUSER.DAT`.
Guides
- Windows Registry Forensics: Hives, Keys and WorkflowWindows registry forensics in practice: hive files, transaction logs, control sets, LastWrite limits, deleted keys, the keys that matter and RECmd workflows.
- USB Device Forensics: Tracing Drives, Users and FilesIdentify every USB drive connected to a Windows host, date its connections, tie it to a user and prove which files were opened from it, step by step.