Detect Air-Gap Bridging via Rogue Bluetooth Re-Enablement and Courier Device Pairing in Splunk
In high-security or OT/ICS environments, endpoint hardening policy typically disables the Bluetooth radio at the service level (bthserv start type set to Disabled) even though the hardware is physically present, precisely to prevent this exfiltration path. An insider or someone with brief physical access can re-enable the disabled service, pair a burner phone or small SBC-based Bluetooth receiver they brought in, and use the built-in OBEX file transfer (fsquirt.exe on Windows, obexftp/bluetoothctl on Linux) to move a staged archive off the host before removing the receiver from the premises — leaving almost no network-layer trace since the transfer never touches a monitored network segment. This is a narrower and higher-confidence variant of generic Bluetooth activity monitoring: the base T1011.001 technique detection watches for any Bluetooth tool execution or registry/file activity, which is noisy in environments where Bluetooth is a normal peripheral channel. This scenario instead keys on the specific sequence that only occurs on a host where Bluetooth was deliberately disabled by policy: a service start-type change from Disabled to Automatic/Manual, followed within a short window by a new device pairing and an OBEX file transfer, ideally combined with off-hours timing. That sequence has essentially no legitimate business explanation on a hardened endpoint and is a strong indicator of deliberate air-gap bridging rather than routine peripheral use.
MITRE ATT&CK
- Tactic
- Exfiltration
SPL Detection Query
| multisearch
[ search index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" (EventCode=12 OR EventCode=13)
TargetObject="*Services\\bthserv\\Start*" (Details="2" OR Details="3" OR Details="0x00000002" OR Details="0x00000003")
| eval Signal="BluetoothServiceReEnabled"
| table _time, host, User, TargetObject, Details, Signal ]
[ search index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=12
TargetObject="*BTHPORT\\Parameters\\Devices*" EventType="CreateKey"
| eval Signal="NewBluetoothPairing"
| table _time, host, User, TargetObject, Signal ]
[ search index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1
(Image="*\\fsquirt.exe" OR Image="*\\obexftp" OR Image="*bluetooth-sendto*")
| eval Signal="ObexFileTransfer"
| table _time, host, User, Image, CommandLine, Signal ]
| sort 0 host, _time
| stats list(Signal) as Signals, list(_time) as Times by host
| where mvcount(Signals) >= 3 AND mvfind(Signals, "BluetoothServiceReEnabled") >= 0 AND mvfind(Signals, "NewBluetoothPairing") >= 0 AND mvfind(Signals, "ObexFileTransfer") >= 0SPL detection combining three Sysmon registry/process signals on the same host: bthserv Start value change to Automatic/Manual (Event ID 12/13), new BTHPORT device pairing key creation (Event ID 12), and an OBEX transfer tool execution (Event ID 1). The final stats stage requires all three signal types to be present for the same host before surfacing an alert, replicating the ordered correlation expressed natively in the KQL query.
Data Sources
Required Sourcetypes
False Positives & Tuning
- Authorized IT change re-enabling Bluetooth for approved peripheral installation
- Endpoint reimaging resetting service start types before hardening baseline is reapplied
- Documented exception process for a specific role requiring Bluetooth
Other platforms for THREAT-Bluetooth-AirGapCourierExfil
Testing Methodology
Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1Re-Enable Disabled Bluetooth Service on Windows
Expected signal: Sysmon Event ID 13: registry value change for HKLM\SYSTEM\CurrentControlSet\Services\bthserv\Start from 4 (Disabled) to 3 (Manual/Demand). Windows Event Log System channel Event ID 7040 recording the service start-type change. Sysmon Event ID 1 for sc.exe process creation with 'config bthserv' in the command line.
- Test 2Simulate Bluetooth Device Pairing Registry Entry
Expected signal: Sysmon Event ID 12: RegistryKeyCreated event for the new device key under BTHPORT\Parameters\Devices. Sysmon Event ID 1 for reg.exe process creation with 'add' and the BTHPORT path in the command line.
- Test 3Execute Windows Bluetooth File Transfer Wizard (fsquirt)
Expected signal: Sysmon Event ID 1: process creation for fsquirt.exe with '/SEND' argument. File creation event for the staged test file preceding the transfer attempt.
Response Playbook
Triage
- Confirm the device's expected Bluetooth policy — check the configuration management baseline (GPO, Intune, SCCM) to verify Bluetooth is meant to be disabled on this asset class before treating the alert as anomalous.
- Check for an associated change ticket or maintenance window covering the service re-enable — if none exists, treat this as unauthorized.
- Identify the account and logon session active on the device at the time of the service change, pairing, and transfer — is it consistent with the assigned user, or does it suggest a different individual with physical access?
- Review the newly paired device's MAC address vendor OUI — an OUI not matching known corporate-approved peripherals (or a randomized/locally-administered MAC, common on burner phones) raises suspicion.
- Determine what file(s) were transferred via the OBEX command line or, if unavailable, correlate with DeviceFileEvents for large or sensitive file access immediately preceding the transfer.
- Check physical access control logs (badge swipes, visitor logs) for the facility/room housing this asset around the time of the event, if available.
Containment
- Immediately re-disable the bthserv service and set the start type back to Disabled via Group Policy or direct remediation: `sc config bthserv start= disabled`.
- Remove the rogue device pairing from the BTHPORT device registry, or fully re-image the endpoint if the device is suspected to be compromised beyond the Bluetooth channel.
- Isolate the endpoint from the network via EDR while investigation continues, particularly if the transferred data is classified or highly sensitive.
- If an employee's account is implicated, coordinate with HR/Legal before any personnel action — treat as an HR-led investigation alongside the technical one.
- Apply or reinforce an application control / device installation restriction policy (Device Installation Restrictions GPO) blocking Bluetooth radio installation entirely on assets that should never need it.
- Physically inspect the endpoint for any unauthorized hardware (USB Bluetooth dongle) if the built-in radio was expected to be absent or removed.
Evidence Collection
- Registry: HKLM\SYSTEM\CurrentControlSet\Services\bthserv\Start — before/after value and the process that changed it (Sysmon Event ID 13)
- Registry: HKLM\SYSTEM\CurrentControlSet\Services\BTHPORT\Parameters\Devices — new device MAC address, name, and pairing timestamp
- Process creation logs for fsquirt.exe/obexftp with full command line including any visible file path arguments
- Windows Security Event Log: logon session (Event ID 4624/4634) covering the full window from service re-enable through transfer, to confirm the acting user
- Physical access control system logs (badge/door logs) for the room or cabinet housing the asset, if the organization has this capability
- Configuration management baseline report confirming the asset's expected (pre-incident) Bluetooth policy state
Escalation Criteria
- !The asset is in a segment explicitly designated as air-gapped, classified, or OT/ICS, where Bluetooth is prohibited by policy with no exception process
- !No change ticket or documented exception exists for the Bluetooth re-enablement
- !The transferred data, based on file access correlation, includes classified, PII, financial, or intellectual property records
- !The paired device's MAC OUI does not match any corporate-approved peripheral vendor and cannot be attributed to a known employee-owned device
- !The activity occurs outside business hours or shortly before/after the responsible user's badge access to the facility shows an anomaly (e.g., badge access by someone other than the account owner)
- !Multiple assets show the same re-enable-pair-transfer sequence, suggesting a coordinated or repeated exfiltration operation rather than a single opportunistic event
Investigation Guide
Related Techniques
Forensic Artifacts
- >
Registry: HKLM\SYSTEM\CurrentControlSet\Services\bthserv\Start — service start-type history via registry transaction logs or forensic timeline - >
Registry: HKLM\SYSTEM\CurrentControlSet\Services\BTHPORT\Parameters\Devices\<MAC> — paired device details and link keys - >
Prefetch: C:\Windows\Prefetch\FSQUIRT.EXE-*.pf — execution timestamp and run count for the OBEX transfer wizard - >
Windows Event Log: System channel Event ID 7040 (service start type changed) for bthserv - >
Configuration management agent logs (SCCM/Intune compliance state) showing the device's last known-good Bluetooth policy state before the change - >
Physical security system logs, where integrated with IT, correlating badge access to the asset's location
Tuning Guidance
This detection is only high-value on assets where Bluetooth is expected to be disabled by policy — apply it as a scoped rule against the specific device group/OU tagged as hardened, air-gapped, or OT/ICS rather than fleet-wide, since on general-purpose workstations Bluetooth service changes are routine. Maintain an exception list of pre-approved change tickets or device serial numbers where temporary re-enablement is sanctioned, and suppress only those specific assets for the ticket's validity window rather than disabling the rule. Because badge/physical-access correlation meaningfully increases confidence but is rarely available in the SIEM directly, route confirmed technical hits to the physical security team as a standing enrichment step rather than trying to encode it in the detection logic itself.
Hunting Queries
Hunt across the full fleet for any bthserv start-type change over the past 90 days, cross-referenced against the asset inventory's expected Bluetooth policy per device class. Any hardened-tier asset appearing in this result set warrants investigation regardless of whether the full pairing/transfer chain also fired.
DeviceRegistryEvents
| where Timestamp > ago(90d)
| where RegistryKey has @"Services\bthserv" and RegistryValueName == "Start"
| where RegistryValueData in ("2", "3")
| project Timestamp, DeviceName, AccountName = InitiatingProcessAccountName, RegistryValueData
| sort by Timestamp descindex=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" (EventCode=12 OR EventCode=13) TargetObject="*Services\\bthserv\\Start*"
| table _time, host, User, TargetObject, Details
| sort - _timeAtomic Red Team Tests
Simulates an adversary or insider re-enabling a policy-disabled Bluetooth service, the first stage of the air-gap bridging sequence. On a hardened endpoint this service should normally be set to Disabled.
Command
powershell.exe -Command "sc.exe config bthserv start= demand; sc.exe start bthserv"Cleanup
powershell.exe -Command "sc.exe stop bthserv; sc.exe config bthserv start= disabled"Expected Telemetry
Sysmon Event ID 13: registry value change for HKLM\SYSTEM\CurrentControlSet\Services\bthserv\Start from 4 (Disabled) to 3 (Manual/Demand). Windows Event Log System channel Event ID 7040 recording the service start-type change. Sysmon Event ID 1 for sc.exe process creation with 'config bthserv' in the command line.
Expected Detection
KQL ServiceReEnable signal fires on the bthserv Start registry value changing to 2 or 3. This is stage one of the three-stage correlation and will not alone trigger the full high-confidence detection until paired with subsequent pairing and transfer activity.
Directly creates a test entry under the BTHPORT device registry key to simulate a new Bluetooth device pairing, the second stage of the sequence, without requiring physical Bluetooth hardware.
Command
reg add "HKLM\SYSTEM\CurrentControlSet\Services\BTHPORT\Parameters\Devices\001122334455" /fCleanup
reg delete "HKLM\SYSTEM\CurrentControlSet\Services\BTHPORT\Parameters\Devices\001122334455" /fExpected Telemetry
Sysmon Event ID 12: RegistryKeyCreated event for the new device key under BTHPORT\Parameters\Devices. Sysmon Event ID 1 for reg.exe process creation with 'add' and the BTHPORT path in the command line.
Expected Detection
KQL NewPairing signal fires on the RegistryKeyCreated event under BTHPORT\Parameters\Devices. Combined with the prior ServiceReEnable test within the 2-hour join window, this advances the correlation to stage two.
Launches the built-in Windows Bluetooth File Transfer Wizard to simulate the final OBEX transfer stage, completing the full re-enable-pair-transfer sequence for detection validation.
Command
echo 'test exfil data' > C:\Temp\airgap_test.txt && Start-Process fsquirt.exe -ArgumentList '/SEND' -WaitCleanup
Remove-Item C:\Temp\airgap_test.txt -Force -ErrorAction SilentlyContinueExpected Telemetry
Sysmon Event ID 1: process creation for fsquirt.exe with '/SEND' argument. File creation event for the staged test file preceding the transfer attempt.
Expected Detection
KQL ObexTransfer signal fires on the fsquirt.exe execution. Combined with the two prior atomic tests executed on the same host within the correlation window, the full three-stage query fires with IsOffHours evaluated against the local execution time.